Comment # 34
on bug 12687
from Guy Harris
(In reply to Oliver Hartkopp from comment #29)
> For that reason my suggested changes to libpcap make sense to me as they are
> using PF_CAN sockets to get the CAN frames - and this would be a reasonable
> extension then.
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).
How do each of those four handle CAN FD frames?
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, 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).
You are receiving this mail because:
- You are watching all bug changes.
