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 big-endian byte order; 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 big-endian byte order; it contains a Linux ARPHRD_ value for the link-layer device type.

The link-layer address length field is in big-endian 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 octets of that field that are meaningful is specified by the link-layer address length field. If there are more than 8 octets, only the first 8 octets are present, and if there are fewer than 8 octets, there are padding octets after the address to pad the field to 8 octets.

The protocol type field is in big-endian byte order.

If the ARPHRD_ type is ARPHRD_NETLINK (824), the payload, 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) or ARPHRD_IP6GRE (823), the protocol type field contains a GRE protocol type for the payload.

If the ARPHRD_ type is ARPHRD_IEEE80211_RADIOTAP (803), the protocol type field is ignored, and the payload 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 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 payload, or one of:

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

CAN CC, CAN FD, and CAN XL frames are in a format similar to LINKTYPE_CAN_SOCKETCAN frames, except that:

  1. all multi-octet fields in the LINKTYPE_CAN_SOCKETCAN header are in host byte order rather than big-endian or little-endian byte order;
  2. the protocol type field, rather than bits in the FD flags and XL flags fields, should be used to distinguish between CAN CC, CAN FD, and CAN XL frames.