Wireshark-bugs: [Wireshark-bugs] [Bug 12687] SocketCAN dissector does not support CAN FD
Date: Sun, 28 Aug 2016 23:21:04 +0000
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.
- Prev by Date: [Wireshark-bugs] [Bug 12790] Buildbot crash output: fuzz-2016-08-26-17937.pcap
- Next by Date: [Wireshark-bugs] [Bug 12687] SocketCAN dissector does not support CAN FD
- Previous by thread: [Wireshark-bugs] [Bug 12687] SocketCAN dissector does not support CAN FD
- Next by thread: [Wireshark-bugs] [Bug 12687] SocketCAN dissector does not support CAN FD
- Index(es):
- Get Wireshark
- Download
- Code of Conduct