Comment # 49
on bug 12687
from Oliver Hartkopp
(In reply to Guy Harris from comment #47)
> (In reply to Oliver Hartkopp from comment #45)
> > Created attachment 14854 [details]
> > Screenshot WS2.0.5 with new libpcap
> >
> > Wireshark 2.0.5 receives additional leading 16 byte (with Link Layer address
> > type, packet type, etc)
>
> Good! That's exactly what it's supposed to do; that's the DLT_LINUX_SLL
> header.
Fine :-)
> The important part is the "Protocol" field, which will be 0x000C for
> "classic" CAN and 0x000D for CAN FD.
>
> > and picks a wrong CAN ID from the content (0x03010000 instead of 0x00000123)
>
> That's because Wireshark 2.0.5, just like all Wireshark versions before it,
> assume that the CAN ID/flags field is *always* big-endian, even when it's
> been captured with pcap-linux.c rather than pcap-can-linux.c. You will need
> a recent build from the 2.0, 2.2, or master branch to get it to dissect it
> as little-endian; the fixes to dissect it as little-endian in this case will
> be in the 2.0.6 release and the 2.2 release, which are currently scheduled
> for 2016-09-08 and 2016-08-31 (2.2.0rc2)/2016-09-07 (2.2.0 final release),
> respectively.
Ok. At least this brings a dependency to update both (libpcap and Wireshark) to
this new 'cleaned' version together. I assumed the change of libpcap would work
with older Wiresharks too ...
I'm personally fine with it. The old pcap files can still be processed with the
new Wireshark.
You are receiving this mail because:
- You are watching all bug changes.
