[PATCH] SocketCAN support for libpcap - draft implementation

[Felix Obenhuber <felix () obenhuber de>]

Hi,

some times ago I took a view on SocketCAN [1]. Due I'm using CAN all day
long with various protocols, I'd like to get some tool support for
debugging and analyzation. 

I used ethereal for all ip based stuff and would like to do something
similiar for CAN. With SocketCAN this should be possible anyway, so I
took a look at the code to get an impression about the effort for adding
CAN support to wireshark.

I've submitted a patch that enables libpcap to capture from socket can
interfaces of the libpcap sf site. A copy of this mail is placed for the
description.

I've done some hacks in tcpdump and wireshark that react on DLT_CAN2B to
visualize the captured frames but I'd like to get pcap lined up clearly
first, before going on with that tools. Furthermore the facts of the
libpcap implementation affect the way how to implement the support in
tcpdump or wireshark anyway...

The patch works quite well for me, but I've got a couple of questions:

1. Should pcap_t.buffsize reflect the maximum amount of data captured
within one call of can_read_linux? This so. Should be 8 bytes for the
time and 16 bytes for the can frame ( worst case alignment ).

2. The can frame struct is defined like this (from linux/can.h):
/**
 * struct can_frame - basic CAN frame structure
 * @can_id:  the CAN ID of the frame and CAN_*_FLAG flags, see above.
 * @can_dlc: the data length field of the CAN frame
 * @data:    the CAN frame payload.
 */
struct can_frame {
        canid_t can_id;  /* 32 bit CAN_ID + EFF/RTR/ERR flags */
        __u8    can_dlc; /* data length code: 0 .. 8 */
        __u8    data[8] __attribute__((aligned(8)));
};


Thus on my x86 hardware 3 bytes are padded before the data array to
fulfill the alignment. Should I move the data bytes 3 bytes up before
passing the data to the user?


3. The identification of the device index is quite a hack. I'm "parsing"
the device name for an int before $. Any Ideas how to improve?

4. Am I right, that bytesex conversions should be done in the code that
uses libpcap?

5. The extended/standard frame flag is coded into the id in struct
can_frame. Shall I extract and store in a separate byte?


To try the patch you won't need some real CAN hardware. Just use the
vcan driver like described in Documentation/networking/can.txt in the
Linux source and the tools distributed with socketcan, eg:

# modprobe vcan
# ip link add dev can0 type vcan
# cansend can0 123#affe

Thanks for comments, review and libpcap!

Cheers,

Felix
 


[1] http://developer.berlios.de/projects/socketcan




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