Re: loopback interface and byte order

[Robert Lowe <Robert.H.Lowe () lawrence edu>]

Guy Harris wrote:

> 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.

Right, sorry for that.

> 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.

Well, I was reporting this from memory.  Let me back up a bit.  When I first
looked at pcap, I went through Tim Carsten's tutorial, referenced from the
tcpdump.org website.  Using that code (sniffer.c) on Linux with a downed eth0
i/f (forcing the dev to any) results in very weird ip src/dst addrs and ports
that look partly like byte swapped information, and partly like wrong offsets.
For example, source might look like 253.103.127.0:1 and dest like
0.1.127.0:32792.  It works fine for packets off the wire.

This leads me to another question.  I've seen recommendations to roll your
own structs for IP/TCP headers, hinting that there might be slight differences
in the definitions between platforms.  Is this really true?  I decided to
use the definitions in the provided header files, and when I tested with my
app, it showed correct behaviour in both cases (off the wire and loopback).
But, if portability is an issue, what is the recommended course of action?

> On what OS are you doing this?

Linux, FC2 (2.6.5-1.358) and FC3 (can't retrieve right now), in particular.
But, I'd like this app to build and run on BSD-derived systems and Solaris.

> > 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.

Thank you for the information!  I don't think I'll bother trying this
now, but I certainly will at some point.

-Robert

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