Re: [PATCH] SocketCAN support for libpcap - draft

[Guy Harris <guy () alum mit edu>]

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.