On Oct 25, 2009, at 2:55 AM, Felix Obenhuber wrote:
On Sun, 2009-10-11 at 19:42 -0400, Alexander Dupuy wrote:
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.
Sorry for the late reply.
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)?
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
