Bluetooth Low Energy Sniffing Basics for Your Own Devices

[Pavel]

Short answer: BLE advertising is easier to observe than an entire connection because connections hop channels using negotiated parameters. Use a BLE sniffer and software that support the target BLE version, PHY and follow mode, and test only devices you own.

Before you start​

• Limit capture and protocol testing to equipment and networks you own or have explicit permission to assess.
• Choose hardware for the protocol and capture mode, not frequency coverage alone: Wi-Fi monitor mode, BLE sniffing, low-frequency RFID and NFC use different interfaces.

Step-by-step method​

1. Step 1: Start with advertising channels and identify your device by a temporary controlled name or timing pattern, not by publishing its permanent address.
2. Step 2: Confirm whether the device uses legacy advertising, extended advertising, LE 1M, 2M or coded PHY. The sniffer must support the selected mode.
3. Step 3: To follow a connection, capture the connection request and hopping parameters from the beginning. Start recording before initiating pairing or connection.
4. Step 4: Validate decoded packets with CRC and expected service/characteristic behavior. Redact addresses, keys, tokens and personal sensor values before sharing.

Concrete example​

A sniffer that begins after two devices are already connected may see advertising from other devices but cannot reconstruct the missed connection parameters needed to follow the hop sequence.

How to judge the result​

A useful capture has valid CRCs, follows the intended owned device through the required stage and includes enough PHY/channel metadata to reproduce the test.

What to record​

• Document channel, bandwidth, adapter chipset and driver mode so another authorized tester can reproduce the capture.
• Verify that captured frames pass checksum or integrity checks before interpreting higher-layer fields.
• Redact MAC addresses, SSIDs, tag identifiers, tokens and payloads before sharing files publicly.

Common mistakes​

• Changing several hardware, software or RF variables at once, which removes the controlled comparison needed to identify the cause.
• Treating one autoscaled screenshot or one unusually good result as proof without recording the settings and repeating the test.
• Assuming BLE remains on one RF channel after connection leads to incomplete captures and false packet-loss conclusions.

Final check​

Repeat the capture only against the owned or authorized device and verify valid frames after sanitization. Reopen the final shared file to confirm that identifiers, tokens and payloads are gone.