Update LINKTYPE_CAN_SOCKETCAN #40
Conversation
hartkopp
commented
Jan 17, 2025
hartkopp
commented
- 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
- fix typos: Classical CAN and CANXL_SEC
- 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 - fix typos: Classical CAN and CANXL_SEC Signed-off-by: Oliver Hartkopp <[email protected]>
|
See also the discussion of this issue in Wireshark merge request 18710, and this comment from pull request #37, which notes that LINKTYPE_CAN_SOCKETCAN is currently used by Wireshark when it writes out, as pcap or pcapng files, captures in non-pcap/pcapng format from some CAN tools. I.e., there's no guarantee that a LINKTYPE_CAN_SOCKETCAN capture originated from a Linux capture. |
|
A tool from Vector Informatik also writes pcap/pcapng files with LINKTYPE_CAN_SOCKETCAN, as per this comment from pull request #1035. |
|
See also the-tcpdump-group/libpcap#1052, where the |
| <li><code>CANFD_FDF</code> (<code>0x04</code>) - if set, the frame is a CAN FD frame; if not set, | ||
| the frame may be a CAN CC frame or a CAN FD frame.</li> | ||
| <li>if the frame size (including the header and padding) is 16, it's a CAN CC frame | ||
| <li>if the frame size (including the header and padding) is 72, it's a CAN FD frame |
There was a problem hiding this comment.
What if the frame size is neither 16 nor 72? As noted, there may be files in which that's the case.
There was a problem hiding this comment.
What if the frame size is neither 16 nor 72? As noted, there may be files in which that's the case.
As in existing files, so adding an ex post facto restriction that the frame size for CAN CC frames must be 16 and CAN FD frames must be 72 doesn't fix that problem.
| been explicitly set, and the <code>CANFD_FDF</code> flag might happen to | ||
| be set even thugh the frame is not a CAN FD frame. | ||
| Software that reads <code>LINKTYPE_CAN_SOCKETCAN</code> frames must distinguish between CAN CC and CAN FD | ||
| ONLY by the frame length (16 or 72). Additionally the <code>0x80</code> bit of the fifth octet of the |
There was a problem hiding this comment.
The algorithm for frame type detection in Wireshark, proposed in this comment on Wireshark merge request 18710, does use the CANFD_FDF flag to distinguish between CAN CC and CAN FD frames; the code is (pseudo-code):
IF frame length == 72 OR FD flags has CANFD_FDF set
IF frame length >= 8 AND frame length <= 72
frame is CAN FD
ELSE
frame is invalid
ENDIF
ELSE IF frame_length >= 8 AND frame length <= 16
frame is CAN CC
ELSE
frame is invalid
ENDIF
Pick up soem fixes from #40: * make clear that RTR and error message frames are only CAN CC frames * fix typos: Classical CAN and CANXL_SEC. Note the field that, in CAN CC frames, contains the Len 8 DLC. Describe that value by referring to section 8.4.2.4 "DLC field" of ISO 11898-1:2015. Put a procedure for determining the frame type, based on the one proposed for Wireshark in https://gitlab.com/wireshark/wireshark/-/merge_requests/18710#note_2305575009: (which is essentially the same as the current algorithm, with some added checks), as the second paragraph. It's written in terms of raw octets of the frame and raw bits as hex values, as the frame formats and flag values are described later. It replaces an earlier description of the first step of that procedure. Discard some descriptions of heuristics to handle fromes from old versions of the Linux kernel and libpcap, as those aren't used by Wireshark, and shouldn't be necessary for dealing with the vast majority of captures (some old captures may need fixing). Improve the descriptions of what software producing these frames must do. ***NOTE:*** this does *nnot* refer to what the Linux kernel does or should do; it refers to what programs that provide packets in the LINKTYPE_CAN_SOCKETCAN/DLT_CAN_SOCKETCAN format must do. For example, this describes what libpcap must do if, for example, it's receiving SocketCAN frames from a Linux PF_PACKET socket. Note that remote retransmission requests may have a payload or a Len 8 DLC value that indicates a non-empty payload, but that the payload should be ignored.
|
I have committed as 9c8f5e6 a change that picks up the typo fixes and other small cleanups, and replaces the short mention of how to determine whether a frame is a CAN XL fram for not with a bulleted-list description of the algorithm proposed in the aforementioned Wireshark merge request comment. NOTE: this document does NOT describe, and is not intended to describe, what a Linux application reading directly from a CAN socket, or reading CAN packets from a If somebody wants to describe the behavior of those sockets, for the benefit of user-mode code that directly reads from those sockets, such as libpcap, they may do so, but that documentation would belong in a document such as this one, rather than in anything libpcap-related. |
