Re: [Wireshark-dev] SocketCAN Support is broken in latest Wireshark-v4.3.0rc0-1430-g600de02805d0
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 (whether SOCK_RAW or SOCK_DGRAM)? The VCID is now part of the content in the struct skbuff data. So it is available everywhere, where a formerly CAN ID was accessible. Also on PACKET sockets. The VCID is no VLAN tag, nor uses it the VLAN specific skbuff elements in Linux. While it would have been possible to get a VLAN tag via PACKET sockets auxiliary cmsg mechanic you would never have be able to "write" the VCID in this way as user space application - and especially not as unprivileged user. And this is a vital requirement for logging and replaying CAN (CC/FD/XL) traffic. The question if we could invent some VLAN-like CAN interface (can0.123) is to be discussed. But there would be the need of a use-case of real CAN XL users. So far there is nothing to see. As CAN XL has up to 2048 bytes of payload it is also possible to do IP-over-CANXL. IMHO it would make sense to create a software ethernet device (maybe with VLAN tag) that interacts with a CAN XL network interface. But this is future work, again when there will be a use-case. 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
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 mainline upstream (net-next) and the CAN XL VCID support will now show up in Linux 6.9: https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=c83c22ec1493c0b7cc77327bedbd387e295872b6 Looking forward to see both improvements in the known distributions. 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
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: > > 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 (whether SOCK_RAW or SOCK_DGRAM)? ___ 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
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: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
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: 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. I can confirm that all type of CAN frames (CAN CC/FD/XL) are now displayed correctly with the latest Wireshark v4.3.0rc0-1528-g37937ef51444. As expected I just don't see the CAN FD flags due to my current (outdated) Debian libpcap 1.10.4. Great job!! Many thanks and 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
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 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).
Excellent! That seems to be the right approach.
Many thanks!
I've also answered to your summary about the two potential approaches to
integrate the VCID here:
https://lore.kernel.org/linux-can/dec6ca6e-c768-4537-ac56-2cbafac58...@hartkopp.net/
I think this all fits together now with maintaining the existing 32 bit
prio value.
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
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
Re: [Wireshark-dev] SocketCAN Support is broken in latest Wireshark-v4.3.0rc0-1430-g600de02805d0
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
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
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
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
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
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
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
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
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
Re: [Wireshark-dev] SocketCAN Support is broken in latest Wireshark-v4.3.0rc0-1430-g600de02805d0
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.) ___ 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
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. ___ 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
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);
> + canhdr->fd_flags &=
> (CANFD_FDF|CANFD_ESI|CANFD_BRS);
Yes, *that* was the underlying reason why FD frames weren't being recognized as
such; my trained-by-C-for-about-45-years brain sometimes automatically sticks a
~ after an &=, given that A &= ~B is the "clear the B bits" C idiom, so that ~
was there where it didn't belong. e50355893cd073c0 fixed that.
___
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
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 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; dissect CAN XL frames; hand LINKTYPE_LINUX_SLL frames with a protocol type of CAN XL to the SocketCAN dissector; so I think this issue will be resolved by the next Wireshark and libpcap releases. ___ 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
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 6.5.0-17-generic kernel, with sudo modprobe vcan sudo ip link add dev xlsrc type vcan sudo ip link set xlsrc mtu 2048 sudo ip link set up xlsrc However, doing cansend xlsrc 123##511223344 as per your mail gets a CAN interface is not CAN FD capable - sorry. error. However, if I do sudo ip link set xlsrc mtu 72 rather than sudo ip link set xlsrc mtu 2048 I *can* send a CAN FD frame. I'm not sure it will support CAN XL frames, however - I tried your command to generate a CAN XL frame, and it didn't appear to work. How do I construct a virtual CAN device that supports CAN classic, CAN FD, *and* CAN XL? Do I need a newer kernel version - or one with additional CAN XL support, built from modified source? > (is the CANFD_FDF flag not set?). It turns out it was getting cleared... ...by *libpcap*, due to a screwup on my part, so current libpcap is broken. I've checked in code to: look at the protocol field and force the right flag bits to be set or clear, based on the protocol field, even for CAN XL; arrange to put the CAN XL fields into little-endian byte order on big-endian machines (if the kernel I have on my QEMU simulated IBM z/Architecture desktop workstation :-) running Ubuntu can be made to support a virtual CAN device with CAN XL support, I can test that to make sure it works), so that there's no "this is in host byte order" nonsense; in https://github.com/the-tcpdump-group/libpcap/commit/fe47b89f2ca93bbea2e9bf7b307460e6c741d6e0 and a fix to the bug where CANFD_FDF was getting cleared in https://github.com/the-tcpdump-group/libpcap/commit/e50355893cd073c050786aad09db5aa9fdeb83cb and backported both of those to the 1.10 branch, so we (the libpcap and tcpdump developers) can put out a new libpcap 1.10.5 release. > 2) Add support to CAN XL, using the "is the 0x80 bit set in the fifth octet > of the header?" test, to epan/dissectors/packet-socketcan.c. *IF* I can set up a virtual CAN device so that I can generate a capture with CAN classic, CAN FD, *AND* CAN XL traffic, I'll make that change. > 3) Perhaps have libpcap forcibly set that flag based on the protocol field. That was done as part of the aforementioned changes, just to make *extra* sure the right flags are set, even if the kernel doesn't happen to set them. ___ 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
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
> https://github.com/hartkopp/canxl-utils/blob/main/wireshark/can_xl.lua
> where Wireshark displayed Classical CAN, CAN FD and CAN XL correctly.
>
> As I could see from Guys commit 39604740898f ("socketcan: support the
> CANFD_FDF flag for identifying CAN FD frames.") there has been a change from
> LINKTYPE_LINUX_SLL (worked and had different ETH_P_* types) to
> LINKTYPE_CAN_SOCKETCAN.
Presumably meaning that, as per the commit comment for
https://gitlab.com/wireshark/wireshark/-/commit/39604740898f
"This will be needed when the current main-branch libpcap is released, as it
uses LINKTYPE_CAN_SOCKETCAN rather than LINKTYPE_LINUX_SLL for ARPHRD_CAN
devices".
Yes, libpcap 1.10.2 includes the change in question:
https://github.com/the-tcpdump-group/libpcap/commit/4357b2d0edbb6371906af2179cf3497e6e1db78a
according to
https://github.com/the-tcpdump-group/libpcap/blob/master/CHANGES#L247
(which is in the section that begins at
https://github.com/the-tcpdump-group/libpcap/blob/master/CHANGES#L189
showing that it was introduced in 1.10.2).
This means that *any* capture done with a program using 1.10.2 or later -
tcpdump, Wireshark, etc. - on a Linux CANbus interface will use
LINKTYPE_CAN_SOCKETCAN.
It *also* means that a capture with those version of libpcap will have the
CANFD_FDF flag set on all frames that have LINUX_SLL_P_CANFD as the protocol
value provided by the PF_PACKET socket (that value is also what is copied into
the LINKTYPE_LINUX_SLL header).
This required that commit 39604740898f be made to Wireshark, to allow it to
read those captures.
was backported to the 1.10 branch - so capturing on
> I assume with the LINKTYPE_CAN_SOCKETCAN the correct display of the different
> CAN traffic types broke.
As long as the frames in question are either CAN classic or CAN FD frames, and
as long as the low-level capture code path (none of which is in Wireshark or
tcpdump, it's in the Linux kernel and libpcap) sets the CANFD_FDF flag on CAN
FD frames and doesn't set it on CAN classic frames, the display of those CAN
traffic types works.
Note, however, that there is no mention of CAN XL there.
Wireshark includes absolutely *no* code to handle CAN XL.
libpcap also includes no such code.
This means that CAN XL frames will either look as if they're CAN classic or CAN
FD frames; given the way libpcap works, they'll look as if they're CAN classic
frames, as they don't have ETH_P_CANFD as the protocol type.
The LINKTYPE_CAN_SOCKETCAN header looks like
https://www.tcpdump.org/linktypes/LINKTYPE_CAN_SOCKETCAN.html
The headers from Linux for various CAN frame types are, as taken from Linux's
can.h header:
/**
* struct can_frame - Classical CAN frame structure (aka CAN 2.0B)
* @can_id: CAN ID of the frame and CAN_*_FLAG flags, see canid_t definition
* @len: CAN frame payload length in byte (0 .. 8)
* @can_dlc: deprecated name for CAN frame payload length in byte (0 .. 8)
* @__pad:padding
* @__res0: reserved / padding
* @len8_dlc: optional DLC value (9 .. 15) at 8 byte payload length
*len8_dlc contains values from 9 .. 15 when the payload length is
*8 bytes but the DLC value (see ISO 11898-1) is greater then 8.
*CAN_CTRLMODE_CC_LEN8_DLC flag has to be enabled in CAN driver.
* @data: CAN frame payload (up to 8 byte)
*/
struct can_frame {
canid_t can_id; /* 32 bit CAN_ID + EFF/RTR/ERR flags */
union {
/* CAN frame payload length in byte (0 .. CAN_MAX_DLEN)
* was previously named can_dlc so we need to carry that
* name for legacy support
*/
__u8 len;
__u8 can_dlc; /* deprecated */
} __attribute__((packed)); /* disable padding added in some ABIs */
__u8 __pad; /* padding */
__u8 __res0; /* reserved / padding */
__u8 len8_dlc; /* optional DLC for 8 byte payload length (9 .. 15) */
__u8 data[CAN_MAX_DLEN] __attribute__((aligned(8)));
};
/*
* defined bits for canfd_frame.flags
*
* The use of struct canfd_frame implies the FD Frame (FDF) bit to
* be set in the CAN frame bitstream on the wire. The FDF bit switch turns
* the CAN controllers bitstream processor into the CAN FD mode which creates
* two new options within the CAN FD frame specification:
*
* Bit Rate Switch - to indicate a second bitrate is/was used for the payload
* Error State Indicator - represents the error state of the transmitting node
*
* As the CANFD_ESI bit is internally generated by the transmitting CAN
* controller only the CANFD_BRS bit is relevant for real CAN controllers when
* building a CAN FD frame for transmission.
