Wireshark-bugs: [Wireshark-bugs] [Bug 12687] SocketCAN dissector does not support CAN FD
Comment # 38
on bug 12687
from Oliver Hartkopp
(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 <felix@obenhuber.de>
> 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.
