Re: [Wireshark-dev] SocketCAN Support is broken in latest Wireshark-v4.3.0rc0-1430-g600de02805d0

[Guy Harris]

On Feb 12, 2024, at 1:15 PM, Oliver Hartkopp  wrote:

> Excellent! That seems to be the right approach.

OK, so:

fix libpcap to put the priority/VCID field in big-endian order in CAN 
XL frames:


https://github.com/the-tcpdump-group/libpcap/commit/eb6cfd8feae85b67529bb3c82f6a97bfd98c73f3
 in the main branch


https://github.com/the-tcpdump-group/libpcap/commit/23904ebe85c4556b77578fd8d61ef82d9bab62b4
 in the 1.10 branch

change Wireshark to treat that field as big-endian:


https://gitlab.com/wireshark/wireshark/-/commit/38a29e82cc96f727aeab7f10e751fa6e8d5e45b6
 in the main branch


https://gitlab.com/wireshark/wireshark/-/commit/b763663904b6101764c414056b9248803569d6d2
 in the 4.2 branch

update the LINKTYPE_CAN_SOCKETCAN spec to reflect all that:


https://github.com/the-tcpdump-group/tcpdump-htdocs/commit/9c357d9ed6d214bd2fc44850138c2f8861782d88

and it'll show up on the site within 24 hours.

___
Sent via:Wireshark-dev mailing list 
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

[Wireshark-dev] Sorting "Number of Packets" / SCTP Associations as strings ?!...

[Cristian Constantin via Wireshark-dev]

Hi,

Now, come on guys, really?? Sorting this field as strings?...

OS: Ubuntu
cco@DEU1145:~$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=22.04
DISTRIB_CODENAME=jammy
DISTRIB_DESCRIPTION="Ubuntu 22.04.3 LTS"

Wireshark version as shown by "About Wireshark":
Version 3.6.2 (Git v3.6.2 packaged as 3.6.2-2)

Copyright 1998-2022 Gerald Combs  and
contributors. License GPLv2+: GNU GPL version 2 or later
 This is free software; see
the source for copying conditions. There is NO warranty; not even for
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled (64-bit) using GCC 11.2.0, with Qt 5.15.2, with libpcap, with
POSIX capabilities (Linux), with libnl 3, with GLib 2.71.2, with zlib
1.2.11, with Lua 5.2.4, with GnuTLS 3.7.3 and PKCS #11 support, with
Gcrypt 1.9.4, with MIT Kerberos, with MaxMind DB resolver, with
nghttp2 1.43.0, with brotli, with LZ4, with Zstandard, with Snappy,
with libxml2 2.9.12, with libsmi 0.4.8, with QtMultimedia, without
automatic updates, with SpeexDSP (using system library), with Minizip.

Running on Linux 6.5.0-15-generic, with 12th Gen Intel(R) Core(TM)
i7-1270P (with SSE4.2), with 31753 MB of physical memory, with GLib
2.72.4, with zlib 1.3, with Qt 5.15.3, with libpcap 1.10.1 (with
TPACKET_V3), with c-ares 1.18.1, with GnuTLS 3.7.3, with Gcrypt 1.9.4,
with nghttp2 1.43.0, with brotli 1.0.9, with LZ4 1.9.3, with Zstandard
1.4.8, with libsmi 0.4.8, with light display mode, without HiDPI, with
LC_TYPE=en_US.UTF-8, binary plugins supported (19 loaded).

Wireshark is Open Source Software released under the GNU General Public License.

Thanks,
Cristian Constantin
___
Sent via:Wireshark-dev mailing list 
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

Re: [Wireshark-dev] SocketCAN Support is broken in latest Wireshark-v4.3.0rc0-1430-g600de02805d0

[Oliver Hartkopp via Wireshark-dev]

On 2024-02-12 18:54, Guy Harris wrote:

On Feb 12, 2024, at 4:04 AM, Oliver Hartkopp  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.


Yes, that was a PoC based on the CAN XL Lua code I got from a colleague. 
And I simply wanted to have some valid output on my X86_64 Laptop.


I'm not a Lua expert with introducing BE/LE data structures in the first 
4 byte and therefore I did the 16 bit shifting and masking to get the 
VCID from the then 32 bit prio.



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. Analogue to the can_id field in CAN 
CC and CAN FD:


 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
+---+
|x|y|z|CAN Identifier   |
+---+

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)

