On 15.02.24 11:43, Guy Harris wrote:
On Feb 15, 2024, at 12:01 AM, Oliver Hartkopp wrote:
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=c83c22ec1493c0b7cc77327bedbd387e295872b6
How does one request that the VCID information be provided on a PF_PACKET
socket
On 2024-02-15 01:03, Guy Harris wrote:
Wireshark 4.2.3, which includes the SocketCAN changes, has just been released.
Presumably, various packagers of Wireshark 4.2.x will pick it up at some point.
Many thanks for the information and your support!
Marc created a pull-request for Linux
On Feb 15, 2024, at 12:01 AM, Oliver Hartkopp wrote:
> Marc created a pull-request for Linux mainline upstream (net-next) and the
> CAN XL VCID support will now show up in Linux 6.9:
>
>
Wireshark 4.2.3, which includes the SocketCAN changes, has just been released.
Presumably, various packagers of Wireshark 4.2.x will pick it up at some point.
___
Sent via:Wireshark-dev mailing list
Archives:
Hello Guy,
On 2024-02-13 01:28, Guy Harris wrote:
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:
On 2024-02-12 21:53, Guy Harris wrote:
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
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:
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
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
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
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
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
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 &=
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
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
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 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
On Feb 11, 2024, at 1:19 PM, Oliver Hartkopp wrote:
> Shouldn't LINUX_SLL_P_CANXL be set to 0x000E like in
> include/uapi/linux/if_ether.h for ETH_P_CANXL instead of 0x000F here?
Fixed in libpcap commit 6735956299c5fbc803255a14fa493886e3cf81c6.
On Feb 11, 2024, at 1:53 PM, Oliver Hartkopp wrote:
> 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);
> +
So the libpcap main and 1.10 branches include changes to
not clear the CANFD_FDF flag for FD frames;
put the multi-byte fields in the CAN XL header into little-endian byte
order;
and the Wireshark main and 4.2 branches include changes to
treat CAN frames without the
On Feb 6, 2024, at 1:24 PM, Guy Harris wrote:
> 1) Provide a capture file that contains CAN FD frames but that isn't
> correctly dissected, so we can see *why* the FD frames aren't being detected
OK, I managed to create the virtual CAN device on Ubuntu 22.04, recently
updated, with a
On Feb 6, 2024, at 10:42 AM, Oliver Hartkopp wrote:
> I'm currently working on CAN XL support which is the latest CAN protocol
> after Classical CAN and CAN FD.
>
> With Wireshark 3.6 I was able to add this dissector for CAN XL
>
22 matches
Mail list logo
