LINKTYPE_CAN_SOCKETCAN
This format supports classic CAN, CAN FD. and CAN XL frames. The same header is used for classic CAN and CAN FD frames; a different header is used for CAN XL frames.
The 0x80
bit of the fifth octet of the header is clear for
CAN and CAN FD frames, and set for CAN XL frames.
CAN and CAN FD frames
Packet structure
+---------------------------+ | CAN ID and flags | | (4 Octets) | +---------------------------+ | Payload length | | (1 Octet) | +---------------------------+ | FD flags | | (1 Octet) | +---------------------------+ | Reserved/Padding | | (1 Octet) | +---------------------------+ | Reserved/Padding | | (1 Octet) | +---------------------------+ | Payload | . . . . . . +---------------------------+ | Padding | . . . . . .
Description
The CAN ID and flags field is in network byte order (big-endian). The bottom 29 bits contain the CAN ID of the frame. The remaining bits are:
0x20000000
- set if the frame is an error message rather than a data frame.0x40000000
- set if the frame is a remote transmission request frame.0x80000000
- set if the frame is an extended 29-bit frame rather than a standard 11-bit frame.
The frame payload length indicates the number of bytes of payload following the header. All packet bytes after those bytes of payload are padding.
The FD flags field contains CAN FD specific flags; for CAN frames, this field is 0. The bits are:
CANFD_BRS
(0x01
) - bit rate switch (second bitrate for payload data).CANFD_ESI
(0x02
) - error state indicator of the transmitting node.CANFD_FDF
(0x04
) - if set, the frame is a CAN FD frame; if not set, the frame may be a CAN frame or a CAN FD frame.
Older software and firmware writing packets with this link type did not
use the CANFD_FDF
flag for CAN FD frames, so if the CANFD_FDF
flag is
not set, the frame is not guaranteed to be a CAN frame. If that flag is
not set:
- if the frame size (including the header and padding) is 16, it's a CAN frame;
- if the frame size (including the header and padding) is 72, it's a CAN FD frame.
In addition, older software and firmware may not have explicitly set
that field, so that the bit corresponding to the CANFD_FDF
flag might be
set even for classic CAN frames. Therefore, code that reads
LINKTYPE_CAN_SOCKETCAN
frames must perform some heuristic checks to make
sure that it doesn't incorrectly interpret a classic CAN frame as a CAN
FD frame, and code that generates LINKTYPE_CAN_SOCKETCAN
frames must
follow certain rules to make sure that those checks don't cause
software that reads those fromes to treat a CAN FD frame as a classic
CAN frame.
Software that reads LINKTYPE_CAN_SOCKETCAN
frames must not treat a frame
with the CANFD_FDF
bit set as a CAN FD frame if any bits other than
CANFD_BRS
and CANFD_ESI
are set in that field, or if either of the
Reserved/Padding fields are non-zero, as that is an indication that the
header fields might not have been explicitly set, and the CANFD_FDF
flag
might happen to be set even thugh the frame is not a CAN FD frame.
Software that generates LINKTYPE_CAN_SOCKETCAN
frames:
- Must check the frame MTU when receiving frames from the Linux kernel in order to classify them as classic CAN frames or CAN FD frames.
- Must make the "FD flags" field 0 for classic CAN frames.
- Must set the
CANFD_FDF
bit of the "FD flags" field in CAN FD frames, and don't set any bits in that field other than theCANFD_BRS
andCANFD_ESI
bits unless and until Linux assigns them a meaning. - Must make the "Reserved/Padding" fields 0 unless and until Linux assigns that particular field a meaning.
- May strip trailing padding bytes to save disk space if all above statements are satisfied.
For a data frame, the payload is the data field of the CAN or CAN FD packet.
For a remote retransmission request, the payload length must be 0, so the payload is empty.
For an error message, the payload is always 8 bytes. The lower bits of
the CAN ID field contain an error class value, with bits specified by
the first set of CAN_ERR_
values in the
Linux uapi/can/error.h
header. The bytes in the payload are:
- first byte - if arbitration was lost, the bit number in the bitstream in which it was lost; otherwise 0.
- second byte - the error status of the CAN controller, with bits
specified by the
CAN_ERR_CRTL_
bits in the Linuxuapi/can/error.h
header. - third byte - flags indicating a CAN protocol error type, with bits
specified by the
CAN_ERR_PROT_
bits in the Linuxuapi/can/error.h
header. - fourth byte - flags indicating a CAN protocol error location, with
bits specified by the
CAN_ERR_LOC_
bits in the Linuxuapi/can/error.h
header. - fifth byte - the error status of the CAN transceiver, with values
specified by the
CAN_ERR_TRX_
values in the Linuxuapi/can/error.h
header. - sixth, seventh, and eighth bytes - controller-specific additional information.
CAN XL frames
Packet structure
+---------------------------+ | Priority ID/VCID | | (4 Octets) | +---------------------------+ | Flags | | (1 Octet) | +---------------------------+ | SDU type | | (1 Octet) | +---------------------------+ | Payload length | | (2 Octets) | +---------------------------+ | Acceptance Field | | (4 Octets) | +---------------------------+ | Payload | . . . . . . +---------------------------+ | Padding | . . . . . .
Description
The Priority ID/VCID field is big-endian, but the payload length and acceptance field are little-endian.
The Priority ID/VCID field is in big-endian byte order. The bottom 11 bits contain the priority of the frame. The 5 bits above that are reserved. The 8 bits above that contain a virtual CAN network identifier (VCID). The 8 bits above that are reserved.
The flags field contains CAN XL specific flags. The bits are:
CANFD_SEC
(0x01
) - Simple Extended Context.CANXL_XLF
(0x80
) - if set, the frame is a CAN XL frame; if not set, the frame is a CAN frame or a CAN FD frame.
The SDU type field contains an indication of the higher-layer protocol used by the payload. The values of this field are specified by CAN in Automation (CiA) specification 611-1 "CAN XL higher-layer functions - Part 1: Definition of service data unit types (SDT)".
The frame payload length is in little-endian byte order. It indicates the number of bytes of payload following the header. All packet bytes after those bytes of payload are padding.
The Acceptance Field is in little-endian byte order.