bluetooth: non-discoverable devices show-up in chooser
Reported by
jra...@logitech.com,
Oct 26
|
|||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.67 Safari/537.36 Platform: 69.0.3497.120 (Official Build) (64-bit) Steps to reproduce the problem: 1. Grab a Bluetooth Low-Energy keyboard (e.g. Logitech Craft) 2. Short-press on one of the 3 host keys (1, 2, or 3). 3. Start web-bluetooth chooser GUI (navigator.bluetooth.requestDevice(...)) What is the expected behavior? Device should not show-up in web-bluetooth chooser What went wrong? Device shows-up in web-bluetooth chooser. Possible explanation: A bluetooth low-energy device that doesn't advertise itself as LIMITED_DISCOVERABLE or GENERAL discoverable, but just tries to reconnect to a previously paired host should NOT be shown in chooser. Initiating Gatt connect from host will fail. Did this work before? No Does this work in other browsers? Yes Chrome version: 70.0.3538.67 Channel: stable OS Version: 69 Flash Version: See the video I shot at https://drive.google.com/file/d/1LW6uPdnTMWEmceceVK_wdl4PRkFrulau/view?usp=sharing Upon short press, device tries to reconnect to host. Upon long-press, devices advertises for pairing (LE_LIMITED_DISCOVERABLE flag). Issue can be solved if using AdvertisingFlags on bluez (see https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/device-api.txt) - experimental API. On Windows, see https://docs.microsoft.com/en-us/uwp/api/windows.devices.bluetooth.advertisement.bluetoothleadvertisementflags
,
Oct 31
,
Oct 31
reillyg: Talked to Dmitry offline. We don't have any objections. Could someone on your team take on this?
,
Nov 5
Thanks guys for handling this.
,
Nov 17
I did a little extra research. On Android ScanRecord.getAdvertiseFlags() will return the flags. On macOS the flags do not appear to be one of the properties passed to centralManager:didDiscoverPeripheral:advertisementData:RSSI: but may be an undocumented property of the advertisementData NSDictionary.
,
Nov 18
I wonder if macOS just filters them out. jracle: Is this a problem on macOS as well?
,
Nov 20
Based on some mailing list posts I found when trying to figure out if this was exposed on macOS it sounds like they aren't filtered out of scan results but I'd appreciate a confirmation from jracle@.
,
Nov 21
Hi Reilly, thanks for asking. So here is what I can tell so far as regards MacOS after doing a few tests as well: - CoreBluetooth does not report advertising flags. Attached file "Craft reconnection" shows what I get on a keyboard that either advertises while reconnecting or while being discoverable. Also as I state, there is no pre-filtering apparently done by CoreBluetooth. - Just to let you know as well that bluetooth settings GUI is flawed.. See attached file "Craft pairing". If my keyboard was previously paired with another machine, and then I turn on my keyboard while my Mac is scanning, I get a first "Keyboard Craft" item. If I enter discoverable mode (long press on host 1 key for instance), the I get a second "Keyboard Craft" item. The 1st one is not connectable (connection will be rejected by firmware), while the 2nd item is! We reported the issue to Apple. |
|||
►
Sign in to add a comment |
|||
Comment 1 by ortuno@chromium.org
, Oct 28