nRF Sniffer misses CONNECT_IND when a SCAN_REQ/SCAN_RSP happens on channel 37 or 38

[Peter Langer Keysoft]

Setup: nRF52840 Dongle, sniffer FW 4.1.1, nrfutil 8.2.0 with the ble-sniffer plugin 0.20.0 on a Raspberry Pi 5. Two nRF54H20 DKs (NCS v3.2.4) — one advertising (ADV_IND, ~107 ms), one actively scanning and then connecting. The sniffer follows the advertiser:

nrfutil ble-sniffer sniff --port /dev/ttyACM0 --output-pcap-file c.pcapng \
        --follow E9:9A:46:47:47:25 --rssi-cut-off -75

Problem. If the central sends a SCAN_REQ and gets a SCAN_RSP on ch37 or ch38, the following CONNECT_IND is not captured. The capture simply stops at the SCAN_RSP — no CONNECT_IND, no data-channel packets, no error or warning in the sniffer log:

ADV_IND   ch37  -28
ADV_IND   ch38  -27
SCAN_REQ  ch38  -19
SCAN_RSP  ch38  -27
   <- nothing after this

If the same exchange happens on ch39, the CONNECT_IND is captured normally and the connection is followed onto the data channels. If the central does not scan actively and only sends CONNECT_IND, it is captured 100 % of the time on all three channels — so it is not a blind spot on a particular channel.

12 sessions, all consistent: scan exchange on ch37/ch38 → no CONNECT_IND (7 runs); on ch39 → CONNECT_IND captured (5 runs).

The lost window is one advertising event: the central connects ~113 ms after the SCAN_RSP (measured on the peripheral's console), against ~107 ms event spacing. It looks as if the scan exchange interrupts the sniffer's 37 → 38 → 39 sweep mid-event and it needs a whole event to recover — which is exactly the event carrying the CONNECT_IND. On ch39 the sweep was ending anyway, so nothing is lost.

Questions: Is this a known limitation of follow mode, and is there any setting that avoids it? Switching the central to passive scanning works around it, but that is not an option when observing a device that must scan actively before connecting.

[Amanda Hsieh]

Hi Peter, 

Since the Nordic chips only have one antenna, the sniffer can only observe a single RF channel at a time. With the default configuration, the nRF Sniffer waits for a packet on channel 37. After it receives a packet on channel 37, it transitions to sniffing on channel 38. When it receives a packet on channel 38, it transitions to sniffing on channel 39. When it receives a packet on channel 39, it starts sniffing on channel 37, and repeats the operation. See Sniffing Bluetooth LE packets and Advertising hop sequence.

The sniffer documentation explicitly notes that "The nRF Sniffer might not pick up all connect requests and does not always pick up on a connection", and there is no setting in the documentation specifically designed to prevent this state transition issue when an active scan response is received mid-sequence.

Regards,
Amanda H.