Re: [PATCH] SocketCAN support for libpcap - draft

[Alexander Dupuy <alex.dupuy () mac com>]

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-endian
> > > format 

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.