And CAN XL with VCID 0xCD and Prio 0x242 looks like this

00 CD 02 42 (which also looks like big endian, right?)

When the AF field is set to 0x11223344 then this 32 bit value is 
represented in little endian:


   00 cd 02 42 81 00 0a 00 44 33 22 11 00 00 00 00
0010   00 00 00 00 00 00

(all values from latest Wireshark v4.3.0rc0-1521-g0e5416efbe94)

I still use the libpcap 1.10.4 from Debian Trixie.

So if you generally convert the first 4 bytes to big endian why should 
there be an exception for CAN XL?




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


These octets would have been the correct little endian representation.


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


Ugh. No.


(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(__LITT

Re: [Wireshark-dev] SocketCAN Support is broken in latest Wireshark-v4.3.0rc0-1430-g600de02805d0

[Guy Harris]

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

Re: [Wireshark-dev] SocketCAN Support is broken in latest Wireshark-v4.3.0rc0-1430-g600de02805d0

[Guy Harris]

On Feb 12, 2024, at 4:04 AM, Oliver Hartkopp  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 
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

Re: [Wireshark-dev] SocketCAN Support is broken in latest Wireshark-v4.3.0rc0-1430-g600de02805d0

[Oliver Hartkopp via Wireshark-dev]

On 12.02.24 10:34, Guy Harris wrote:

On Feb 12, 2024, at 1:21 AM, Guy Harris  wrote:


How many processors - as in "number of CPUs", not "number of instruction set 
architectures" - capturing CANbus traffic and producing SocketCAN headers are big-endian, and 
how many are little-endian?


To be more specific, how many processors - as in "number of CPUs", not "number of 
instruction set architectures" - capturing *CAN XL* traffic and producing SocketCAN headers 
are big-endian, and how many are little-endian?


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


I only had the data structure example in big-endian to increase the 
readability.


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
__u8  flags;  /* additional flags for CAN XL */
__u8  sdt;/* SDU (service data unit) type */
__u16 len;/* frame payload length in byte */
__u32 af; /* acceptance field */
__u8  data[CANXL_MAX_DLEN];
};

To maintain the filtering of the 11 bit CAN identifier (inside the 
uint32 canid_t in Classical CAN and CAN FD) the 11 bit PRIO value has to 
share the position of these 11 bits.


Therefore the somewhat ugly endian handling is to be introduced.

Or would you suggest to generally add the vcid content into the uint32 
space by shifting and masking, like in this previous suggested patch?


https://lore.kernel.org/linux-can/20240106192836.4716-1-socket...@hartkopp.net/

Best regards,
Oliver
___
Sent via:Wireshark-dev mailing list 
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

Re: [Wireshark-dev] SocketCAN Support is broken in latest Wireshark-v4.3.0rc0-1430-g600de02805d0

[Oliver Hartkopp via Wireshark-dev]

Hello Guy,

On 2024-02-12 08:17, Guy Harris wrote:

On Feb 11, 2024, at 1:19 PM, Oliver Hartkopp  wrote:


Although the Priority 0x242 and the VCID 0xCD are correctly displayed in the 
grey line the values below that line seem to be wrong (Priority 52480, VCID 2).


Fixed in Wireshark change fdf4ecdb4aea61f6e557d75172d27ca0ffea79d7.

(All fixes mentioned have been backported to the 1.10 branch for libpcap and 
the 4.2 branch for Wireshark.)


I'm sorry but the fix went into the wrong direction and removed the 
formerly correct values in the grey'ed line.


In the attached screenshot you can see from the plain data

   00 cd 02 42 81 00 0a 00 af af af af 00 00 00 00
0010   00 00 00 00 00 00

VCID = 0xCD
PRIO = 0x0242 (here in correct in big endian)
Flags = 0x81 == CANXL_XLF and CANXL_SEC bits are set
SDT = 0x00
Length = 0x000A (is dec 10 in little endian)
AF = 0xAFAFAFAF

So the first three items need to be fixed.
CANXL_XLF (0x80) is missing in the flags.

I've seen that you do some bit-shifting and masking on proto_vcid in 
your latest patch.


I did so in my PoC too, when prio was still a 32 bit value like canid_t.

But now there are separate elements inside the first 32 bits (also in 
big endian expression):


  __u8  __res0; /* reserved / padding must be set to zero */
  __u8  vcid;   /* virtual CAN network identifier */
  __u16 prio;   /* 11 bit priority for arbitration */

and prio is only 16 bits.

Not sure what's the best way to get further here.

Many thanks,
Oliver___
Sent via:Wireshark-dev mailing list 
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

Re: [Wireshark-dev] SocketCAN Support is broken in latest Wireshark-v4.3.0rc0-1430-g600de02805d0

[Oliver Hartkopp via Wireshark-dev]

Sorry for the noise.

This issue seems to be fixed in libpcap in commit e50355893cd073c0 
("socketcan: *really* fix CAN FD support.")



-   canhdr->fd_flags &= 
~(CANFD_FDF|CANFD_ESI|CANFD_BRS);
+   canhdr->fd_flags &= 
(CANFD_FDF|CANFD_ESI|CANFD_BRS);


:-)

