://www.wireshark.org/docs/wsdg_html/#ChSrcContribute
On 3/18/24 3:46 AM, Oliver Hartkopp via Wireshark-dev wrote:
This patchset simplifies the CAN packet type detection as it focusses
on the rules to distiguish the different CAN CC/FD/XL frames from the
Linux kernel API.
Additionally some more content is shown
The different CAN frame types are defined by Linux SLL_P types in the
sll_protocol field and the length of the frame.
LINUX_SLL_P_CANXL:
The frame length for CAN XL can be 12 + 1 to 12 + 2048 (13 .. 2060) byte.
Additionally the CANXL_XLF flag has to be set.
LINUX_SLL_P_CAN and LINUX_SLL_P_CANFD:
Signed-off-by: Oliver Hartkopp
---
epan/dissectors/packet-socketcan.c | 13 -
epan/dissectors/packet-socketcan.h | 17 ++---
2 files changed, 18 insertions(+), 12 deletions(-)
diff --git a/epan/dissectors/packet-socketcan.c
b/epan/dissectors/packet-socketcan.c
index
The different CAN frame types are defined by Linux SLL_P types in the
sll_protocol field and the length of the frame.
LINUX_SLL_P_CANXL:
The frame length for CAN XL can be 12 + 1 to 12 + 2048 (13 .. 2060) byte.
Additionally the CANXL_XLF flag has to be set.
LINUX_SLL_P_CAN and LINUX_SLL_P_CANFD:
This patchset simplifies the CAN packet type detection as it focusses
on the rules to distiguish the different CAN CC/FD/XL frames from the
Linux kernel API.
Additionally some more content is shown in the dissector and the
CAN CiA 611-1 definitions have been cleaned up and extended by CiA.
Display the officially defined bits for CAN XL and CAN FD.
While CANXL_XLF is a mandatory set bit value for CAN XL frames
the CANFD_FDF bit might be set based on the used Linux kernel
version. So both bits present valuable content for the user.
Signed-off-by: Oliver Hartkopp
---
While the Classical CAN frame can transport only 8 byte of data the
4 bit data length code (DLC) has the ability to have a value range
from 0 to 15. To be able to send and receive DLC values from 9 to 15
the struct can_frame contains an additional len8dlc element which
can have values from 9 to 15
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
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 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 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
Hi all,
unfortunately I did not get any feedback from subscribing to this list
via https://www.wireshark.org/mailman/listinfo/wireshark-dev - so I'm
just sending my issue directly to the list.
I'm currently working on CAN XL support which is the latest CAN protocol
after Classical CAN and
17 matches
Mail list logo
