Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

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

Date: Mon, 29 Aug 2016 23:30:33 +0000

Comment # 58 on bug 12687 from
(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..

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

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.


You are receiving this mail because:
  • You are watching all bug changes.