[most AsteroidOS watches] Not showing up in Bluetooth menu on iDevices

[GeckoEidechse]

Describe the bug Based on a discussion in the Matrix channel as well as https://github.com/AsteroidOS/asteroidos.org/pull/241 we found out that while generally the watches supporting AsteroidOS show up in the Bluetooth menu on iOS/MacOS while running WearOS, they do not show up while running AsteroidOS. They can however still be discovered and paired on e.g. an iPhone using a 3rd party app like nRF Connect. As such we might wanna find out why they do not show up in Bluetooth settings by default.

To reproduce Steps to reproduce the behavior:

1. Own an Apple device like an iPhone
2. Enable Bluetooth on your watch (e.g. `lenok``) running AsteroidOS
3. Go to the Bluetooth settings on your iPhone
4. The watch won't appear as a listed Bluetooth device

Expected behavior The watch should show up as a listed Bluetooth device (at least if it would also do that when running WearOS)

Device (sample):

• Watch Codename: lenok
• AsteroidOS Builddate 2022-02-10
• Version nightly

trying to pair with an iPhone 12 Mini running iOS 16.3.1

Additional context None

[beroset]

I have now tried this with an old Macbook Pro running Darwin version 11.4.2 (yes, it's old -- August 2012) and was able to see this problem when attempting to pair it with a sturgeon. I noticed a few things that may be relevant. First Apple's version of "Bluetooth Setup Assistant" says in the user dialog, "If you don't see your device in the list, make sure it is powered on and 'discoverable.'" and indeed I was unable to see my device (or any device!) in the list.

I used bluetoothctl on the watch and was able to verify that the watch is not "discoverable." The first few lines printed by bluetoothctl show are these:

	Name: sturgeon
	Alias: sturgeon
	Class: 0x00000000
	Powered: yes
	Discoverable: no
	DiscoverableTimeout: 0x000000b4
	Pairable: yes

I tried to set Discoverable on:

[bluetooth]# discoverable on
Failed to set discoverable on: org.bluez.Error.Busy

So it appears that I can't make it discoverable, even though I tried both as ceres and as root users.

I was able to verify that even in this state, my nearby Linux laptop is able to find and pair with this sturgeon, build ID 20230108190811.

[beroset]

I have now also tried the experiment with an iPhone SE running iOS version 16.3.1 and catfish. I am unable to get the iPhone's application to "see" the unpaired watch and I am also unable to set discoverable on with the exact same message as on sturgeon as noted above.

Using nRF Connect, however, both sturgeon and catfish pop up immediately and I can successfully pair to both within that application.

[beroset]

Aha! The way to make this work is to change /etc/bluetooth/main.conf on the watch so that instead of ControllerMode = LE, which we have by default, ControllerMode = dual allows us to change the watch to be discoverable. Once that is done, both the iPhone and Macbook Pro can see and pair with the watch.

Thanks to @dodoradio for the hint in Matrix chat.

[GeckoEidechse]

Aha! The way to make this work is to change /etc/bluetooth/main.conf on the watch so that instead of ControllerMode = LE, which we have by default, ControllerMode = dual allows us to change the watch to be discoverable.

Is there a reason it's currently set to LE? I assume maybe for power saving reasons?

[dodoradio]

Aha! The way to make this work is to change /etc/bluetooth/main.conf on the watch so that instead of ControllerMode = LE, which we have by default, ControllerMode = dual allows us to change the watch to be discoverable.

Is there a reason it's currently set to LE? I assume maybe for power saving reasons?

yes, it's for power saving reasons. We don't use the bluetooth classic mode at all in a standard asteroid install, and using LE-only saves a lot of power. It's architected completely differently, as far as I understand the bluetooth controller can do quite a lot without involvement from the cpu.

Aha! The way to make this work is to change /etc/bluetooth/main.conf on the watch so that instead of ControllerMode = LE, which we have by default, ControllerMode = dual allows us to change the watch to be discoverable. Once that is done, both the iPhone and Macbook Pro can see and pair with the watch.

I think apple has misimplemented something in their bluetooth stack. LE-only devices shouldn't have to use the 'classic' pairing mechanism. This sounds like an iBug, not an asteroid bug.... In any case, we should research this more. Perhaps there's some special profile specific to BLE devices intended for use with iOS/Mac? It sounds really strange that Apple would lock themselves out of the entire market of BLE-only gadgets like this (though it's not a totally wild idea, considering their whole MFI certification system)

[beroset]

It looks like, indeed, it's an iBug. See https://stackoverflow.com/questions/27840199/display-and-pairing-ble-devices-on-bluetooth-device-list-in-settings for details, but essentially, BLE-only devices are simply not pairable without a separate app.

For that reason, I think I need to rework the recently updated instructions to say that, in fact, something like nRF Connect is required to pair. Thanks to @GeckoEidechse for inspiring this investigation! I realize now that with all of my pairing and unpairing with the iPhone, a device that is paired (either because it is in dual mode or because it was paired with something like nRF Connect) can be unpaired ("Forget this device" on the iOS Bluetooth menu) and it will show up under the "other devices" because of caching. This was what led me to falsely believe that a BLE-only device could be paired with nothing but the iOS Bluetooth settings.

[GeckoEidechse]

Made PR to update wiki again in regards to iOS: https://github.com/AsteroidOS/asteroidos.org/pull/259

[GeckoEidechse]

The fact that iOS doesn't show BLE devices in Bluetooth settings is definitely intentional. I think the reason is to not overwhelm the user with too many devices. For example opening nRF Connect on a crowded train instantly gives me 30+ devices. Instead by requiring the user to put their device into a "pairing mode" that pulls it from BLE to whatever the name for the "high power" equivalent is, they can effectively filter out most devices that the user isn't interested in. At least that's my theory ^^

Similarly device specific apps can filter out all BLE devices with hardware addresses from other vendors, resulting again in a less crowded list.

With that said, do we wanna work around this in AsteroidOS? For example we could introduce a "pairing mode" where we'd switch ControllerMode = LE to ControllerMode = dual for short time period 30s-60s which would give the user enough time to pair the device from default iOS Bluetooth settings. That way we can avoid guiding the user to a 3rd party BLE app (though we can still mention it cause it's quite useful). Obviously an iOS companion app for AsteroidOS would be even nicer but we'd need to find someone willing to invest time into it first :P

[beroset]

An iOS companion app is certainly the better approach!