On Feb 6, 2024, at 1:24 PM, Guy Harris <ghar...@sonic.net> 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 <wireshark-dev@wireshark.org>
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
