BLE sniffer guide

From Texas Instruments Wiki
Jump to: navigation, search

Bluetooth Low Energy Wiki Main Page


The TI Packet Sniffer can be used to look at everything that goes on between two BLE devices over the air, and is as such a good tool for debugging or just learning about Bluetooth Low Energy applications. The TI Packet Sniffer is limited to capturing BLE data and control PDUs that follow the Bluetooth 4.0 and 4.1 specification. The following Bluetooth 4.2 optional features cannot be fully captured / decoded with the TI Packet Sniffer:

  • LE Data Length Extension - The Link Layer control procedure to set/configure longer PDUs can be observed, but PDUs that exceed 27 bytes cannot be observed. Other PDUs that are up to 27 bytes can be observed even though both devices have negotiated support for extended packet lengths. Note that a PDU > 27 bytes will only be sent when the App/Host sends a larger PDU payload.
  • LE Secure Connections - The Secure Connection pairing key exchange can be observed but the subsequent decode requires supplying the Long Term Key (LTK)

Installation and setup, using a CC2540 USB dongle as sniffer hardware

  1. Download and install the SmartRF Packet Sniffer from [1]
  2. Using SmartRF Flash Programmer, program the CC2540 USB dongle with the image found in \program files\Texas Instruments\SmartRF Tools\Packet Sniffer\bin\general\firmware\sniffer_fw_cc2540_usb.hex after installation. The manual on how to use SmartRF Flash Programmer with the CC Debugger to program the USB dongle can be found here.
    Using flash programmer
  3. Start the sniffer, select Bluetooth Low Energy and press Start
    Starting the sniffer in BLE mode

Using the sniffer

To start sniffing, select the now programmed USB dongle, and press the play button.

Starting packet aquisition

The received packets will be parsed according to the packet format laid out in the Bluetooth 4.0 Core Specification[2] Volume 6, Part B, chapters 2.1, 2.3 and 2.4.

Radio configuration pane

Radio configuration

In the radio configuration pane you can

  • Specify which initiator IEEE address' connection you want to follow in the case that there are multiple BLE devices active (red ring). Otherwise the first detected connection establishment will be followed. You will still see all advertisement data.
  • Specify which advertisement channel you want to listen to (yellow): 37 (default), 38, or 39.
  • Note: The Packet Sniffer can only monitor one Advertising channel. If the connection request is sent by the Master on one of the other two available Advertising channels, then the sniffer will not be able to monitor the connection. For testing purposes with a TI peripheral, you can use GAPRole_SetParameter() to set the GAPROLE_ADV_CHANNEL_MAP parameter to a specific Advertising channel, e.g., GAP_ADVCHAN_37, so the peripheral only uses Advertising chan 37. See the available channel defines in gap.h. For the peripheral based sample applications in the BLE-Stack SDK (e.g., Simple Peripheral, SensorTag, Heart Rate, etc.), this parameter can be adjusted in peripheral.c at the following location:
 // Initialize the Profile Advertising and Connection Parameters
 gapRole_AdvChanMap = GAP_ADVCHAN_ALL;
 // Set gapRole_AdvChanMap to the desired Advertising channel: GAP_ADVCHAN_37, GAP_ADVCHAN_38 or GAP_ADVCHAN_39

This parameter should only be used in test conditions as it is recommended to always Advertise on all three channels in production firmware.

Address book


Display filter

Filter on Unique Advertiser

Choose "ADV_IND AdvA" and press button "First", then add the address where x is, so the line says ex. AA1=0x112233445566. Then press "Add" followed by "Apply filter".

Packet Sniffer Filtering Advertiser

You should now only see advertiser with address 0x112233445566.



Packet types

According to the state the device is in, different communication channels are applicable.

  • Advertising channel: 37 (2402MHz), 38 (2426 MHz) and 39 (2480 MHz)
  • Data channel: 0-36 (2404-2478 MHz) excluding (2426 MHz)

The advertising channel and data channel allow different Protocol Data Unit (PDU) types

