On Feb 12, 2024, at 11:09 AM, Oliver Hartkopp <socketcan@xxxxxxxxxxxx> 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).