Thanks!

On 2024-02-11 22:48, Oliver Hartkopp wrote:

Another small issue:

On 2024-02-09 23:56, Guy Harris wrote:


and the Wireshark main and 4.2 branches include changes to

treat CAN frames without the CANXL_XLF flag or the CANFD_FDF flag 
as FD frames if they're exactly 72 bytes long, to work around the 
(fixed in the main and 1.10 branches) libpcap bug where CANFD_FDF is 
unintentionally cleared;


Is it possible that the work around for the libpcap bug (set the 
CANFD_FDF flag for non-XL frames with a length of 72 bytes) clears the 
other bits in the CAN FD flags field?


The CANFD_BRS and CANFD_ESI bits are not visible anymore.

CANFD_FDF is only set in the CAN FD frames in recent kernels. In older 
kernels only the PDU length of 72 is the indicator. But BRS/ESI were 
always supported.


Best regards,
Oliver

___
Sent via:Wireshark-dev mailing list 
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

Re: [Wireshark-dev] SocketCAN Support is broken in latest Wireshark-v4.3.0rc0-1430-g600de02805d0

[Oliver Hartkopp via Wireshark-dev]

Another small issue:

On 2024-02-09 23:56, Guy Harris wrote:


and the Wireshark main and 4.2 branches include changes to

treat CAN frames without the CANXL_XLF flag or the CANFD_FDF flag as FD 
frames if they're exactly 72 bytes long, to work around the (fixed in the main 
and 1.10 branches) libpcap bug where CANFD_FDF is unintentionally cleared;


Is it possible that the work around for the libpcap bug (set the 
CANFD_FDF flag for non-XL frames with a length of 72 bytes) clears the 
other bits in the CAN FD flags field?


The CANFD_BRS and CANFD_ESI bits are not visible anymore.

CANFD_FDF is only set in the CAN FD frames in recent kernels. In older 
kernels only the PDU length of 72 is the indicator. But BRS/ESI were 
always supported.


Best regards,
Oliver
___
Sent via:Wireshark-dev mailing list 
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

Re: [Wireshark-dev] SocketCAN Support is broken in latest Wireshark-v4.3.0rc0-1430-g600de02805d0

[Guy Harris]

On Feb 12, 2024, at 1:21 AM, Guy Harris  wrote:

> How many processors - as in "number of CPUs", not "number of instruction set 
> architectures" - capturing CANbus traffic and producing SocketCAN headers are 
> big-endian, and how many are little-endian?

To be more specific, how many processors - as in "number of CPUs", not "number 
of instruction set architectures" - capturing *CAN XL* traffic and producing 
SocketCAN headers are big-endian, and how many are little-endian?
___
Sent via:Wireshark-dev mailing list 
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

Re: [Wireshark-dev] SocketCAN Support is broken in latest Wireshark-v4.3.0rc0-1430-g600de02805d0

[Guy Harris]

On Feb 12, 2024, at 12:07 AM, Oliver Hartkopp  wrote:

> I'm sorry but the fix went into the wrong direction and removed the formerly 
> correct values in the grey'ed line.
> 
> In the attached screenshot you can see from the plain data
> 
>    00 cd 02 42 81 00 0a 00 af af af af 00 00 00 00
> 0010   00 00 00 00 00 00
> 
> VCID = 0xCD
> PRIO = 0x0242 (here in correct in big endian)

...

> But now there are separate elements inside the first 32 bits (also in big 
> endian expression):

How many processors - as in "number of CPUs", not "number of instruction set 
architectures" - capturing CANbus traffic and producing SocketCAN headers are 
big-endian, and how many are little-endian?
___
Sent via:Wireshark-dev mailing list 
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