[bugzilla-daemon@xxxxxxxxxxxxx]

Comment # 53 on bug 12687 from Oliver Hartkopp

(In reply to Michael Mann from comment #52)
> (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.

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.

> > 
> > 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?

Identically. They are the same. They just have Packet type 4.

>  If there are some in the provided
> capture (attachment 14858 [details]) I see nothing in the frame that would
> distinguish type 4 frames.

They are type 4 :-)

And not type 1.

> The byte swapping preference is already present
> in the patch.

I know. This was just an example.
I suggested to add a new preference "Display type 4 (Sent by us) packets" which
is disabled by default:

> > E.g. 'Enable display of Packet Type 4 (sent from me)' which is disabled by
> > default.

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 ...

> > 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.

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.

---

      You are receiving this mail because:

• You are watching all bug changes.