Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-bugs: [Wireshark-bugs] [Bug 12687] SocketCAN dissector does not support CAN FD

Date: Sun, 21 Aug 2016 10:57:53 +0000

Comment # 38 on bug 12687 from
(In reply to Guy Harris from comment #34)

> There are several ways to get CAN frames through libpcap:
> 
> 1) capturing on an unbound PF_PACKET socket (using the "any" device with
> libpcap) apparently provides them - that's presumably why the SocketCAN
> dissector registers with LINUX_SLL_P_CAN in the "sll.ltype" dissector
> handle, so that packets delivered with a protocol of LINUX_SLL_P_CAN
> (0x000C) are passed to the dissector;
> 
> 2) capturing on a PF_PACKET socket bound to a CAN network interface
> apparently provides them, as per this libpcap commit:
> 
>     commit 1c1816f670c9015ba97fa6b9780355c787920d67
>     Author: Felix Obenhuber <[email protected]>
>     Date:   Tue Dec 29 01:04:20 2009 -0800
> 
>         Add support for CANbus capture.
> 
> which, for a PF_PACKET socket bound to an interface, maps ARPHRD_CAN to
> DLT_CAN_SOCKETCAN;
> 
> 3) capturing on a PF_CAN socket (pcap-can-linux.c);
> 
> 4) capturing on CanUSB devices (pcap-canusb-linux.c).

2+3 are the same implementations!

4 is a special USB CAN Hardware with Vendor ID 0x0403 and Device ID 0x8990
where I didn't find any information about on the Internet.
At least it's a bad idea to name it pcap-canusb-linux.c as this name aims to
handle a class of interfaces which definitely does not handle.

> How do each of those four handle CAN FD frames?

Not - by now. pcap-canusb-linux.c will probably never do.

> Note, BTW, that in only one of those four code paths is the CAN FD/flags
> field put in network byte order; the others provide it in *host* byte order.
> To handle this, DLT_CAN_SOCKETCAN was renamed DLT_CAN_SOCKETCAN_BIGENDIAN,
> and a new DLT_CAN_SOCKETCAN_HOSTENDIAN was added, so, with the latest
> master-branch libpcap,

This smells fishy.

> you can get either of those two DLT_ values when
> capturing, and can get either of the corresponding LINKTYPE_ values in
> capture files.  The tip of the master, 2.2, and 2.0 branches in Wireshark
> can handle both (and also have a "byte-swap the CAN FD/flags field"
> preference to handle captures from unmodified libpcap if the CAN FD/flags
> field is little-endian).

Will continue in other replies.


You are receiving this mail because:
  • You are watching all bug changes.