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

[bugzilla-daemon@xxxxxxxxxxxxx]

Comment # 60 on bug 12687 from Oliver Hartkopp

(In reply to Guy Harris from comment #58)
> (In reply to Guy Harris from comment #57)
> > (In reply to Oliver Hartkopp from comment #56)
> > > > > > > 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.
> > 
> > So are you saying that, if a CANbus device sends a broadcast packet, the
> > sending hardware receives the packet it's sending and provides it as an
> > input packet, so that software reading from a PF_PACKET socket will see two
> > copies - a copy looped back in the networking stack, and a copy received by
> > the hardware?  That's not the case with regular LAN hardware, which doesn't
> > see its own transmissions, so that's not an issue for Ethernet, 802.11, etc..

Right!

> No, it looks as if the CAN networking stack loops back transmitted packets.

Not always.

The idea is to present a PACKET_BROADCAST packet to all consumers on the local
host when you receive a CAN frame from the outside OR a sent CAN frame really
hit the CAN bus. When sending a CAN frame the transmission can be delayed by
arbitration (due to CSMA/CA) or a CAN frame might never be sent out when
there's no CAN node which acknowledges the CAN frame.

For that reason CAN network devices have an interface flag IFF_ECHO which must
not be mixed with IFF_LOOPBACK. When a CAN netdevice has IFF_ECHO set, the
'echo' of sent CAN frames is done on *driver level* when the CAN frame is sent
out (TX OK interrupt). A minority of CAN drivers (e.g. slcan.c) do not provide
the functionality to 'echo' CAN frames as they have some kind of data stream
which does not allow to detect the correct transmission on the CAN bus.
Only for these CAN interfaces the CAN network layer stuff in
linux/net/can/af_can.c provides a 'echo' CAN frame for the local consumers on
the host.

http://lxr.linux.no/#linux+v4.7.2/net/can/af_can.c#L271

> So does dev_queue_xmit_nit(), so we get *two* loopback packets.
> 
> If the CAN layer is *guaranteed* to loop back all transmitted packets, that
> means that all PACKET_OUTGOING CAN packets can be discarded, unless there's
> a way to detect which PACKET_BROADCAST CAN packets are looped back and which
> are received, in which case we should discard the looped-back
> PACKET_BROADCAST packets so that the packet type reflects whether we sent
> the packet or not.

Now it gets sticky.

Whether a PACKET_BROADCAST CAN packet was sent from the local host or not is
distinguished by the reference to the originating socket. When there's no
originating socket (sk == NULL) the CAN frame comes from the outside:

http://lxr.linux.no/#linux+v4.7.2/net/can/raw.c#L126
http://lxr.linux.no/#linux+v4.7.2/net/can/raw.c#L172

But this detail is not visible on PF_PACKET sockets!

I did not take this detail into account so far.
IMO displaying PACKET_BROADCAST CAN frames would fit the user needs -
especially the outgoing CAN frames would have the correct TX timestamp then!!
That's why I suggest to disable the display of PACKET_OUTGOING by default.

If we want to provide the correctly timestamped PACKET_BROADCAST packets
*together* with the information about the CAN frames origin we would need to
get back to PF_CAN RAW sockets - with some more functionality:

http://lxr.linux.no/#linux+v4.7.2/Documentation/networking/can.txt#L631

---

      You are receiving this mail because:

• You are watching all bug changes.