Re: loopback interface and byte order

[Guy Harris <guy () alum mit edu>]

On Dec 1, 2004, at 3:31 PM, Robert Lowe wrote:

> In testing a small app using libpcap, I noticed differences in 
> behaviour when
> using the loopback interface vs. using a hardware interface.  In 
> particular,
> it seems the packets coming in over the loopback interface are still 
> in host
> byte order (little endian, in this case).

Packets aren't in any byte order; particular fields in the packet might 
be in a particular byte order.

In the link-layer header used with BSD-style loopback interfaces, the 
4-byte packet type is, in most BSDs, in host byte order - it's 
obviously known that the machines on both side of the connection have 
the same byte order :-) - but, at least in newer versions of OpenBSD, 
it's in network byte order.

On Linux, the link-layer header is a fake Ethernet header, and the type 
field *should* be in network byte order (big-endian).

The IP, ICMP, TCP, and UDP header fields should be in network byte 
order.

On what OS are you doing this?

> Is that typical, or just an
> OS-dependent artifact?  In trying to find the answer, I came across a 
> function
> in the pcap library, pcap_datalink().  If I really wanted my app to 
> work using
> the loopback interface, I assume I would use this function to 
> determine whether
> or not to invoke byte order altering functions.

If you really want your app to work on anything other than Ethernet 
interfaces, you would use that function to determine what to do with 
the link-layer header.

If it returns DLT_EN10MB, it's Ethernet (don't worry about the "10MB", 
that's a historical artifact from the days when there was the 
experimental 3Mb/s Ethernet and the standard 10Mb/s Ethernet, and they 
had different link-layer headers; all Ethernets 10Mb and up have the 
same header, and use DLT_EN10MB).

If it returns DLT_NULL, it's BSD-style loopback, with a link-layer 
header containing a 4-byte AF_ value in *host* byte order.

If it returns DLT_LOOP, it's BSD-style loopback, with a link-layer 
header containing a 4-byte AF_ value in *network* byte order.

Beware - the AF_ value is the value for the OS on which the capture is 
being done, and AF_INET6 has different values on {Net,Open}BSD, 
FreeBSD, and OS X!  If you want to handle save files as well as live 
captures, make sure you check for all the AF_INET6 values.
>

-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.