LINKTYPE_LINUX_SLL

Packet structure

+---------------------------+
|         Packet type       |
|         (2 Octets)        |
+---------------------------+
|        ARPHRD_ type       |
|         (2 Octets)        |
+---------------------------+
| Link-layer address length |
|         (2 Octets)        |
+---------------------------+
|    Link-layer address     |
|         (8 Octets)        |
+---------------------------+
|        Protocol type      |
|         (2 Octets)        |
+---------------------------+
|           Payload         |
.                           .
.                           .
.                           .

Description

The packet type field is in network byte order (big-endian); it contains a value that is one of:

  • 0, if the packet was specifically sent to us by somebody else;
  • 1, if the packet was broadcast by somebody else;
  • 2, if the packet was multicast, but not broadcast, by somebody else;
  • 3, if the packet was sent to somebody else by somebody else;
  • 4, if the packet was sent by us.

The ARPHRD_ type field is in network byte order; it contains a Linux ARPHRD_ value for the link-layer device type.

The link-layer address length field is in network byte order; it contains the length of the link-layer address of the sender of the packet. That length could be zero.

The link-layer address field contains the link-layer address of the sender of the packet; the number of bytes of that field that are meaningful is specified by the link-layer address length field. If there are more than 8 bytes, only the first 8 bytes are present, and if there are fewer than 8 bytes, there are padding bytes after the address to pad the field to 8 bytes.

The protocol type field is in network byte order.

If the ARPHRD_ type is ARPHRD_NETLINK (824), the packet data, including the LINKTYPE_LINUX_SLL header, is a LINKTYPE_NETLINK packet, with the protocol type field being the Netlink protocol type.

If the ARPHRD_ type is ARPHRD_IPGRE (778), the protocol type field contains a GRE protocol type.

If the ARPHRD_ type is ARPHRD_IEEE80211_RADIOTAP (803), the protocol type field is ignored, and the payload following the LINKTYPE_LINUX_SLL header begins with Radiotap link-layer information followed by an 802.11 header.

If the ARPHRD_ type is ARPHRD_FRAD (770), the protocol type field is ignored, and the payload following the LINKTYPE_LINUX_SLL header is a Frame Relay LAPF frame, beginning with a ITU-T Recommendation Q.922 LAPF header starting with the address field, and without an FCS at the end of the frame.

Otherwise, the protocol type field contains the Ethernet protocol type for the packet, or one of:

  • 0x0001, if the frame is a Novell 802.3 frame without an 802.2 LLC header;
  • 0x0003, in some mysterious cases;
  • 0x0004, if the frame begins with an 802.2 LLC header;
  • 0x000C, if the frame is a CAN bus frame;
  • 0x000D, if the frame is a CAN FD (CAN with Flexible Data-Rate) frame.

A CAN bus frame begins with a header of the form:

+---------------------------+
|      CAN ID and flags     |
|         (4 Octets)        |
+---------------------------+
|    Frame payload length   |
|         (1 Octet)         |
+---------------------------+
|          Padding          |
|         (1 Octet)         |
+---------------------------+
|      Reserved/Padding     |
|         (1 Octet)         |
+---------------------------+
|      Reserved/Padding     |
|         (1 Octet)         |
+---------------------------+

where the field containing the CAN ID and flags is in host byte order. 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;

and the header is followed by the CAN bus payload.

A CAN FD frame begins with a header of the form:

+---------------------------+
|      CAN ID and flags     |
|         (4 Octets)        |
+---------------------------+
|    Frame payload length   |
|         (1 Octet)         |
+---------------------------+
|         FD flags          |
|         (1 Octet)         |
+---------------------------+
|      Reserved/Padding     |
|         (1 Octet)         |
+---------------------------+
|      Reserved/Padding     |
|         (1 Octet)         |
+---------------------------+

where the field containing the CAN ID and flags is in host byte order. The bottom 29 bits of that field contain the CAN ID of the frame. The remaining bits are:

  • 0x80000000 - set if the frame is an extended 29-bit frame rather than a standard 11-bit frame.
The bits of the FD flags field are:
  • 0x01 - set if the bit rate switch flag is set for the frame;
  • 0x02 - set if the error state indicator is set for the frame;

and the header is followed by the CAN FD payload.

For a CAN or CAN FD data frame, the payload is the data field of the packet.

For a retransmission request, the length must be 0, so the payload is empty.

For a CAN or CAN FD 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.