[Bouncingsoul1]

No it is not, IMO. These devices are only ever usefull if you have unencrypted connections, with peripherals with static addresses. Add either random addresses or encryption and you won't have any success while debugging. So this tools are not usefull for 99% of peripherals you see around. These cheap tools can only operate on 1 frequency at a time. BLE Advertisments are done one 3 channels (37,38,39), you have to listen to all of them to get the init of the connection. With this cheap devices you have 66% you miss some parts of this and thus fail to follow the connection and encryption on the remaining 36 channel (BLE does dynamic channel hopping, the channel list is exchanged within the connection). Plus with only 1 channel, it will sooner or later fail to follow the connection and this is usually just before you could repro the issue at hand.

Believe me if you want to do anything serious you have to invest some money. Up to BLE 4.2 i would suggest https://fte.com/products/bpalowenergy.aspx which comes around 1000€. There is so no follow up for 5.0 (which more and more devices have now) so I have no suggestion there (unless you want to invest 10.000+++)

[kallistisoft]

Very much depends on what you're trying to do... In my case I wanted to examine the raw traffic between two devices that I had written software for and had full control over. I found it worked just fine as the debug version of the code doesn't implement any of the ble security features. Also had no issues using the dongle to examine ble 5.x traffic.

[Bouncingsoul1]

Yes thats true, but even if I have access to the device firmware, which I usually do, so I can build an unecrpyted version and this usually leads to the problem not being reproducible or showing differently... Anyway I want to reproduce the problem as close to production fw as possible. So via our time/effort calculation, spending some money on a multichannel sniffer was surely worth it.

[1231112315123]

Great note, didn't think of this limitation when using the dongle previously.

One question though, doesn't the sender transmit advertisements sequentially on all of the broadcast channels? So at least for BLE advertisements, they should all appear on the advertisement channel you're listening on - even if that's just one of them?

[dromtrund]

This is true, but the connection request only comes on one channel. The sniffer can be set up to follow an advertiser though, which makes it jump to the next channel in the sequence as soon as the time window for sending a connection request after the advertisment is gone. It picks up connection requests virtually every time in this mode.

Both this and encrypted communication interpretation works a lot better than the commenter above you claims. They've either not tried this sniffer, and are only making claims based on assumptions, or they haven't learned how to use it properly.

It's definitely not as good as commercial sniffer hardware, but it's perfectly fine 90% of the time, and the price is two to three orders of magnitude lower.

[_flux]

Wouldn't MitM attack work, though?

I found this one, doesn't seem to be maintained but the concept seems clear: https://github.com/PaulPauls/Bluetooth_LE_MITM

It doesn't seem to be concerned about encryption, but would that typically be a problem?