PDU Types
Channel State PDU Type Explanation Core spec chapter
Advertising Advertising ADV_IND Connectable undirected advertising event. Contains AdvA and AdvData. 6.B. // 6.B. // 3.C.11 // 3.C.18.1 (payload)
ADV_DIRECT_IND Connectable directed advertising event. Contains AdvA and InitA 6.B. // 6.B.
ADV_NOCONN_IND Broadcast. Contains AdvA and AdvData 6.B. // 6.B.
ADV_SCAN_IND Connectable directed advertising event. Scannable. 6.B. // 6.B.
Scanning ADV_SCAN_REQ Request for more information from LL in scanning state. ScanA, AdvA. 6.B. // 6.B.
Advertising ADV_SCAN_RSP Response. 6.B. // 6.B.
Initiating CONNECT_REQ Sent by initiator to establish a connection 6.B. // 6.B.4.4.4
Data Data LLID field is 1 or 2. Empty PDUs allow the slave to respond with any PDU. General data 6.B.2.4 // 6.B.4.5
Control LLID field is 3. PDU can not be emtpy Control data, see core spec 6.B.2.4.2 // 6.B.4.5

You will immediately start receiving captured advertisement packets, given that a peripheral is advertising. Fields 1,2,3,4 and 9,10,11 are common to all captured packets.
Using capt adv.png
Explanation for advertisement packet fields.
Field # Source Explanation Core spec chapter
1 Sniffer Packet number as logged by the sniffer
2 Capture device Time in microseconds since last packet was received and absolute time
3 Capture device Radio channel data was captured on 6.B.1.4.1
4 Air Bluetooth spec specified address for advertising and scan response 6.B.2.1.2
5 Air Type of advertisement packet 6.B.2.3
6 Air Header 6.B.2.3
7 Air Advertiser IEEE address 6.B.2.3
8 Air Advertisement data. In this example it's capabilities and three UUIDs the device provides. 6.B.2.3 / 3.C.11 / 3.C.18.1
9 Air Precalculated CRC checksum 6.B.2.1.4
10 Capture device Received signal strength indicator.
11 Capture device Field Control Sequence. If OK, the checksum is correct

The advertisement fields are further explained in 6.B.2.3 on page 2202 of the BT core spec.

Scan request / response

Scan request and response are two other types specified in 6.B.2.3, and look like the image below in the sniffer. The example below is of Active scan, and a sequence diagram is found in 6.D.4.2.
Using scan req.png
Here we can see that immediately following an advertisement indication (366µs), in the same advertisement event when the peripheral goes into RX mode, another device sends a scan request, which is then immediately answered by the peripheral device. The scan response in this instance is "Keyfobdemo"

Connection establishment

Connection establishment is initiated by the initiator (sic) on the peripheral RX slot of an advertisement event. The message format of the connection request is described in 6.B.2.3.3 in the Bluetooth core spec[3], and a message sequence diagram can be found in 6.D.5.1.
Using conn est.png

Here we see that Bluetooth LE connection establishment is pretty fast. Packet #185 shows an advertisement event peripheral TX slot, #186 shows connection request in the peripheral RX slot in the same event. Now the link is established. This is followed 20ms later by the first Central device initiated connection event's TX slot in #187, followed by a peripheral answer in #188 in the same connection event.

Empty connection events

After connection establishment we are in the connected state as defined by 6.B.4.5 in the BT Core spec. The data header is defined in 6.B.2.4 and is summarized below.
Using empty conn ev.png
Data header
Field Long name Explanation Core spec chapter
LLID Link Layer ID 0x1 = Data PDU; continued fragment or emtpy, 0x2 Data PDU Start of fragmented data or complete message, 0x3 Control PDU. 6.B.2.4 / 6.B.4.5
NESN Next expected sequence number 1-bit, used with SN for ack/nack 6.B.2.4 / 6.B.4.5.9
SN Sequence number 1-bit, used with NESN for ack/nack 6.B.2.4 / 6.B.4.5.9
MD More Data Used to indicate whether more data is coming. See table in spec. 6.B.4.5.6
PDU Length Length of payload + MIC in octets. PDU Length is maximum 27 octets. MIC 4 octets if present. 6.B.2.4

In this example we can see that the central device has SN = NESN indicating new data, and the peripheral device responds with ACK (SN!=NESN because it expects next packet).

Read request, read response


Write request, write response