Version 0 packet format (legacy)

+---------------------------+
|        Magic number       |
|         (2 Octets)        |
+---------------------------+
|         Packet type       |
|          (1 Octet)        |
+---------------------------+
|        Packet counter     |
|          (2 Octets)       |
+---------------------------+
|            Unused         |
|          (2 Octets)       |
+---------------------------+
|       Payload length      |
|          (1 Octet)        |
+---------------------------+
|          Payload          |
.                           .
.                           .
.                           .

Version 1 packet format

+---------------------------+
|          Board ID         |
|          (1 Octet)        |
+---------------------------+
|        Header length      |
|          (1 Octet)        |
+---------------------------+
|       Payload length      |
|          (1 Octet)        |
+---------------------------+
|       Protocol version    |
|          (1 Octet)        |
+---------------------------+
|        Packet counter     |
|          (2 Octets)       |
+---------------------------+
|         Packet type       |
|          (1 Octet)        |
+---------------------------+
|          Payload          |
.                           .
.                           .
.                           .

Version 2 and later packet format

+---------------------------+
|          Board ID         |
|          (1 Octet)        |
+---------------------------+
|       Payload length      |
|         (2 Octets)        |
+---------------------------+
|       Protocol version    |
|          (1 Octet)        |
+---------------------------+
|        Packet counter     |
|          (2 Octets)       |
+---------------------------+
|         Packet type       |
|          (1 Octet)        |
+---------------------------+
|          Payload          |
.                           .
.                           .
.                           .

Description

The magic number in version 0 packets has the first octet 0xBE and the second octet 0xEF.

To determine the packet version:

• check the octets at offses of 0 and 1 - if they are 0xBE and 0xEF, respectively, the packet is version 0;
• otherwise, the octet at offset 3 gives the packet version number.

The board ID field for packet versions 1 and later indicates which Sniffer device the message is to or from. Its value is opaque, with different values for different devices.

The header length field in packet version 1 contains the length of the header following the board ID, in octets, including the header length octet.

The payload length field contains the length of the payload following the header, in octets. In version 2 and later, it is in little-endian byte order.

The protocol version field in packet versions 1 and later contains the version of this protocol.

The packet counter field is in little-endian byte order. In messages sent from the Sniffer to the host, it contains a count of messages sent from the Sniffer to the host; in messages sent from the host to the Sniffer, it contains a count of messages sent from the host to the Sniffer. In both cases, the count is modulo 65536. This can be used to detect missing packets.

The packet type field contains a value that is one of:

• 0x00, for a REQ_FOLLOW message sent from the host to the Sniffer to only send packets received from a specific address;
• 0x01, for an EVENT_FOLLOW message sent from the Sniffer to the host to indicate that it has entered the FOLLOW state;
• 0x02, for an EVENT_PACKET_ADVERTISING message sent from the Sniffer to the host to indicate it has received an advertising physical channel PDU.
• 0x05, for an EVENT_CONNECT message sent from the Sniffer to the host to indicate that someone has connected to the unit we are following;
• 0x06, for an EVENT_PACKET_DATA message sent from the Sniffer to the host, containing a Bluetooth LE packet captured by the Sniffer;
• 0x07, for a REQ_SCAN_CONT message sent from the host to the Sniffer, telling it to scan continuously and hand over the packets ASAP;
• 0x09, for a EVENT_DISCONNECT message sent from the Sniffer to the host, telling it that the connected address we were following has received a disconnect packet;
• 0x0C, for a SET_TEMPORARY_KEY message, specifying a temporary key to use on encryption (for OOB and passkey);
• 0x0D, for a PING_REQ message;
• 0x0E, for a PING_RESP message;
• 0x13, for a SWITCH_BAUD_RATE_REQ message;
• 0x14, for a SWITCH_BAUD_RATE_RESP message;
• 0x17, for a SET_ADV_CHANNEL_HOP_SEQ message sent from the host to the Sniffer, telling it which order to cycle through the channels when following an advertiser;
• 0xFE, for a GO_IDLE sent from the host to the Sniffer, telling it to stop sending UART traffic and listen for new commands.

For an EVENT_PACKET_ADVERTISING or EVENT_PACKET message, the payload has the form:

+-------------------------------+
|      Payload header length    |
|            (1 Octet)          |
+-------------------------------+
|              Flags            |
|            (1 Octet)          |
+-------------------------------+
|             Channel           |
|            (1 Octet)          |
+-------------------------------+
|           RSSI Sample         |
|            (1 Octet)          |
+-------------------------------+
|          Event counter        |
|            (2 Octets)         |
+-------------------------------+
| Delta time/Firmware timestamp |
|            (4 Octets)         |
+-------------------------------+
|    LE Packet (no preamble)    |
.                               .
.                               .
.                               .

For protocol versions prior to version 3, both advertising physical channel packets and data physical channel are provided in EVENT_PACKET_DATA messages. If the access address is 0x8e89bed6, the packet is an advertising physical channel packet, otherwise it is a data physical channel packet.

For protocol version 3, advertising physical channel packets are delivered in EVENT_PACKET_ADVERTISING messages and data physical channel packets are delivered in EVENT_PACKET_DATA messages.

The payload header length field contains the length of the header preceding the Bluetooth LE packet, including the length of the payload header field.

The flags field contains the following flag bits for EVENT_PACKET_ADVERTISING messages:

• 0000000x - CRC status (0 = incorrect, 1 = OK);
• 00000xx0 - reserved for future use (channels >= 37);
• 00000xx0 - AUX_TYPE (channels < 37):
• 0 - AUX_ADV_IND:
• 1 - AUX_CHAIN_IND:
• 2 - AUX_SYNC_IND:
• 3 - AUX_SCAN_RSP.
• 0000x000 - reserved for future use;
• 0xxx0000 - PHY type:
• 0 - 1M PHY;
• 1 - 2M PHY;
• 2 - coded.
• x0000000 - reserved for future use:

and for EVENT_PACKET messages:

• 0000000x - CRC status (0 = incorrect, 1 = OK);
• 000000x0 - packet direction (0 = peripheral -> control, 1 = control -> peripheral);
• 00000x00 - packet encrypted (0 = no, 1 = yes);
• 0000x000 - MIC status (0 = incorrect, 1 = OK);
• 0xxx0000 - PHY type:
• 0 - 1M PHY;
• 1 - 2M PHY;
• 2 - coded.
• x0000000 - reserved for future use.

The channel field contains the Bluetooth LE channel index of the channel being used.

The RSSI sample field contains the absolute value of RSSI of the packet, in dBm; the actual RSSI is the negative of that value.

The event counter field is in little-endian byte order. For packets that are part of a connection, it contains the value of a counter of packets within the connection; there are separate counters for each direction of the connection.

The delta time/firmware timestamp field is in little-endian byte order. In protocol versions prior to version 3, it contains the time in microseconds from the end of the previous received packet to the beginning of this packet. In protocol version 3, it contains the timestamp of the start of the received packet captured by the firmware timer with microsecond resolution.

Following the delta time/firmware timestamp field is a Bluetooth LE link-layer packet, as described in section 2 "Air Interface Packets" of Volume 6, part B of the Bluetooth Core Specification, except that the preamble field is absent.