BLE sniffer guide
- 1 Introduction
- 2 Installation and setup, using a CC2540 USB dongle as sniffer hardware
- 3 Using the sniffer
- 4 Packet types
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.
Installation and setup, using a CC2540 USB dongle as sniffer hardware
- Download and install the SmartRF Packet Sniffer from 
- 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.hexafter installation.
- Start the sniffer, select Bluetooth Low Energy and press Start
Using the sniffer
To start sniffing, select the now programmed USB dongle, and press the play button.
The received packets will be parsed according to the packet format laid out in the Bluetooth 4.0 Core Specification Volume 6, Part B, chapters 2.1, 2.3 and 2.4.
Radio configuration pane
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).
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".
You should now only see advertiser with address 0x112233445566.
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
|Channel||State||PDU Type||Explanation||Core spec chapter|
|Advertising||Advertising||ADV_IND||Connectable undirected advertising event. Contains AdvA and AdvData.||6.B.188.8.131.52 // 6.B.184.108.40.206 // 3.C.11 // 3.C.18.1 (payload)|
|ADV_DIRECT_IND||Connectable directed advertising event. Contains AdvA and InitA||6.B.220.127.116.11 // 6.B.18.104.22.168|
|ADV_NOCONN_IND||Broadcast. Contains AdvA and AdvData||6.B.22.214.171.124 // 6.B.126.96.36.199|
|ADV_SCAN_IND||Connectable directed advertising event. Scannable.||6.B.188.8.131.52 // 6.B.184.108.40.206|
|Scanning||ADV_SCAN_REQ||Request for more information from LL in scanning state. ScanA, AdvA.||6.B.220.127.116.11 // 6.B.18.104.22.168|
|Advertising||ADV_SCAN_RSP||Response.||6.B.22.214.171.124 // 6.B.126.96.36.199|
|Initiating||CONNECT_REQ||Sent by initiator to establish a connection||6.B.188.8.131.52 // 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|
Advertisement packetsYou 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.
|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|
|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 / responseScan 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.
Connection establishmentConnection 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, and a message sequence diagram can be found in 6.D.5.1.
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 eventsAfter 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.
|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