LINKTYPE_CAN_SOCKETCAN

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 the CANFD_BRS and CANFD_ESI bits unless and until Linux assigns them a meaning.
  • Must make the "Reserved/Padding" fields 0 unless and until Linux assigns it 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 Linux uapi/can/error.h header.
  • third byte - flags indicating a CAN protocol error type, with bits specified by the CAN_ERR_PROT_ bits in the Linux uapi/can/error.h header.
  • fourth byte - flags indicating a CAN protocol error location, with bits specified by the CAN_ERR_LOC_ bits in the Linux uapi/can/error.h header.
  • fifth byte - the error status of the CAN transceiver, with values specified by the CAN_ERR_TRX_ values in the Linux uapi/can/error.h header.
  • sixth, seventh, and eighth bytes - controller-specific additional information.