Comment # 47
on bug 12687
from Guy Harris
(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.
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.
You are receiving this mail because:
- You are watching all bug changes.