Comment # 8
on bug 12687
from Oliver Hartkopp
(In reply to Michael Mann from comment #7)
> You're mixing two completely different pieces of functionality. Wireshark
> is a network analysis tool that happens to have hooks for doing capturing as
> well. Wireshark can only analyze what's been captured for it. After
> capturing, it then gets passed to the analysis/dissector portion.
ok.
>
> vcan0 is the "capture driver"
Just to make it clear: vcan0 is a "network device" with dev->type = ARPHRD_CAN
inside Linux.
A CAN netdevice (either 'real' CAN or 'virtual' CAN) can have a maximum
transfer unit (MTU) of 16 or 72 which reflects the sizeof(struct can_frame) or
the sizeof(struct canfd_frame).
When having a CAN FD capable interface (dev->mtu == 72) you might receive
either CAN or CAN FD frames on this interface.
> and it's providing the capture data in the
> socketCAN format as specified by LINKTYPE_ definition of:
> u32 CAN_ID
> u8 length
> u8 pad1
> u8 pad2
> u8 pad3
> u8 data[8];
>
> If vcan0 writes a "CANFD" frame, I think it looks like this:
> u32 CAN_ID
> u8 length
> u8 fd_flags
> u8 pad2
> u8 pad3
> u8 data[64];
IMO you can just assume to have a CAN FD interface and work with struct
canfd_frame (see PDF slides).
When your registered for ETH_P_CAN and ETH_P_CANFD with the LINUX_SSL_P_CAN[FD]
you will get both type of CAN frames.
And now comes the big trick (tada!):
When you get a socketbuffer with skb->len == sizeof(struct can_frame) you have
a 'classic' CAN frame, when skb->len == sizeof(struct canfd_frame) you have a
CAN FD frame,
As the length information is at the same position the only big difference in
the case of CAN FD is to display a 'CAN FD' info and the two bits 'BRS' and
'ESI' when set in the flags field.
> What I was hoping to get out of the capture file was a deterministic way to
> tell if CANFD was present. In the capture file you did provide, CANFD is
> piggybacking on the CAN format, so how is one supposed to know if its CAN or
> CANFD? Can we assume the fd_flags field will be non-zero? (It appears to
> be in all but the first packet of your capture). Are we to assume pad1
> should always be 0 with "regular" CAN?
I hope my description finally answered your questions.
> The capture file format is why I also mentioned the SLL types. vcan0
> doesn't appear to write capture files in that format (and there isn't a
> magic button to change it), so does that not need to be supported?
Just an additional hint. I compiled the tool tst-packet.c
(https://github.com/linux-can/can-tests/blob/master/tst-packet.c) from the CAN
tests repo at https://github.com/linux-can/can-tests .
Instead of setting
sll.sll_family = AF_PACKET;
sll.sll_ifindex = ifindex;
sll.sll_protocol = htons(ETH_P_CAN);
I changed the code to
sll.sll_family = AF_PACKET;
sll.sll_ifindex = ifindex;
sll.sll_protocol = htons(ETH_P_CANFD);
to receive CAN FD frames. But this had the problem that you get CAN frames OR
CAN FD frames - and not both of them at the same time (which is usual for CAN
FD capable network interfaces).
You are receiving this mail because:
- You are watching all bug changes.