Comment # 9
on bug 12687
from Michael Mann
(In reply to Oliver Hartkopp from comment #8)
> 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.
> 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,
We are still talking two entirely different languages. The layers you speak of
are not passed to any information Wireshark has (Wireshark does not have socket
information). Wireshark is not passed the struct canfd_frame (or technically
the can_frame). The "file format" more closely resembles the can_frame, but
the "data" field is not guaranteed to be 8.
Do you have any capture files where data length > 8? I didn't see any frames
like that in the capture provided.
> IMO you can just assume to have
> a CAN FD interface and work with struct canfd_frame (see PDF slides).
I think this can "work", but there still isn't a way to distinguish CAN and
CANFD frames if both are part of the same capture file (again, because there
isn't anything in the "file format" that differiates them). So you can either
have one or the other from Wireshark's perspective.
You are receiving this mail because:
- You are watching all bug changes.