Wireshark-bugs: [Wireshark-bugs] [Bug 12687] SocketCAN dissector does not support CAN FD
Comment # 54
on bug 12687
from Michael Mann
(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.
>
> > >
> > > 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.
> 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.
> > > 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.
> 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? 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"?
Is this a Linux Cooked Capture "feature"?
You are receiving this mail because:
- You are watching all bug changes.
