On 2024-02-12 21:53, Guy Harris wrote:
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).
Excellent! That seems to be the right approach.
Many thanks!
I've also answered to your summary about the two potential approaches to
integrate the VCID here:
https://lore.kernel.org/linux-can/dec6ca6e-c768-4537-ac56-2cbafac583d4@xxxxxxxxxxxx/
I think this all fits together now with maintaining the existing 32 bit
prio value.
Best regards,
Oliver