Re: [PATCH] SocketCAN support for libpcap - draft

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

On Dec 7, 2009, at 12:57 PM, Felix Obenhuber wrote:

> On Mon, 2009-12-07 at 11:38 -0800, Guy Harris wrote:
> > > I think that preserving the byte order makes sense in order to lean
> > > against the behavior of the native netdev interface. This is also  
> > > the
> > > way libpcap does with ETH_P_ALL devices. Is this correct?
> >
> > What does "preserving the byte order" mean here?  Putting the fields
> > into a standard byte order at capture time, or putting them into the
> > host byte order when reading the file (i.e., byte-swapping them if
> > you're reading the file on a host with a byte order different from  
> > the
> > byte order of the host on which the file was written)?
>
> Putting them into the host byte order when reading the file.

That's what's done for USB devices on Linux.  I'm not sure what an  
"ETH_P_ALL device" is; on Linux, libpcap binds *all* PF_PACKET sockets  
to the protocol ETH_P_ALL, and relies on the packet filter to select  
which packets to capture.

For non-cooked captures, libpcap just supplies the raw data you get  
from the socket.  It doesn't do any byte-swapping when reading the  
file for most link-layer types; the only link-layer types for which it  
swaps to host byte order are DLT_USB_LINUX and DLT_USB_LINUX_MMAPPED.

If you supply data in host byte order, this means that you can't use  
the EXTRACT_ macros in tcpdump, or the tvb_get_ routines in Wireshark,  
to fetch data from the packets, as those macros, and those routines,  
are defined to extract data in a particular byte order (little-endian  
or big-endian).  You also can't use proto_tree_add_item() in  
Wireshark, as the last argument to those routines specifies the byte  
order (little-endian or big-endian).

print-usb.c in tcpdump just prints the value directly, without  
extracting it (the one multi-byte integral quantity it prints is on  
the natural byte boundary *IF* the packet begins on the appropriate  
boundary, which should be the case), so it should be able to handle a  
capture file from a machine with the opposite byte order from the  
machine reading the file (we don't care about PDP-11's any more, so  
there are only two byte orders to care about).  The Wireshark code  
that reads the pseudo-header from the capture file, like the libpcap  
code that reads packets from a capture file, byte-swaps the multi-byte  
fields into host byte order; the Wireshark USB dissector uses those  
fields directly, so it can also handle capture files with the opposite  
byte order.

The Wireshark dissector you supplied for SocketCAN, however, assumes  
those fields are little-endian, which will only be the case when you  
read the file on a little-endian machine; it won't work on, for  
example, SPARC, PowerPC, ARM, System/3x0 or z/Architecture, etc..  If  
you supply the information from the header as a pseudo-header, you  
could byte-swap that in the file-reading code, just as is done for  
fields in the USB pseudo-header, and the fields from the pseudo-header  
would be assumed to be in the host byte order.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.