On Feb 12, 2024, at 4:04 AM, Oliver Hartkopp <socket...@hartkopp.net> 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-socket...@hartkopp.net/
>
> 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.
___________________________________________________________________________
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
