Wireshark-bugs: [Wireshark-bugs] [Bug 12687] SocketCAN dissector does not support CAN FD
Date: Mon, 29 Aug 2016 20:14:34 +0000

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

If so, that should be handled in linux_check_direction() in pcap-linux.c.  It
already handles the loopback device providing two copies of all packets; it
should also filter out one of the copies of the broadcast packets.

> I'm not against writing both packet types (1 & 4) into the pcap[ng] file.
> It's just the display of CAN frames in Wireshark becomes unusable when you
> see pkttype 4 frames (sometimes). And I want to avoid that the Wireshark
> users flood the mailing lists with "Since Wireshark 2.3 I get some CAN
> frames two times - how can I get rid of it?"

They won't say that.

They'll say "since version XXX of my distribution I get some CAN frames two
times - how can I get rid of it?", because version XXX of that distribution has
libpcap 1.8.x or 1.9.x (whichever version ends up getting the changes to use
PF_PACKET sockets for all CANbus capturing), and the previous version has the
1.7.x or whatever.  That'll show up with *all* versions of Wireshark that
support CAN packets.


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