BLE: Can't reconnect to a previously bonded device

[alexherriott-dmc]

Description of defect

Using Cordio and the device in the peripheral role, I can successfully connect, pair and bond to the device using a phone. Once disconnected though, I cannot reconnect to the device without manually clearing the bond information from the phone and re-pairing to the device. I would expect the bond keys to be preserved on the device and for the phone to re-form an encrypted connection without re-pairing.

I've tested this with a variety of configuration settings and functions from SecurityManager and BLE::Gap as well as saving the keys to non-volatile memory and can't seem to find anything that changes this behavior, so I'm fairly confident at this point this is a bug. Enabling WSF_TRACE_ENABLED and LL_TRACE_ENABLED in wsf_trace.h correctly shows that the original connection is successfully encrypted and the LTK is generated, but once disconnected, the stack does not seem to react at all to the phone trying to connect in the future and the connection times out. Is there something here I'm missing?

Target(s) affected by this defect ?

NRF52_DK, NRF52832

Toolchain(s) (name and version) displaying this defect ?

gcc arm 9-2019-q4-major

What version of Mbed-os are you using (tag or sha) ?

mbed-os-6.2.1 and mbed-os-5.15.3

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

mbed-cli

How is this defect reproduced ?

I've attached a slightly modified version of the BLE_SM example main.cpp that can be used to test this. It removes the central role and doesn't auto-disconnect. With the phone, connect, pair, disconnect, and try to connect again. Clearing the bond information in phone settings allows for the device to connect again. Tested with LightBlue and NRF Connect on iOS.

main.txt

[pan-]

@alexherriott-dmc Compatibility with various phone vendors is one of our focus at the moment, especially with the latest iOS version.

Can you detail the version of iOS and the version of the iPhone being used ?

[pan-]

As a quick workaround, can you start advertising with the public address (default is random static) ?
We noticed that with iOS it is not possible to reconnect a device if the advertising address is not the identity address (or a private resolvable address derived from the IRK).

You should call .setOwnAddressType(ble::own_address_type_t::PUBLIC) on your advertising parameters.

[AGlass0fMilk]

I have also encountered this issue and found it to be related to the address type advertised by default as @pan- said above.

Waiting to see the solution -- glad the BLE stack is getting some much needed attention.

[alexherriott-dmc]

@pan- Thanks for the quick response.

Yeah that seems to be the issue. The workaround works.
We've seen this behavior with:

• iPhone X iOS 13.6
• iPhone 6s iOS 13.6
• Samsung Galaxy s8, Android 9

One thing we're now running into: 1-2 seconds after re-connection on the android device the os disconnects the device with onConnectionStateChange: status 22. This seems to be related to this issue: #11809 . Is there a workaround you're aware of or any movement on this issue? On iOS the workaround seems to be working fine.

[pan-]

@alexherriott-dmc The second issue your describing might well be related to #11809 . Have you tried to set the LL_OP_MODE_FLAG_SLV_DELAY_LLCP_STARTUP to see if it fixes your issue ?
What LL_OP_MODE_FLAG_SLV_DELAY_LLCP_STARTUP does is just waiting for the first non control packet from master to start its LL control procedure (exchanging version, capabilities, ...), it should be safe to enable it. From the description of #11809 it seems like a race condition in the connection parameters update. Waiting for the master to finish may help with some stacks.

The issue for this ticket is very different, after pairing, it is not possible with the latest iOS to authenticate again if the initiation/advertising address isn't the Identity address exchanged during pairing or a resolvable private address derived from the identity address. This change is specific to iOS 13 if I'm not mistaken.
It might be implemented by other Android vendors like Samsung too but it isn't by all on the latest Android version (Google, Huawei, ...).
On Cordio, the identity address used by the device is always the public address, so to reconnect after bonding you must use the public address at the moment.

We're working on hard on bringing good privacy support for Bluetooth 4.x and 5.x controller on mbed. This should solve this issue as long as privacy is enabled (will probably be the new default when this land). In the meantime, we will update our docs to explain how to work on your device with privacy disabled which is often desirable for development.

[alexherriott-dmc]

@pan- Adding LL_OP_MODE_FLAG_SLV_DELAY_LLCP_STARTUP didn't seem to resolve the issue we were encountering with that particular Android device. We'll see if we can generate more detail and add to that ticket or a new one.

What does your schedule/pipeline currently look like for this ticket and the privacy support improvements like you mentioned? We'd like to get a better understanding of if and how that would fit into this particular project's schedule.

[pan-]

@alexherriott-dmc The privacy support improvement will be released in September. It should solve this issue.

[ciarmcom]

Thank you for raising this detailed GitHub issue. I am now notifying our internal issue triagers.
Internal Jira reference: https://jira.arm.com/browse/IOTOSM-2210

[pan-]

@alexherriott-dmc We're adding better privacy support to mbed-os, can you try #13717 ? Privacy should be enabled with the help of the function Gap::enablePrivacy() . I recommend not to set the device address to public in the advertising parameters, this workaround should not be required anymore.

[pan-]

@alexherriott-dmc Proper privacy support is available in Mbed OS 6.4. It should solve reconnection issues on the device listed above.

Can you test your application with the latest Mbed OS and privacy enabled ? You shouldn't need the workaround where the device advertises with the public address.

[ciarmcom]

We closed this issue because it has been inactive for quite some time and we believe it to be low priority. If you think that the priority should be higher, then please reopen with your justification for increasing the priority.