Comment # 36
on bug 12687
from Michael Mann
(In reply to Guy Harris from comment #35)
> > 2. Enhance the PDU that contain the current CAN frames to be able to
> > transport CAN FD frames too. This kind of tunnelling from libpcap to
> > Wireshark is currently done with the CANFD_USE bit - and that's why this bit
> > must not show up in the Wiresharks proto bits.
>
> "Currently" presumably meaning "with your changes to pcap-can-linux.c".
>
> CANFD_USE is defined to be 0x04, which, in the CAN ID/flags field, is one of
> the CAN ID bits; is that bit guaranteed not to be set in the CAN ID?
>
I have not looked at the libpcap changes, but the CANFD_USE flag (with value of
0x4) is NOT part of the CAN ID field (see comment #7 or comment #33 for frame
format description). CAN_FD is populating the byte after the length field with
flag values, including CANFD_USE.
This is currently how https://code.wireshark.org/review/16787 is detecting
CANFD packets (still needs to be rebased with latest
LINKTYPE_CAN_SOCKETCAN_BIGENDIAN/HOST_ENDIAN changes). To me the current
debate is if that method should stay or a new linktype for CANFD developed.
And if it is developed, the libpcap code should provide a consistent endianness
so that we don't end up with 2 more link types.
But I would also like to note that libpcap isn't the only software using this
format. There have been questions on -dev mailing list that imply "CAN
capture drivers" are being written with this format in mind. I myself have
also written "CAN capture drivers" with this format (basically reverse
engineering from SocketCAN dissector).
You are receiving this mail because:
- You are watching all bug changes.
