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
>
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 -
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 branc
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|
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 fdf4e
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 b
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_x
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/fl
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/hart
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 pack
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/eb6cfd8feae85b67529bb3c82
11 matches
Mail list logo
