Checking my understanding of the -e and -H behavior

[XenoKovah]

I just got a pair of Creative Zen Air Plus headphones since they advertised LE audio, and I wanted to poke around with standards-based LE audio rather than whatever custom thing Apple came up with. (FYI they advertise both CIS and BIS in their manual, using those exact terms from the BT spec, albeit without spelling them out. So they may be appropriate for broadcast exploration too.)

These also seem to turn out to be the first devices around me which advertise ADV_EXT_INDs (15s after opening the case.) However, when I add the -e and optionally the -H, to try and see what extended data they're advertising, I don't get anything.

E.g. based on this packet:

I would expect it would go to channel 15 and capture an AUX_ADV_IND. However I don't see anything ~570us later, just more ADV_EXT_INDs.

Am I correct in thinking that if the -e option is given, Sniffle should be picking up some extra advertising packets between the ADV_EXT_INDs?

Also, am I understanding correctly that if one is specifically only looking for extended advertisements and their followup data, there's no need to use -H? (I.e. that -H is only for if you want to follow both legacy and extended advertisements, watching for a connection which could come in after advertisement on either of those channels?)

Also FYI this capture was done w/ fw 1.10.0

[sultanqasim]

It should be picking up the AUX_ADV_IND packets when you specify -e. The -H option should be unnecessary. My guess is that the process of receiving the ADV_EXT_IND, processing it, then retuning to channel 15 is too slow. For reference, for your ADV_EXT_IND, the preamble is 1 byte, access address is 4 bytes, header is 2 bytes, body 7 bytes, and CRC 3 bytes. That's a total of 17 bytes, so 136 us on the 1M PHY. The packet making its way from the radio CPU to the main CPU for processing takes ~200 us, the processing may take around 50-100 us, and then the time from issuing the retune command to actually listening on the new channel takes ~200 us. Combined, it might just be a few microseconds too slow to catch the AUX_ADV_IND whose preamble starts 570 us after the ADV_EXT_IND's preamble.

I made some recent changes to the firmware to reduce some latencies, so you can try the latest master branch of the firmware to see if it succeeds. You can also try the active scanning mode (using the -A flag in conjunction with -e) since it lets the radio CPU process the aux pointer and retune independently without needing the main CPU to tell it what to do.

[XenoKovah]

No luck with the latest firmware either, with or without -A in conjunction with -e.

[sultanqasim]

Hmm, I wonder what's going on then. If some of the packets have longer aux offsets (for example 870 us), that should be sufficient time for the firmware to hop. If you use something like nRF Connect on an Android device, does it see the auxiliary advertising data?

Another thing you could try is getting the sniffer to just sit on one of the secondary advertising channels (for example 10) and seeing if it catches any auxiliary advertisements that way. For this device, auxiliary advertisements should also be on the 1M PHY. You could do this by calling hw.cmd_chan_aa_phy(10, 0x8E89BED6, PhyMode.PHY_1M) for staying on channel 10 after the call to hw.setup_sniffer.

[sultanqasim]

If you want to see how this should normally work, use the Nordic nRF Connect Android app to set up an extended advertiser and sniff it with Sniffle. I'm not yet sure what your Creative headphones are doing differently.

[XenoKovah]

I confirmed that I can capture the nRF connect Android extended advertisements out of the box with Sniffle. And then I went and confirm the same version still didn't catch the AUX_ADV_IND follow ups to the ADV_EXT_INDs.

I then also confirmed the suggestion to add a hw.cmd_chan_aa_phy(10, 0x8E89BED6, PhyMode.PHY_1M) after hw.setup_sniffer() did allow me to capture the AUX_ADV_IND packets! (Which had a lot of extra data in them.)