Update LINKTYPE_CAN_SOCKETCAN #37
Conversation
hartkopp
commented
Mar 21, 2024
hartkopp
commented
- introduce CAN CC as the new naming for Classical CAN and CAN2.0B
- point out that CAN CC and CAN FD are only distinguished by their length
- fix the description of the CANFD_FDF meaning
- introduce the Len 8 DLC value for CAN CC
- make clear that RTR and error message frames are only CAN CC frames
- introduce CAN CC as the new naming for Classical CAN and CAN2.0B - point out that CAN CC and CAN FD are only distinguished by their length - fix the description of the CANFD_FDF meaning - introduce the Len 8 DLC value for CAN CC - make clear that RTR and error message frames are only CAN CC frames Signed-off-by: Oliver Hartkopp <[email protected]>
| a CAN FD frame. | ||
| <li><code>CANFD_BRS</code> (<code>0x01</code>) - bit rate switch (second bitrate for payload data).</li> | ||
| <li><code>CANFD_ESI</code> (<code>0x02</code>) - error state indicator of the transmitting node.</li> | ||
| <li><code>CANFD_FDF</code> (<code>0x04</code>) - mark CAN FD for dual use of struct canfd_frame.</li> |
There was a problem hiding this comment.
So is CANFD_FDF a flag to care about, or was its introduction not useful?
I.e., is the only test that should be used to distinguish between CAN CC and CAN FD frames the frame size, in which case CANFD_FDF does not appear to serve any useful purpose, or is there some reason why software should care about the CANFD_FDF flag?
Note also that there is no requirement that a frame using this link-layer type was delivered to a program writing the frame by a Linux kernel; at least two of the non-pcap/non-pcapng file formats that Wireshark can read are treated by Wireshark's capture-file-reading library as providing LINKTYPE_CAN_SOCKETCAN-format frames.
There was a problem hiding this comment.
Three of those formats, to be precise. See this comment for more details.
There was a problem hiding this comment.
So is
CANFD_FDFa flag to care about, or was its introduction not useful?
It has another functionality than you obviously expected.
I.e., is the only test that should be used to distinguish between CAN CC and CAN FD frames the frame size, in which case
CANFD_FDFdoes not appear to serve any useful purpose, or is there some reason why software should care about theCANFD_FDFflag?
CAN CC and CAN FD are different in many points:
- CAN CC: Has RTR, is limited to 8 data byte and therefore has DLC values more than 8
- CAN FD: Has BRS/ESI and a non-linear data length / DLC mapping
And the only test that should be used to distinguish between CAN CC and CAN FD frames is the frame size (16/72).
The CANFD_FDF flags is some kind of bonus for the CAN FD frame structure users - nothing more.
Note also that there is no requirement that a frame using this link-layer type was delivered to a program writing the frame by a Linux kernel; at least two of the non-pcap/non-pcapng file formats that Wireshark can read are treated by Wireshark's capture-file-reading library as providing
LINKTYPE_CAN_SOCKETCAN-format frames.
Looking into the former and current Wireshark code makes it pretty clear that the frame size was always used to distinguish between CAN CC and CAN FD frames. Which is fine. So nothing changes, right?
The handling around CANFD_FDF is wrong as CANFD_FDF is just a bonus as described above - and not reliable indicator for CAN CC/FD.
There was a problem hiding this comment.
Note that, currently, Wireshark handles non-pcap/pcapng CAN capture files, such as Vector Informatik BLF files, BUSMASTER files, dumps from Linux candump, and log files from CLx000 CAN loggers from CSS Electronics, by constructing a fake SocketCAN header from whatever metadata is available in the native file format and prepending that header to the CAN frame data.
This means that, if those files were to be read by a program in the Wireshark suite and written out as a pcap or pcapng file, there would be LINKTYPE_CAN_SOCKETCAN packets without the padding Linux SocketCAN adds. The frame size check can't be used for those packets; the flags have to be checked
Either the spec should allow for that, or the Wireshark code that writes LINKTYPE_CAN_SOCKETCAN packets should pad CAN CC frames to 16 octets (including the SocketCAN header) and pad CAN FD frames to 72 octets (again, including the SocketCAN header).
|
This needs rebasing, as the terminology was updated in f20d134. |
|
Oh, I wasn't aware that this PR was still open ... |
