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. 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
- Download and install the SmartRF Packet Sniffer from 
Note that BLE sniffing is only supported with the PACKET-SNIFFER, there is no BLE sniffing support in PACKET-SNIFFER-2.
Windows 10 Users: Please download and install the latest version of SmartRF Studio 7 (SMARTRFTM-STUDIO) in order to obtain the Win10 CEBAL device driver needed to communicate with the USB dongle.
- 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. The manual on how to use SmartRF Flash Programmer with the CC Debugger to program the USB dongle can be found here.
- 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): 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.
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.220.127.116.11 // 6.B.18.104.22.168 // 3.C.11 // 3.C.18.1 (payload)|
|ADV_DIRECT_IND||Connectable directed advertising event. Contains AdvA and InitA||6.B.22.214.171.124 // 6.B.126.96.36.199|
|ADV_NOCONN_IND||Broadcast. Contains AdvA and AdvData||6.B.188.8.131.52 // 6.B.184.108.40.206|
|ADV_SCAN_IND||Connectable directed advertising event. Scannable.||6.B.220.127.116.11 // 6.B.18.104.22.168|
|Scanning||ADV_SCAN_REQ||Request for more information from LL in scanning state. ScanA, AdvA.||6.B.22.214.171.124 // 6.B.126.96.36.199|
|Advertising||ADV_SCAN_RSP||Response.||6.B.188.8.131.52 // 6.B.184.108.40.206|
|Initiating||CONNECT_REQ||Sent by initiator to establish a connection||6.B.220.127.116.11 // 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