nRF8001 doesn't acknowledge LL_VERSION_IND

[Stephan Walter]

Hi,

We are using an nRF8001 with bonding.

We tested the use case were a bond has been established with an iOS app. Then the connection was terminated by closing the iOS app.

Now we establish a new bond with a different device. Again we close the connection.

Now we try to re-connect to the iOS app, where the iPhone still has the old bonding information, but the nRF8001 has a new (wrong) bonding information.

In this case, the iOS sends a LL_VERSION_IND packet, which the nRF8001 fails to acknowledge even after multiple retries. See sniffer trace nrf8001-ios-wrong-bond.pcapng. During this, there are no ACI events generated by the nRF8001, so on the peripheral side there is no way for us to know when this behaviour occurs.

If, instead of establishing a different bond, we simply delete the bonding information on the nRF8001, the behaviour is different: The connection will be setup but of course the encryption will fail. See sniffer trace nrf8001-ios-no-bond.pcapng

With Android, we do not have the problem even when the wrong bonding information is present on the nRF8001 (possibly because Android doesn't sent an LL_VERSION_IND packet). See sniffer trace nrf8001-android-wrong-bond.pcapng.

Is there anything we can do to handle the situation more gracefully? Of course the original bonding information is lost, but it would be nice if we could either restart the bonding process or indicate an error to the user.

[run_ar]

When you captured the iOS trace, what is the device bonded with nRF8001?

[run_ar]

If the nRF8001 is bonded to a device that has a static address (Android), it will enable address based whitelisting. If it is bonded to a device with a private address (iOS) it will not enable this whitelist (this is because iOS changes its address every 15th minute). Looking at your iOS capture it looks like the whitelist is enabled.

Edit: You could possibly change this behavior by modifying the setup data. Change the whitelist bit in devsett 0x1 -> v3_data -> features.

[Stephan Walter]

Hi, thanks for your response. I did the test with an Android and an iOS device, so for the iOS capture the nRF8001 was bonded with the Android device and vice versa.

If I'm understanding you correctly, if we would test this with two iOS devices, the behaviour should be the same as in the Android trace, that is the connection should be set up but encryption would fail.

It seems that the behaviour of the nRF8001 is as it should be, and we have to try to react to this case in the app.