Comment # 52
on bug 12687
from Michael Mann
(In reply to Oliver Hartkopp from comment #50)
> Created attachment 14857 [details]
> Screenshot from Wireshark with Patchset 10
>
> The picture shows two issues aka space for improvements :-)
>
> 1. For CANFD protocol the 'FD Flags' are no optional flags which should be
> expanded or collapsed in the "Controller Area Network FD" section. The 'Bit
> Rate Setting' and 'Error State Indicator' flags should always be placed
> below the 'Extended Flag' and before the 'Frame-Length'.
All fields are displayed as they appear in the frame. The 'FD flags' are
effectively a field after the initial CAN ID/flags and length fields, which is
why they are placed in their current position. I also think it makes sense to
group them because they are their own entity.
>
> 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.
> The IFF_ECHO mechanism for CAN interfaces 'echoes' all sent frames on netdev
> driver level, so all type 4 frames will show up as type 1 frames anyway.
> My suggestion would be to a new Controller Area Network preference (like the
> 'Byte-swap the CAN ID/flags flied').
How are type 4 frames represented? If there are some in the provided capture
(attachment 14858 [details]) I see nothing in the frame that would distinguish type 4
frames. The byte swapping preference is already present in the patch.
> E.g. 'Enable display of Packet Type 4 (sent from me)' which is disabled by
> default.
>
> 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?
It's removed from the Info column, and I think that's as far as I want to go.
Wireshark wants to show as much information as possible as we're never quite
sure what a user is trying to debug. If an RTR frame shouldn't have data
bytes, then don't have the capture driver write the data bytes. If a capture
driver is writing RTR frames with data "by mistake", than showing the bytes in
Wireshark can point out that mistake.
You are receiving this mail because:
- You are watching all bug changes.
