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? Furthermore the intention for this enhancement was, to use libpcap from existing applications (ie. WS), that already make use of the lib. From this point of view it acts as a kind of adapter only. Concerning this, byte order conversions might be confusing. btw: Some already tried? Thanks, Felix - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
