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 07:40:20 +0000

Comment # 37 on bug 12687 from
(In reply to Michael Mann from comment #36)
> (In reply to Guy Harris from comment #35)
> > > 2. Enhance the PDU that contain the current CAN frames to be able to
> > > transport CAN FD frames too. This kind of tunnelling from libpcap to
> > > Wireshark is currently done with the CANFD_USE bit - and that's why this bit
> > > must not show up in the Wiresharks proto bits.
> > 
> > "Currently" presumably meaning "with your changes to pcap-can-linux.c".
> > 
> > CANFD_USE is defined to be 0x04, which, in the CAN ID/flags field, is one of
> > the CAN ID bits; is that bit guaranteed not to be set in the CAN ID?
> > 
> 
> I have not looked at the libpcap changes, but the CANFD_USE flag (with value
> of 0x4) is NOT part of the CAN ID field (see comment #7 or comment #33 for
> frame format description).  CAN_FD is populating the byte after the length
> field with flag values, including CANFD_USE.

So CAN_FD is a bit in the field that's "pad1" in the struct can_frame header
and "fd_flags" in the struct canfd_frame header?

If so, then it will *not* be set for any captures from 1) a PF_PACKET socket or
2) a CANUSB device.  Perhaps captures on an interface named "canN" will be done
on a PF_CAN socket rather than a PF_PACKET socket, but captures from the "any"
device will not be done on a PF_CAN socket (but will be done as "cooked"
captures, so the protocol can be used to distinguish between CAN and CAN FD)
and captures from a "canusbN" device will also not be done on a PF_CAN socket
(again, how do *they* distinguish between CAN and CAN FD)?

> This is currently how https://code.wireshark.org/review/16787 is detecting
> CANFD packets (still needs to be rebased with latest
> LINKTYPE_CAN_SOCKETCAN_BIGENDIAN/HOST_ENDIAN changes).  To me the current
> debate is if that method should stay or a new linktype for CANFD developed.

...or if we just use DLT_LINUX_SLL for capturing on "canN" devices, with a
PF_PACKET socket, and don't bother using PF_CAN sockets at all.


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