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

[bugzilla-daemon@xxxxxxxxxxxxx]

Comment # 56 on bug 12687 from Oliver Hartkopp

(In reply to Michael Mann from comment #54)
> (In reply to Oliver Hartkopp from comment #53)
> > But please make it in a way that the flags values are always(!) displayed in
> > the same way as CAN identifier, Length, etc. Which means that there's no
> > option to show or hide the CAN FD flags as it is presented now.
> > 
> > A dissector for CAN FD just has do display all flags all the time.
> 
> I'm more indifferent to this change, but I will point out that if the flags
> are true/set, they are appended to the "FD Flags" field so you know their
> value without expanding the tree.

IMHO that doesn't fit the either use expectations nor the correct technical
representation. We now have a separate code for CAN FD frames and display that
protocol type 'CANFD' in the HMI accordingly.

The flags that can be found in struct canfd_frame.flags are no 'CAN FD Flags'
but are only 'flags' that describe this CAN FD frame in the same way the
'Extended Flag' does. I would be fine with the fact that you want to put the
BRS and ESI flags behind the 'Frame-Length:' line to follow the sequential
position in the PDU data.

Therefore the BRS and ESI bits should be presented in the same way and
indention as the EXT flags and without any possibility to collapse or expand
these two bits.

> > > > 
> > > > 2. Up to now only the Packet type 1 (Broadcast) was displayed inside
> > > > Wireshark. With the use of PF_PACKET sockets we now see the type 1 and type
> > > > 4 (from me) packet types - so we see sent frames two times, which is not
> > > > usual.
> 
> I had to go back and look at the trace to realize type 1 can be
> distinguished from type 4, at the "Linux Cooked Capture" layer.  That
> information is not passed to the CAN dissector, but I still can't tell from
> your description how it would really benefit the CAN layer anyway.

As you can see in https://bugs.wireshark.org/bugzilla/attachment.cgi?id=14855 I
disabled the display of 'sll.pkttype == 4' to make the display of CAN content
look like it was before the switch to the SLL packet capture.

When I can disable the display of 'sll.pkttype == 4' by hand - why can't I
define this behavior with a preset like the 'byteswap' preset does?

> 
> > See https://www.kernel.org/doc/Documentation/networking/can.txt Chapter 3.2
> > 
> > Even other dissectors might run into problems when they now get the frame
> > two times (type 1 & 4) due to the switch to the PF_PACKET socket ...
> 
> This is where you may be confusing socket behavior with Wireshark frame
> formats and what libpcap (or other capture drivers) may be writing to the
> pcap[ng] file.

I'm not against writing both packet types (1 & 4) into the pcap[ng] file.
It's just the display of CAN frames in Wireshark becomes unusable when you see
pkttype 4 frames (sometimes). And I want to avoid that the Wireshark users
flood the mailing lists with "Since Wireshark 2.3 I get some CAN frames two
times - how can I get rid of it?" - and then we will answer to filter for
"!(sll.pkttype == 4)". This is not the user experience I would like to provide
after our great SocketCAN clean-up process.

> > > > ps. Is it possible to remove the 'Data' display from CAN frames with remote
> > > > transmission request (RTR)? RTR frames are really weird: RTR frames have NO
> > > > data bits on the wire EVEN when the data length value can carry values from
> > > > 0 to 8. Is there any chance to display this technical detail in Wireshark?
> > > 
> 
> Wireshark's first concern is displaying as much information as it has so
> users can potentially drawn their own conclusions about what they are
> seeing.  We could add "expert info" highlighting a RTR packet that has a
> non-zero data length.  But I don't think we should ever "hide" the data.

Fine with me.

But a RTR CAN frame can have a value of 0 .. 8 in struct can_frame.can_dlc but
the data length of RTR frames is always zero on the wire.

> > We still have a values 'xx bytes on the wire' which for RTR frames means:
> > Whatever the Length value is telling you - the data length on the wire is
> > zero.
> 
> This brings up something else I noticed - does CAN FD always put 64 bytes on
> the wire regardless of the "CAN" data length?

No.

Inside Linux the CAN frames are a fixed data structure:

CAN:   struct can_frame   -> sizeof(struct can_frame)   = 16
CANFD: struct canfd_frame -> sizeof(struct canfd_frame) = 72

But the length of the frame on the wire depends on the length value element
(can_dlc / len) - which also gives a reference of the valid data inside the
struct can[fd]_frame.data.

> Because that's what you're
> capture is showing.  I would think that will end up confusing many people
> because the "unused" bytes aren't labeled at all by Wireshark.  Are they
> supposed to be "padding"?

Yes they are. They should filled up with zero until the end of the data array.
When it is possible I would appreciate to display the trailing zeros in another
way/color. E.g. with a standard CAN frame with can_dlc = 6 the trailing two
bytes could be displayed differently.

---

      You are receiving this mail because:

• You are watching all bug changes.