tcpdump mailing list archives
Re: [PATCH] SocketCAN support for libpcap - draft
From: Alexander Dupuy <alex.dupuy () mac com>
Date: Sun, 11 Oct 2009 19:42:21 -0400
I wrote:
If you ever think that SocketCAN/libpcap will be used on big-endian systems, you might want to "canonicalize" the layout in the big-endianformat
Guy Harris replied:
Linux USB leaves the pseudo-header in host byte order - and, in the code that reads the savefile, libpcap byte-swaps the fields, if the capture file was written on a machine with the opposite byte order, so that they appear to be in the byte order of the host reading the file.
Indeed it does, I wasn't aware of that. Having special hacks (or "modularity exceptions," if you prefer) handling the byte-swapping in savefile.c is somewhat plausible for a linktype that is in some sense "internal" to a host, and especially for fields like bus id, timestamp, status and the like that are not actually transmitted on the USB "wire" and therefore don't really have a transmission byte order. However, it seems a bit of a special case and it doesn't seem like such a good idea to encourage other linktypes to handle arbitrary byte-ordering conversions in the savefile code.
In the specific case of the SocketCAN, the fields in question appear to be transmitted on the wire (otherwise there would have been no need for an optional extension to the ID field - the size could just unilaterally have changed); given this fact, and the likelihood that the CAN20B linktype uses big-endian ordering for these fields (this is the impression I get from the format diagram that Gianluca posted, although I have no other evidence), I think it would probably be the more consistent implementation choice to use big-endian order for these fields in the SocketCAN linktype format.
That's just my opinion, however, and as one who will never use the code for this linktype, I would defer to Felix on any implementation choice.
@alex -- mailto:alex.dupuy () mac com - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Current thread:
- Re: [PATCH] SocketCAN support for libpcap -, (continued)
- Re: [PATCH] SocketCAN support for libpcap - Gianluca Varenni (Oct 05)
- Re: [PATCH] SocketCAN support for libpcap - Michael Richardson (Oct 05)
- Re: [PATCH] SocketCAN support for libpcap - Felix Obenhuber (Oct 06)
- Re: [PATCH] SocketCAN support for libpcap - Michael Richardson (Oct 06)
- Re: [PATCH] SocketCAN support for libpcap - draft implementation Gianluca Varenni (Oct 05)
- 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 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)