Android asking for pairing after DFU

[Randy Lee]

Using SDK 15.3 on the embedded side and Android 10 I think it is on the mobile side.

We've implemented whitelists and hanging onto the bonding information on the embedded side.  The idea is that once the mobile side is talking to us we only want to talk to that particular device until we explicitly change to another one.

This works fine across power cycles on both sides.  Once paired and bonded and everything, the mobile side and embedded side exist in married bliss.

Now, pull up nRF connect and run a DFU on the embedded side. Once the embedded side comes back (and it is keeping all the bonding information and whitelists and all that across this as far as I can tell), Android wants to pair again...

I just don't understand why this is.  We've got the bonding information both sides as far as I know. Why does the Android side really want to pair again?  Am I missing something on the embedded side?

[Edvin]

Hello,

So it is after the update is complete, and you try to connect to it again like it was before (in the married bliss) that it wants to pair again, is that correct? 

Do you see whether the peripheral device has changed anything? Or did you try to debug the applciation? Is the bonding data still present on the peripheral? Does the peripheral use the same Bluetooth LE address as before the DFU update took place?

Best regards,

Edvin

[Randy Lee]

yes, after the DFU has completed. Everything should be the same as before the update as all that information is being saved as far as I know...  Power cycles of either side of that prior to DFU does not cause this repairing request so I'm pretty sure it's being saved.

Android itself is popping a "you want to pair?" message.

[Randy Lee]

The "Allow repairing" thing is a code note to myself meaning, in this case, that we've got something in the whitelist and to allow that MAC address to talk to me.  The app is very locked down here using whitelists to not allow anyone to connect to it unless it's gone through some serious upper level handshakes.  This notation just says that, yes, the whitelists survived the update.  Those whitelists use fds so that are hasn't been wiped (this was a previous bug that we had in the code)

1) Yes, we're using a couple of different ones. One team tends to use a Pixel and most of the other teams tend to use a Lenovo tablet.  Different versions of Android.

2) The bootstrap here is effectively the buttonless dfu using SDK15.3 (with a couple of mods backporting some SDK17 fixes). 5707.bootloader.zip

[Randy Lee]

Oh, and, I understand the time thing in the summer.... Thank you for being able to keep following this thing...

[Edvin]

Hello,

Ok. I am back (and will stay for a while this time).

Can you please try to capture a sniffer trace of the connection being entered. Preferably one after a DFU, and one with a normal connection (where the bonding is not requested). Please note that in order for the sniffer to be able to follow into a bonded connection, you probably need to erase the bonds, connect -> bond -> disconnect -> reconnect for the sniffer to be able to capture the LTK. If you are using OOB (6-digit passkey), you need to enter this manually in the sniffer.

To capture a sniffer trace, you can use the nRF Sniffer for Bluetooth LE.

And again, if there is some way for me to reproduce this, please zip a project application that can reproduce the issue. You say that it is a slightly modified ble_app_buttonless_dfu application, but please zip the one that is used for reproducing the issue. I also see that you are mixing a few different SDK versions. Can you please try to stick to one, and see if it is still reproducible, just to make sure that it is not the backport that is causing something to behave weirdly?

Best regards,

Edvin

[Randy Lee]

TOok some time as we had to get the hardware to do this, but attached are the sniffer logsconnection after DFU.pcapngnormal connection.pcapng

[Einar Thorsrud]

Hi,

I have inherited this case from Edvin.

Looking at connection after DFU.pcapng, everything looks normal, as if connecting to a device with no existing bond. My first gut feeling after reading this thread was that perhaps the nRF BT address was different, but that is the same in both traces, so that is not it. Could it be that your custom app for some reason deletes the bond when performing DFU? Are you able to reproduce this using only nRF Connect for mobile and not your app at all (make sure it is not running in the background as well)?

Einar

[Randy Lee]

Greetings Einar!

Yes, this is generally reproduced using mobile version of nRFconnect on Android phones.

[Randy Lee]

thought:  The device is using all the normal Nordic code and mechanisms for this stuff along with the soft device.  Keys and such are stored in FDA areas as usual (see above).  Is it possible for the android app to be asking for connections and keys before something is ready on the device side to deal with it so that it thinks that the information hasn't been stored?

Thinking outside the box here. I don't see how, but then again, things happen with embedded systems that aren't always obvious.