Packet Manipulation with Xbridge

As explained in our previous article, Xbridge is technically not a bridge per se, but a router. While we chose to use the term ‘bridge’ in the name of this software, the nomenclatural distinction is actually an important one with respect to the technical implementation of the software.

Xbridge is necessarily a router due to a number of caveats associated with typical consumer-grade networking equipment. Wireless network adaptors are increasingly popular, but promiscuous mode on these devices is rendered redundant on account of them dropping all traffic not for them on a hardware-level, unless in monitor mode. Likewise, few routers and switches deployed in the home environment allow for multiple hardware addresses to be associated with a single network port. As such, our software operates as a router, determining the correct destination for network traffic according to its protocol address (i.e IP address).

This requires on-the-fly modifications to all network packets passing through Xbridge, otherwise devices on the network will not know where their traffic should go. We shall begin this article by explaining the architecture of a typical packet.

Packets come in a variety of shapes and sizes. Perhaps the packet most people would be familiar with is a TCP/IP packet encapsulated in an Ethernet frame. This is illustrated here.

Typical TCP Packet

A packet can be described as an onion (please, bear with this poor analogy!). On the outermost layer is the hardware header and footer, if one exists. In this case, the Ethernet protocol has a 14-byte header and no corresponding footer.

This 14-byte header is composed of a 6-byte source hardware address (e.g. 00:1D:D8:B3:BD:09), another 6-byte destination hardware address and a 2-byte (short integer) protocol type.

In this case, the protocol type is IPv4 (0×0800). Other protocol types of interest include IPv6 (0×86DD) and ARP (0×0806). NICs only ever inspect the hardware layer and use this information to determine how received packets should be handled.

This is followed by the IP header, which (like in the case of the Ethernet layer) has no corresponding footer. It is at least 20 bytes in length, but can be longer.

IP Header

The first field is the version identifier. This is a four-bit field that should contain the value “4″ to indicate IPv4. The field following this is the length of the header in 32-bit words (4-byte chunks). This is typically 5, to indicate 20 bytes. The third field, Type of Service, is rarely implemented, but was designated to be used in QoS applications.

Next is the total length field, a 16-bit integer indicating the length of the entire packet (excluding the hardware layer) in bytes. The minimum size that a host must be able to handle is 576 bytes and the maximum possible is 65,535 bytes. Typically, the packet is no longer than 1500 bytes, as specified by the MTU for the interface.

The identification field is used to uniquely identify fragments of a complete message. The flags field is used to specify whether a packet is fragmented, or should not be fragmented. The time to live (TTL) field specifies how many “hops” the packet is allowed to make. This prevents infinite loops from occurring on ill-configured networks.

The protocol field specifies the protocol of the underlying message. The two most common protocols in wide use are TCP (0×06) and UDP (0×11). This is followed by the 16-bit header checksum that is used to verify the integrity of the entire IP header. Finally, these are followed by both the source IP address and destination IP address, both 32 bits long.

This IP header is ignored by the network interface hardware, but is of great interest to the operating system. If an operating system makes claim to multiple IP addresses (as in the case of users operating Xbridge), this allows the operating system to determine whether traffic is for the applications residing on it or another computer.  These are the two layers with which Xbridge is most concerned. Layers above this (such as the Application layer, Transport layer, etc. as defined by the OSI model) are relevant only to the applications and computers operating on either side of the bridge.

In typical bridge-mode operation, Xbridge monitors all network traffic passively until it detects a packet for which it is responsible. It determines this by inspecting the Network Layer (c.f. the OSI model), in this case IPv4, and checking whether the destination IP address belongs to the computer on which it is running or a device on another network segment. If it is the latter, Xbridge looks up both the device’s hardware address corresponding to this IP address and the correct network segment in its internal database.

Xbridge must now rewrite the Ethernet header: the source address is changed to that of the network interface that will transmit this altered packet and the destination address is that of the “real” host. Once this process is done, the packet is replaced on the network stack and network operation resumes as per normal.

This typical operation of Xbridge is fairly straight forward, albeit not as simple as a true bridge. However, this only applies to “steady state” network traffic. This operation relies upon Xbridge having all the requisite entries in its database to correctly route network traffic. These entries can be introspected from network packets on an already-configured network, but in the case of “fresh” networks (i.e. networks wherein some or all devices have not yet been assigned IP addresses by a DHCP server), additional work is required in the form of even deeper packet inspection. This will be explained in an upcoming article, so stay tuned.