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.
