[Guy Harris <gharris@xxxxxxxxx>]

On Feb 12, 2024, at 4:04 AM, Oliver Hartkopp <socketcan@xxxxxxxxxxxx> wrote:

> I assume only ARM(64), X64 and Risc-V architectures will get in contact with CAN XL. And all these archs are little-endian.

And the version of your Lua dissector at

	https://github.com/hartkopp/canxl-utils/blob/main/wireshark/can_xl.lua

dissects multi-byte fields as little-endian.

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      |
		+---------------+---------------+---------+---------------------+

	or, equivalently, two little-endian fields in the form

		 1 1 1 1 1 1
		 5 4 3 2 1 0 9 8 6 6 5 4 3 2 1 0
		+---------+---------------------+
		|Reserved |       Priority      |
		+---------+---------------------+

		 1 1 1 1 1 1
		 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
		+---------------+---------------+
		|    Reserved   |     VCID      |
		+---------------+---------------+

	with the first of those two being in bytes 0 and 1 and the second of those in bytes 2 and 3, in which case a VCID value of 0x12 and a priority value of 0x345 would be, as a sequence of octets, 0x45 0x03 0x12 0x00

or

	a single little-median 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 7 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 |       Priority      |   Reserved    |     VCID      |
		+---------+---------------------+---------------+---------------+

	or, equivalently, two little-endian fields in the form

		 1 1 1 1 1 1
		 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
		+---------------+---------------+
		|    Reserved   |     VCID      |
		+---------------+---------------+

		 1 1 1 1 1 1
		 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
		+---------+---------------------+
		|Reserved |       Priority      |
		+---------+---------------------+

	with the first of those two being in bytes 0 and 1 and the second of those in bytes 2 and 3, in which case a VCID value of 0x12 and a priority value of 0x345 would be, as a sequence of octets, 0x12 0x00 0x45 0x03

(these being little-endian, the low-order, thus lower-numbered, bits are in the low-order, thus lower-address, bytes).

> The currently discussed struct canxl_frame is here:
> 
> https://lore.kernel.org/linux-can/20240128183758.68401-1-socketcan@xxxxxxxxxxxx/
> 
> struct canxl_frame {
> #if defined(__LITTLE_ENDIAN)
>        __u16 prio;   /* 11 bit priority for arbitration */
>        __u8  vcid;   /* virtual CAN network identifier */
>        __u8  __res0; /* reserved / padding must be set to zero */
> #elif defined(__BIG_ENDIAN)
>        __u8  __res0; /* reserved / padding must be set to zero */
>        __u8  vcid;   /* virtual CAN network identifier */
>        __u16 prio;   /* 11 bit priority for arbitration */
> #else
> #error "Unknown endianness"
> #endif

That appears to be the first of those two examples.