SCAN_RSP data missing

[jsmif]

For all the data I capture, I always see the SCAN_RSP data missing, as shown below:

Is this expected?

[jsmif]

I would note that some of these could be legitimately empty. But the issue is that when I sniff with Sniffle, while I see some no-name-data, length-6, packets, I also see some of the expected length != 6 packets with device names from my devices coming back.

FWIW I tested with the below while running a scanner (https://github.com/emericg/toolBLEx) for a bit to try and generate some SCAN_RSPs

./ice9-bluetooth -l -i bladerf0 -w 20_channels.pcap -s -c 2427 -C 20
 - Which my CPU can handle fine
./ice9-bluetooth -l -i bladerf0 -w 40_channels.pcap -s -c 2427 -C 40
 - Which is at the limit of my CPU (~= 100%)
./ice9-bluetooth -l -i bladerf0 -a -w all_channels.pcap -s
 - Which exceeds my CPU (~= 50+%)

None of the pcaps had non-length=6 SCAN_RSP packets.

[mikeryan]

I believe what you're observing are fully captured packets with empty SCAN_RSP sections. If you are indeed seeing SCAN_RSP data with other tools, it's likely we're missing them. You should be able to capture them with your first command.

Can you tell me what devices are generating the SCAN_RSP packets you're looking for?

[jsmif]

@mikeryan I wanted to give you some better data about this now that there's a new and better version of Sniffle out. However, when I come back to this and run the same commands as above, I get the following error:

sudo ./ice9-bluetooth -l -i bladerf0 -w 20_channels.pcap -s -c 2427 -C 20
Password:
[WARNING @ /privatehost/libraries/libbladeRF/src/board/bladerf2/bladerf2.c:916] Oversample feature gain limit reached. RF Gain clamped to 11.
[ERROR @ /privatehost/libraries/libbladeRF/src/streaming/async.c:107] FPGA does not support 8bit mode. Upgrade to at least FPGA version 0.15.0.
ice9-bluetooth: Unable to initialize bladeRF stream: Operation not supported

I literally haven't touched this since last year, so my only thought is that maybe some OS upgrade broke something. Any ideas what can cause this error? (git log says I'm still on the June 1 tag: commit 489d75a91055ef8fec0d0aade6b332455e35c764 (HEAD -> master, tag: v23.06.0)

Edit: I found the older issue #17 and just re-ran the bladerf-cli -l hostedxA9-latest.rbf and that fixed it (during the update it said "FPGA v0.15.0 was detected," so idk what its problem was...). I'll investigate getting some equivalent SCAN_RSP from Sniffle and ice9 now to show.

[jsmif]

OK, so here's what I can confirm based on new tests:

1. According to Sniffle's view, sniffing channel 39 exclusively, there are definitely some things in range of me like Apple TVs which do generate SCAN_RSP with a len of 6 which consequently shows up in Wireshark as "Scan Response Data: <MISSING>"
2. ice9-bluetooth appears to be missing lots of packets when just trying to sniff a single channel.

Reproducing:

1. On macOS run sudo ./ice9-bluetooth -l -i bladerf0 -w channel_39_only.pcap -s -c 2480 -C 8 to minimize the sniffing to as close to only channel 39 as I can get (due to ticket bug: ice9-bluetooth doesn't actually allow a value of 4 for -C #30). Start this before step 2.
2. Set up a single TI board with Sniffle v1.9 to sniff only channel 39 within Wireshark in a Linux VM. Start this after step 1.
3. Set wireshark filter of (btle.advertising_header.pdu_type == 0x4) && !(btle.advertising_header.length == 6) and wait for 10 or so packets with non-missing SCAN_RSP data to show up in wireshark. Stop wireshark.
4. Stop ice9-bluetooth. Open channel_39_only.pcap in Wireshark and apply filter (btle.advertising_header.pdu_type == 0x4) && !(btle.advertising_header.length == 6).

Result:
I see only 3 SCAN_RSP despite the fact that Sniffle saw 16 packets in the same time period.

Conclusion:

1. The original ticket is incorrect in that ice9-bluetooth can see SCAN_RSP with non-empty data.
2. ice9-bluetooth is missing a bunch of packets compared to Sniffle even when just sniffing a single advertisement channel.

Should I start a new ticket for the packet loss issue or do you want to investigate here?