tcpdump mailing list archives
[PATCH] SocketCAN support for libpcap - draft implementation
From: Felix Obenhuber <felix () obenhuber de>
Date: Sat, 03 Oct 2009 10:07:39 +0200
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.
Current thread:
- [PATCH] SocketCAN support for libpcap - draft implementation Felix Obenhuber (Oct 03)
- <Possible follow-ups>
- [PATCH] SocketCAN support for libpcap - draft implementation Felix Obenhuber (Oct 03)
- [PATCH] SocketCAN support for libpcap - draft implementation Felix Obenhuber (Oct 04)
- Re: [PATCH] SocketCAN support for libpcap - draft implementation Guy Harris (Oct 04)
- Re: [PATCH] SocketCAN support for libpcap - Felix Obenhuber (Oct 05)
- Re: [PATCH] SocketCAN support for libpcap - Gianluca Varenni (Oct 05)
- Re: [PATCH] SocketCAN support for libpcap - Michael Richardson (Oct 05)
- Re: [PATCH] SocketCAN support for libpcap - Felix Obenhuber (Oct 06)
- Re: [PATCH] SocketCAN support for libpcap - Michael Richardson (Oct 06)
- Re: [PATCH] SocketCAN support for libpcap - draft implementation Guy Harris (Oct 04)
- Re: [PATCH] SocketCAN support for libpcap - draft implementation Gianluca Varenni (Oct 05)
- Re: [PATCH] SocketCAN support for libpcap - draft implementation Gianluca Varenni (Oct 05)