Periodic advertising support?

[skig]

Hello! I like your solution very much and I think it is great!
I have a small question about your project plans.
Are there any plans to implement periodic advertising sniffing in the project?
Thank you

[sultanqasim]

Probably, though it’s not on my immediate list of priorities as not many things use it currently. I’ll probably implement it when I also start working on support for broadcast isochronous mode which is similar.

[mdxs]

Isn't this actually already included now?

At least in my first use of Sniffle today, one of my BLE peripherals (the DUT = Device Under Test) does periodical advertising; and as far as I can tell it is being captured when I listen to a specific MAC address (of the BLE peripheral).

Also, when I first listen to that (periodical advertisements of the DUT), then connect (to the DUT), in my case the BLE advertisements of the DUT stop (this is by design), and when I disconnect the DUT starts advertising again (also by design) and this is all captured by Sniffle in my case. I look at the PCAP in Wireshark and it makes sense to me.

But perhaps I don't understand the original question raised.

[sultanqasim]

This is about a specific Bluetooth 5 feature where an advertisement on a primary advertising channel can point to a train of periodic advertisements on a secondary/auxiliary advertising channel. I haven’t yet encountered any real life devices that use this, so I haven’t yet bothered to implement it.

Essentially every Bluetooth device puts out advertisements roughly periodically on primary advertising channels (as you said), and Sniffle can capture those just fine.

[mdxs]

Thanks for the clarification!

[sultanqasim]

This is next in terms of major features I want to implement