Describe the bug
On Windows, winrtble::ble::watcher::BLEWatcher::start unconditionally calls
watcher.SetAllowExtendedAdvertisements(true) (and, as of #463, SetUseCodedPhy(true)
alongside it). On at least one real adapter, enabling AllowExtendedAdvertisements makes
Windows stop delivering Received events for a specific peripheral entirely - not
filtered out by btleplug's own logic, not a malformed/dropped packet, just never received
at all - even with a completely unfiltered scan (ScanFilter::default()).
This is different from #330 (advertisement events missed above a payload-length threshold)
and from #364/#402 (the call itself returning a hard error on old hardware, since worked
around by ignoring its Result) - here the call succeeds, and other devices keep
advertising and being discovered normally at the same time. It's specifically this one
peripheral, specifically while this one flag is enabled.
To Reproduce
Isolated with two independent BluetoothLEAdvertisementWatchers running side by side,
both ScanningMode::Active, both with no AdvertisementFilter set:
- Watcher A: default settings only (no
SetAllowExtendedAdvertisements call at all).
- Watcher B: same, plus
let _ = watcher.SetAllowExtendedAdvertisements(true);.
Watcher A reliably reports the peripheral in question (an nRF52-based BLE radio running
MeshCore firmware) within a few seconds. Watcher B never reports it at all, for scans
lasting 10+ seconds, while continuing to report several other nearby BLE peripherals
(headphones, other MeshCore-firmware boards, printers, phones) normally throughout. Toggling
that single line back off makes the same peripheral immediately visible again. Confirmed on
btleplug 0.13.0.
I don't have a minimal standalone repro I can share (it depends on the specific peripheral +
adapter combination), but wanted to flag this since it's a real, reproducible case of
btleplug's Windows backend silently missing a peripheral because of a hardcoded,
non-optional setting - worth being aware of for anyone debugging "peripheral X isn't showing
up in scan on Windows but works fine on Linux/macOS/Android" reports.
Expected behavior
Either: a peripheral visible to a default-settings BluetoothLEAdvertisementWatcher should
also be visible with AllowExtendedAdvertisements enabled, or (more realistically, since
this looks like it might be an OS/driver/adapter-level PHY scan-window trade-off rather than
something btleplug itself controls) there should be some way to opt out of
AllowExtendedAdvertisements/UseCodedPhy via the public API, so a caller who hits this can
work around it without patching the crate.
Platform info (please complete the following information):
- OS: Windows 11, build 10.0.26200
- Bluetooth adapter: Realtek Bluetooth LE adapter (Realtek Bluetooth LEAI Driver)
- btleplug version: 0.13.0
Additional context
Worked around downstream for now by running a second, unfiltered watcher without
AllowExtendedAdvertisements/UseCodedPhy set, forwarding what it sees independently of
btleplug's own event stream - happy to share more detail on that if useful, but it's very
specific to our use case and not something I'd suggest upstreaming as-is.
Describe the bug
On Windows,
winrtble::ble::watcher::BLEWatcher::startunconditionally callswatcher.SetAllowExtendedAdvertisements(true)(and, as of #463,SetUseCodedPhy(true)alongside it). On at least one real adapter, enabling
AllowExtendedAdvertisementsmakesWindows stop delivering
Receivedevents for a specific peripheral entirely - notfiltered out by btleplug's own logic, not a malformed/dropped packet, just never received
at all - even with a completely unfiltered scan (
ScanFilter::default()).This is different from #330 (advertisement events missed above a payload-length threshold)
and from #364/#402 (the call itself returning a hard error on old hardware, since worked
around by ignoring its
Result) - here the call succeeds, and other devices keepadvertising and being discovered normally at the same time. It's specifically this one
peripheral, specifically while this one flag is enabled.
To Reproduce
Isolated with two independent
BluetoothLEAdvertisementWatchers running side by side,both
ScanningMode::Active, both with noAdvertisementFilterset:SetAllowExtendedAdvertisementscall at all).let _ = watcher.SetAllowExtendedAdvertisements(true);.Watcher A reliably reports the peripheral in question (an nRF52-based BLE radio running
MeshCore firmware) within a few seconds. Watcher B never reports it at all, for scans
lasting 10+ seconds, while continuing to report several other nearby BLE peripherals
(headphones, other MeshCore-firmware boards, printers, phones) normally throughout. Toggling
that single line back off makes the same peripheral immediately visible again. Confirmed on
btleplug 0.13.0.
I don't have a minimal standalone repro I can share (it depends on the specific peripheral +
adapter combination), but wanted to flag this since it's a real, reproducible case of
btleplug's Windows backend silently missing a peripheral because of a hardcoded,non-optional setting - worth being aware of for anyone debugging "peripheral X isn't showing
up in scan on Windows but works fine on Linux/macOS/Android" reports.
Expected behavior
Either: a peripheral visible to a default-settings
BluetoothLEAdvertisementWatchershouldalso be visible with
AllowExtendedAdvertisementsenabled, or (more realistically, sincethis looks like it might be an OS/driver/adapter-level PHY scan-window trade-off rather than
something btleplug itself controls) there should be some way to opt out of
AllowExtendedAdvertisements/UseCodedPhyvia the public API, so a caller who hits this canwork around it without patching the crate.
Platform info (please complete the following information):
Additional context
Worked around downstream for now by running a second, unfiltered watcher without
AllowExtendedAdvertisements/UseCodedPhyset, forwarding what it sees independently ofbtleplug's own event stream - happy to share more detail on that if useful, but it's very
specific to our use case and not something I'd suggest upstreaming as-is.