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.
