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: Wed, 17 Aug 2016 03:32:01 +0000

Comment # 33 on bug 12687 from
(In reply to Oliver Hartkopp from comment #32)
> With CAN FD we now have two options:
> 
> 1. Create a second link type DLT_CANFD_SOCKETCAN and provide a separate data
> source to Wireshark. Additionally libpcap could be moved to use PF_PACKET
> too.
> 
> 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.
> 
> As you can see from our patches option 2 is obviously easy to do.
> But is it the right way to go?

Now we're on the same page as I was trying to ask similar questions earlier.  I
don't have a strong opinion on the route taken, but I do believe Wireshark
should show ALL "frame data" which includes CANFD_USE bit if you are going to
piggyback on the DLT_CAN_SOCKETCAN format.

My patch (and current dissection functionality) has the fields/flags in order
as they appear on the frame:
32-bit value for CAN ID + "original" flags (ERR, RTR, EFF/SFF)
8-bit length field
8-bit flag field for CAN_FD (so only visible if frame is CAN_FD)
16-bit "pad" (which probably should be added because people don't like seeing
gaps in dissection - consider 24-bit pad for "Classic" CAN)
0-x bytes - packet data.

If a DLT_CANFD_SOCKETCAN "frame format" can better consolidate its respective
flags, then Wireshark would dissect them as such (but still in order).  It
would then probably lend itself to a separate dissection function (like I had
in the first version of my patch as I thought this was going to be the
direction).

CANFD dissection will not be included in the 2.2 release, so we have a good
amount of time to finalize a solution. We can go the route of piggybacking on
CAN for now until a DLT_CANFD_SOCKETCAN value can be secured (email
tcpdump-workers to work that out).

I don't have a problem submitting my patch once the minor bugs/comments have
been worked through as it does enable the dissection of CANFD and you can use
Wireshark moving forward (nightly builds) in your efforts with it.


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