In the previous blog post, we went over the different BLE sniffers available in the market and compared the pros and cons of each. In this video below, we walk through a live demo of capturing BLE advertisements using the TI CC2540 USB Dongle BLE sniffer. We look at the different aspects of the captured advertisement data and understand each part.
Bluetooth low energy Advertisement Data
Packet number: the sequence of packets received by the sniffer.
Timestamp: (starting from 0) and the time difference since the previous packet was received.
Channel number: (depends on what channel you set in the Radio Configuration). The Access address will always be the same value (0x8E89BED6) according to the spec for advertisement packets.
Adv PDU type: there are seven types, including (as of the 4.2 Bluetooth Specification):
- ADV_IND (
0b0000): Connectable undirected advertising which can be connected to by any BLE central. - ADV_DIRECT_IND (
0b0001): Connectable directed advertising which can be connected to by one specific Central. - ADV_NONCONN_IND (
0b0010): Non-connectable undirected advertising which cannot be connected to and cannot respond to a scan request. - SCAN_REQ (
0b0011): sent by the Central requesting a scan response (which is a way to send more data via advertising but the response is directed specifically to the requester). - SCAN_RSP (
0b0100): The scan response packet containing any additional info sent by the peripheral. - CONNECT_REQ (
0b0101): a connection request packet sent by the Central to connect to a specific peripheral. - ADV_SCAN_IND (
0b0110): Scannable undirected advertising which cannot be connected to but which can respond to a scan request.
Adv PDU Header: contains the following elements:
- Type: is the value indicating the type of advertisement which corresponds to the type listed under “Adv PDU Type”.
- TxAdd: Indicates whether the advertiser’s or initiator’s (depending on the type of advertisement packet) address is public (0x00) or random (0x01). For example, for ADV_IND, ADV_DIRECT_IND, ADV_NONCONN_IND, SCAN_RSP, and ADV_SCAN_IND it refers to the advertiser’s address whereas it to refers to the initiator’s address in the case of SCAN_REQ and CONNECT_REQ.
- RxAdd: Indicates whether the address is public (0x00) or random (0x01) depending on the type of advertisement packet. Just like TxAdd, but the opposite. It only exists for the types ADV_DIRECT_IND, SCAN_REQ, and CONNECT_REQ since for the other types the Initiator role does not apply.
- PDU-Length: The length of the PDU, which includes the data following the header.
AdvA: this is the advertiser’s address and is unique per device.
AdvData: this contains the individual bytes being advertised by the peripheral device.
CRC: This is the CRC value transmitted in the packet and originally calculated by the transmitter device.
RSSI: Received signal strength indicator as reported by the BLE sniffer transceiver.
FCS: Frame check sequence, which indicates whether the CRC calculated by the software matches the CRC transmitted by the BLE device under test.
Summary
- We went over how to capture BLE advertisement data using the TI BLE sniffer.
- We also went through a live demo of capturing the data and explaining the different elements.
- I hope you found this video useful. In the next video, we’ll go over how to follow connections between a central device and a peripheral device and look at the different packet information being displayed by the software.
Others in the series:
