Scanning on Linux does not return all peripherals

[ferbarra]

There are some peripherals that are only returned when performing a scan_get_results() from windows. Calling scan_get_results() on Linux (Fedora) only returns some peripherals but not all. The linux machine uses an ASUS BlueTooth 4.0 USB dongle adapter.

I can also find the peripheral using the "nRF Connect" app on Android. The peripheral I'm interested in appears as a "LE only" device and has the "Advertising type" set to legacy. Here is the raw data: 0x0409464552.

Any ideas on how to pinpoint the problem?

[allanvaughanjones]

@ferbarra I think I'm seeing a similar thing. Running on Raspberry Pi OS (Bullseye). The C++ scan example finds 4 devices; Scan started. Found device: [60:04:1F:86:3A:DD] -83 dBm Found device: [4A:9E:BD:BA:33:D0] -75 dBm Found device: mpy-uart [D8:3A:DD:43:4F:D5] -83 dBm Found device: [4F:B9:D9:07:25:99] -78 dBm Updated device: mpy-uart [D8:3A:DD:43:4F:D5] -69 dBm Scan stopped.

Running $sudo hcitool lescan on the same machine gives; LE Scan ... 3A:0E:2B:E8:55:54 (unknown) 4A:9E:BD:BA:33:D0 (unknown) 04:B9:E3:23:3C:01 (unknown) 0F:98:91:1B:BF:8A (unknown) 4F:B9:D9:07:25:99 (unknown) 07:91:5C:8B:8D:1C (unknown) EE:48:BA:E5:7A:04 h2o383E9 7B:90:D3:9D:FC:EB (unknown) F9:2A:F3:67:51:C6 (unknown) CE:2A:47:C0:3C:D6 (unknown) D8:3A:DD:43:4F:D5 (unknown) C3:00:00:02:EF:0D (unknown)

Did you resolve the problem?

[allanvaughanjones]

Just a further bit if information on this; If I modify Adapter1 (SimpleBLE/simplebluez/src/interface/Adapter1.cpp) void Adapter1::StartDiscovery() { DiscoveryFilter myFilter; SetDiscoveryFilter(myFilter);

auto msg = create_method_call("StartDiscovery");
_conn->send_with_reply_and_block(msg);

}

then I get all of the peripherals shown. There doesn't seem to be a way to set the filter from the SimpleBle API.

So now I can see the device I wish to connect to in the scan, but connection fails - I've added a bit of debug; device_->connect(); failed org.freedesktop.DBus.Error.UnknownObject: Method "Connect" with signature "" on interface "org.bluez.Device1" doesn't exist.

I think this may be due to the peripheral having a random static address.

[MikeNeilson]

I was able to take what @allanvaughanjones provided and make a slightly more generic workaround for my application:

#ifdef __linux__
    auto bluez = (SimpleBluez::Adapter*)adapter.underlying();
    SimpleBluez::Adapter1::DiscoveryFilter filter;
    filter.Transport = SimpleBluez::Adapter::DiscoveryFilter::TransportType::LE;
    filter.DuplicateData = true; // I didn't actually need these two as they are the default.
    filter.Pattern = "";
    bluez->discovery_filter(filter);
#endif

There's probably an even better way to properly verify it's actually using Bluez instead of DBUS or something before doing that casting, but that worked for my simple application.

And it case others have similar issue: My old laptop and Raspberry Pi 3b had Bluetooth 4.1 controllers and just wouldn't return anything even after. I bought a usb 5.1 adapter and got my expected results. (My current application is "beacon" data from an Arduino Nano BLE device.)

I also had to make sure I was using both set_callback_on_scan_updated and set_callback_on_scan_found; but I suspect that's because I'm not pairing anything, just passively listening for the "manufacture data" packets.

[jcelerier]

Same here. Another workaround is to send a scan le command to bluetoothctl and SimpleBLE will start reporting the BLE devices too.

[kdewald]

Hey, thanks to all for the feedback.

Is it possible that the discovery filter is being overwritten by some other application. I'll make sure this gets added.

[kdewald]

I just had a moment to look into this. It seems that the most likely cause here is that we're relying on the default filter settings that the operating system is using and if those get modified we can be affected as well.

The fix is quite straightforward, so it will definitely make it into v0.10