Understanding Bluetooth Advertising Packets

Bluetooth Advertising

UPDATE (Dec. 7, 2014): I am interested in understanding how my Bluetooth scanning Android app, Bluescan could be used to help with your Bluetooth efforts. Please email me at j2abro@gmail.com if you have any feedback or ideas on how I can improve that app in ways that would be useful for you.

This post looks at Bluetooth Low Energy (BLE) advertising packet format and then shows some sample packets captured using an Ubertooth Bluetooth packet sniffer. First we'll look at the packet format and then look at some packets. In a future post I'll compare the captured packets to the format shown here.

Bluetooth Link Layer Packet Format

Packets in BLE are defined in the Link Layer. There is only one packet format for BLE as shown below.

BLE Packet Structure

Attributes

A packet can be 80 to 376 bits in length, and has the following components.

• Preamble: used for internal protocol management. Advertising packets have 10101010b as the preamble.

• Access Address: This is always 0x8E89BED6 (10001110100010011011111011010110b)for advertising packets.

• PDU: There are two PDU formats, one for advertising packets and one for data packets.

• CRC: 3 byte value calculated over PDU.

Bluetooth LE Advertising Channel PDU

There are only two PDU formats in BLE, one for data packets and one for advertising - shown below. Here is the GitHub Gist for the blockdiag diagram. The type of packet is determined by the channel on which the packet is transmitted. Advertising channels are 37, 38, and 39.

Advertising Channel PDU

Attributes

• PDU Type: See more info below.
• RFU: Reserved for future use
• TxAdd, RxAdd: These are defined for each individual advertising channel, but their purpose is not clear to me.
• Length: Payload length in bytes. Valid range is 6 to 37 bytes.

PDU Types

These are the PDU types; the first four are advertising channel types:

• ADV_IND (0000): Connectable undirected advertising, has the following payload:
• AdvA (6 bytes): Advertisers public or random device address. TxAdd indicates if the address is public or random.
• TxAdd = 0 advertiser address is public
• TxAdd = 1 advertiser address is random address
• AdvData (0-31 bytes): Optional advertising data from advertiser
• ADV_DIRECT_IND (0001): Connectable directed advertising. Directed advertising is used when a device needs to quickly connect to another device. An initiating device immediately sends a connection request upon receiving this. This PDU has the following payload.
• AdvA (6 bytes): Advertisers address. TxAdd indicates if the address is public or random.
• TxAdd = 0 advertiser address is public
• TxAdd = 1 advertiser address is random address
• InitA (6 bytes): Initiator address. RxAdd in PDU indicates the address type:
• RxAdd = 0 initiator address is public
• RxAdd = 1 initiator address is random address
• ADV_NONCONN_IND (0010): Non connectable undirected advertising. Used by devices that want to broadcast and don't want to be connected to or scannable. This is the only option for a device that is only a transmitter.
• AdvA (6 bytes): Advertisers public or random device address. TxAdd indicates if the address is public or random.
• TxAdd = 0 advertiser address is public
• TxAdd = 1 advertiser address is random address
• AdvData (0-31 bytes): Optional advertising data from advertiser
• ADV_SCAN_IDN (0110): (formerly called ADV_DISCOVER_IND) Scannable undirected advertising.
• AdvA (6 bytes): Advertisers public or random device address. TxAdd indicates if the address is public or random.
• TxAdd = 0 advertiser address is public
• TxAdd = 1 advertiser address is random address
• AdvData (0-31 bytes): Optional advertising data from advertiser

While not specifically an advertising PDU type, active scanning will involve the following additional types:

• SCAN_REQ (0011): Upon receiving and advertising packet and active scanner will issue this scan request packet, with the following payload.
• ScanA (6 bytes): Scanner address.TxAdd indicates if the address is public or random.
• TxAdd = 0 advertiser address is public
• TxAdd = 1 advertiser address is random address
• AdvA (6 bytes): Device to which this PDU is addressed. RxAdd in PDU indicates the address type:
• RxAdd = 0 initiator address is public
• RxAdd = 1 initiator address is random address
• SCAN_RSP (0100): Upon receiving a scan request (SCAN_REQ) packet and advertiser can respond with this.
• AdvA (6 bytes): Advertiser address.TxAdd indicates if the address is public or random.
• TxAdd = 0 advertiser address is public
• TxAdd = 1 advertiser address is random address
• ScanResponseData (0-31 bytes): Optional advertising data from advertiser
• Length: Length of response data
• CONNECT_REQ (0101): Connection request

