Re: [PATCH] SocketCAN support for libpcap - draft implementation

[Felix Obenhuber <felix () obenhuber de>]

On Fri, 2009-10-09 at 08:27 -0400, Alexander Dupuy wrote:
> Given these differences between the two frame formats I would suggest
> that you use a new DLT for SocketCAN, especially as there would be no
> way to know for sure whether the flags were present or just padding (a
> packet with all zero flags would be indistinguishable). 

Thanks Alex for your thoughts! 

Summing up the discussion till now, I'd like to request a new DLT for
SocketCAN that is called

DLT_CAN_SOCKETCAN

with a comment like:

CAN frames with SocketCAN header. See 
Documentation/networking/can.txt in the Linux source.


Who has his/her hands on the DLTs?

Are there any conventions about the DLT naming? Maybe the slightly
redundant CAN in DLT_CAN_SOCKETCAN doesn't fit them. I've inserted for a
future grouping purpose of DLTs that deal with CAN.

> 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 above for a more comprehensible diagram, and because
> little-endian systems have htonl/ntohl macros that are not no-ops,
> making portable user-level coding simpler (if you standardize the
> little-endian format, portable code has to use #ifdefs to determine
> byte-order and then call a swap() function/macro on big-endian
> systems).

Think that the usage of SocketCAN/libpcap on BE machines may be need
once. Think about a Linux and PPC based CAN data logger for example.

Cheers,

Felix

-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.