tcpdump mailing list archives
Re: [PATCH] SocketCAN support for libpcap - draft
From: Felix Obenhuber <felix () obenhuber de>
Date: Wed, 09 Dec 2009 00:03:01 +0100
Thanks Guy.
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).
During capture from a can interface the relevant fields (here struct can_frame.can_id ) have to be passed to callback() in network byte order. This means to swap on le platforms - for short htonl. cf = (struct can_frame*)&handle->buffer[8]; cf->can_id = htonl( cf->can_id );
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.
With the swap above, flipping the last proto_tree_add_item arguments to FALSE takes care to interpret the data a be. I'm a little bit confused about the correct way to handle the endianess, but to hope to got it right now. I'll have no mail access for a some days, but be back in a week. Cheers, Felix - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Current thread:
- Re: [PATCH] SocketCAN support for libpcap - draft implementation, (continued)
- Re: [PATCH] SocketCAN support for libpcap - draft implementation Gianluca Varenni (Oct 05)
- Re: [PATCH] SocketCAN support for libpcap - Felix Obenhuber (Oct 11)
- Re: [PATCH] SocketCAN support for libpcap - draft implementation Alexander Dupuy (Oct 09)
- Re: [PATCH] SocketCAN support for libpcap - draft implementation Felix Obenhuber (Oct 11)
- Re: [PATCH] SocketCAN support for libpcap - draft implementation Guy Harris (Oct 11)
- Re: [PATCH] SocketCAN support for libpcap - draft Alexander Dupuy (Oct 11)
- Re: [PATCH] SocketCAN support for libpcap - draft Felix Obenhuber (Oct 25)
- Re: [PATCH] SocketCAN support for libpcap - draft Guy Harris (Dec 07)
- Re: [PATCH] SocketCAN support for libpcap - draft Felix Obenhuber (Dec 07)
- Re: [PATCH] SocketCAN support for libpcap - draft Guy Harris (Dec 07)
- Re: [PATCH] SocketCAN support for libpcap - draft Felix Obenhuber (Dec 08)
- Re: [PATCH] SocketCAN support for libpcap - draft implementation Felix Obenhuber (Oct 11)
- Re: [PATCH] SocketCAN support for libpcap - Felix Obenhuber (Oct 12)