On Feb 12, 2024, at 11:09 AM, Oliver Hartkopp <socket...@hartkopp.net> wrote:
> On 2024-02-12 18:54, Guy Harris wrote: > >> Thus, I specified that all multi-byte fields in the CAN XL header, in >> LINKTYPE_CAN_SOCKETCAN packets, are little-endian (unlike the header for CAN >> classic and CAN FD, in which the CAN ID/flags field is big-endian): >> https://www.tcpdump.org/linktypes/LINKTYPE_CAN_SOCKETCAN.html >> So the question is whether the first 4 bytes of the CAN XL header are: >> a single little-endian field in the form >> >> 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 >> 1 0 9 8 6 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 >> +---------------+---------------+---------+---------------------+ >> | Reserved | VCID |Reserved | Priority | >> +---------------+---------------+---------+---------------------+ > > Yes! This is the correct plan. > > But in fact this is a 32 bit value. Yes, that's exactly what the figure I drew showed it as, and that's what a single field containing 4 bytes is on any machine likely to run {Linux,libpcap,Wireshark} would be. > Currently the first 4 bytes in the Wireshark data window (in the bottom > right) for CAN CC & CAN look like this for CAN ID 0123: > > 00 00 01 23 (which looks like big endian) That's because, in LINKTYPE_CAN_SOCKETCAN captures, that field, *in CAN classic and CAN FD captures* is *defined* to be big-endian, and libpcap *explicitly puts it into big-endian order before handing the packet to the caller*. > And CAN XL with VCID 0xCD and Prio 0x242 looks like this > > 00 CD 02 42 (which also looks like big endian, right?) That's because libpcap doesn't currently distinguish between CAN XL and the other packet types, and thus puts the first 4 bytes of the SocketCAN header into big-endian byte order. It doesn't *have* to do that and, in fact, the libpcap code on the tip of the main and 1.10 branches puts that field into *little-endian* order for CAN XL. However, if the goal is to allow programs that read LINKtYPE_CAN_SOCKETCAN captures to be able to handle both captures made with the existing libpcap *and* with the upcoming libpcap, the right way to handle this would be to have libpcap put those 4 bytes into *big-endian* byte order and put the *other two* multi-byte integral-valued fields - the payload length and the acceptance field - into *little-endian* byte order, as that's the order they'd be in with the libpcap 1.10.4 code if capturing on a little-endian machine. I will update the libpcap code to put the first 4-byte field in the CAN XL header into big-endian order, and update the LINKTYPE_CAN_SOCKETCAN spec to indicate that it's big-endian (but not that the *other* multi-byte fields are). ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
