Pairing issues with S110 v8.0.0

[Jerome]

It may sound a bit old and you may have fixed them in latest Soft Device stacks however I wanted to share with you a couple of pairing issues we encountered with Soft Device 110 version 8.0.0.

The project we have been working on is a simple UART module to go into an existing machine to connect it to a Smartphone and associated Cloud. The module supports standard pairing and bonding via the app to ensure secured connections. The module pairing state is controlled via a specific serial command.

When testing interoperability of the module with various devices, we encountered issues with 2 types of devices:

1. Gionee Amigo supporting random private non resolvable Bluetooth address In this case, the mobile phone pairs and connects to the module via our app or nRF Connect, however after releasing the connection, it does not connect anymore and the module is left in a non workable state. The module application does not start so the module does no longer advertise (so it can’t be paired and connected with another device) and it is not possible to control it via UART serial commands. As a result, we decided to exclude any mobile phone with random private non resolvable address in the pairing procedure to avoid such a nasty case.

2. iOS devices supporting random private resolvable Bluetooth address with IRK In this case, pairing and connection works fine in normal conditions but connections would fail after having removed the module from the iOS paired device list and attempting a new pairing. We found out that the module is registering another time the same iPhone in white list and this may be the reason for the connection issue. As a result, we decided to remove the previously bonded address and keep only the latest bonded address after comparing the 2 addresses in white list and this resolves the problem.

I trust these issues have been fixed in latest Soft Device stacks however I preferred to let you know in case this has not been addressed. It is also possible that we have been doing something wrong. In any case, it would be good to get a feedback from your engineering team.

[run_ar]

Thank you for reporting theses issues. Note that these are not stack issues, but limitations in the SDK device manager. Also note that for newer SDK's we have moved to a new module called peer manager.

1. In this case you should make sure you are not using the whitelist feature. As this will block the non resolvalbe address if it is changed.

2. This is a limitation with the Device manager. As it uses the address of a device to identify it, but not the IRK. Since iOS uses a resolvable private address it might change (every 15 minutes actually) and your workaround of comparing the address might not work (unless you already use the IRK to resolve the address). Anyway, I would not recommend allowing a new bond from an unknown device. The reason I claim this is an unknown device is that anyone could copy the known address to connect to your device. the peer has to be authenticated by the encryption keys, using ediv and rand to identify the keys. If the iOS device lost it's keys it's not possible to know it's the same device. At least be aware that "auto refreshing" might be a security treath.