Sample packets

Now lets look at some packet captures.

Using Ubertooth to capture Bluetooth packets, I was finally able to really visualize what was happening in my BlueScan Android scanner.  Below shows a dump from Ubertooth using the device connected to a Mac laptop as with the -f option to follow a connection:

 ubertooth-btle -f  

To capture data from another channel, the -A flag is used. On my installation, I had to take the Ubertooth out of  the USB slot for this to have an affect. Then this worked.

 ubertooth-btle -f -A 39

The following packet sequence is between a Fitbit Flex (advertiser) and Bluescan (scanner), on channel 37.

Fitbit advertisement (ADV_IND):

 systime=1401827476 freq=2402 addr=8e89bed6 delta_t=673.874 ms  
 40 21 eb 12 e6 2d bb f5 02 01 06 11 06 ba 56 89 a6 fa bf a2 bd 01 46 7d 6e ca 36 ab ad 05 16 0a 18 07 04 69 6e 34   
 Advertising / AA 8e89bed6 / 33 bytes  
   Channel Index: 37  
   Type: ADV_IND  
   AdvA: f5:bb:2d:e6:12:eb (random)  
   AdvData: 02 01 06 11 06 ba 56 89 a6 fa bf a2 bd 01 46 7d 6e ca 36 ab ad 05 16 0a 18 07 04  
     Type 01 (Flags)  
       00000110  
     Type 06 (128-bit Service UUIDs, more available)  
       adab36ca-6e7d-4601-bda2-bffaa68956ba  
     Type 16 (Service Data)  
       UUID: 180a, Additional: 07 04  
   Data: eb 12 e6 2d bb f5 02 01 06 11 06 ba 56 89 a6 fa bf a2 bd 01 46 7d 6e ca 36 ab ad 05 16 0a 18 07 04  
   CRC:  69 6e 34  

In this captures, we are listening on Channel 37 which is the default.

BlueScan response (SCAN_REQ):

 systime=1401827476 freq=2402 addr=8e89bed6 delta_t=0.336 ms  
 83 0c 55 87 45 0b 22 ac eb 12 e6 2d bb f5 cc 1c fd   
 Advertising / AA 8e89bed6 / 12 bytes  
   Channel Index: 37  
   Type: SCAN_REQ  
   ScanA: ac:22:0b:45:87:55 (public)  
   AdvA: f5:bb:2d:e6:12:eb (random)  
   Data: 55 87 45 0b 22 ac eb 12 e6 2d bb f5  
   CRC:  cc 1c fd  

Fitbit response (SCAN_RSP):

 systime=1401827476 freq=2402 addr=8e89bed6 delta_t=0.326 ms  
 44 0f eb 12 e6 2d bb f5 05 09 46 6c 65 78 02 0a fa b6 c4 52   
 Advertising / AA 8e89bed6 / 15 bytes  
   Channel Index: 37  
   Type: SCAN_RSP  
   AdvA: f5:bb:2d:e6:12:eb (random)  
   ScanRspData: 05 09 46 6c 65 78 02 0a fa  
     Type 09 (Complete Local Name)  
       Flex  
     Type 0a (Tx Power Level)  
       -6 dBm  
   Data: eb 12 e6 2d bb f5 05 09 46 6c 65 78 02 0a fa  
   CRC:  b6 c4 52  

For more info, I suggest to Core spec:

Bluetooth Specification Version 4.1, [Volume 6] Link Layer Specification.
(Page 2,506 of the specification, is a start)

Analyzing Packets

Next, we'll analyze some packets and compare them to the documented format.

UPDATE (Dec. 7, 2014): I am interested in understanding how my Bluetooth scanning Android app, Bluescan could be used to help with your Bluetooth efforts. Please email me at j2abro@gmail.com if you have any feedback or ideas on how I can improve that app in ways that would be useful for you.