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]

So in this log (baby_logs.txt), is this from after the DFU, or is it the first time you turn it on (before ever bonding with the phone)?

If that is the case, then it doesn't have any devices in the whitelist, and I would assume that it doesn't have any devices in the peer manager either, since the whitelist typically uses the peer manager to load the addresses for the whitelist.

If that is not the case, then can you please describe to me what I am looking at in the baby_logs.txt log?

[Randy Lee]

Sorry, I forgot to say what we did exactly here... This is using Android 11 as the initiator

1. Set DFU mode
   • Set promiscuous mode on device (put it into a reception state where it is ready for bonding)
   • Connect 
   • Pair
   • Join (this is our special thing that tells it to whitelist the thing that bonded)
   • Send BOOTLOADER command (line 38)
   • Disconnect
2. DFU (this wouldn't be in the logs because the bootloader doesn't have that kind of instrumentation)
   
   • Connect with nRFconnect
   • Do DFU
   • Disconnect
3. Restore bonding
   • Connect with nRFconnect (line 53)
   • Pair
   • Disconnect

Search the document for POR; That the Power On Reset points so those are the points where the application running is regaining control from the bootloader.

Special note: the lines tagged with e.g. [1634809205.873] are part of the logging from the application itself.  Things tagged e.g. <debug> are Nordic code logs... you can ignore most of the lines from the application I think.

Note that the whitelist is still populated coming back so I have problems thinking that the bonding information is gone too...

Line 245: This is in response to PM_EVT_CONN_SEC_CONFIG_REQ on a pm event

I'll be able to focus back on this next week and get your code implanted and a log back to you on it.

[Edvin]

Are you reproducing this on a DK or custom HW? If custom, can you try to reproduce it on a DK? And does it only happen on a certain Android version (10) or on any android version? And have you tried iOS? Is there some way for me to replicate this issue on a DK with a phone? Preferably iOS, but I can try to get hold of an Android if I need to. 

From the logs, you are saying that on line 52, when it says "applied whitelist with addr_cnt=1 irk_cnt=1", it will still go through the pairing process? Is there anything in the logs saying when you need to pair or not?

BR,
Edvin

[Randy Lee]

This is full custom hardware; I rarely use a dev kit from anyone as they are so limiting to what I do. Reproducing it on the DK would be difficult as there is so much code there that assumes custom hardware.  Also we've seen this over 5 or 6 products all with the same basic code base.

As to Android version, We've seen it on 10 and 11 (these logs were produced with an 11 connection). Never tried it on iOS as we don't have the app we use with it on iOS and it's rather difficult to get the connection to begin with without the app.  We can try it at some point here tho as that would be something instructive I think.

Line 52 is saying that, when it comes back from POR, that there whitelist is still intact in flash storage.  That implies to me that any bonding information kept in the same basic storage place would be still intact.  I will have to verify that with your code suggestion the next time I get a chance.

Line 54 has what I assume is step 3 pairing requests and whatnot coming through. Ignore anything labeled "RFID:"  It's about 5 seconds later (line around 188) where we see the bonding completion....

The upshot is that these logs aren't as informative as they could possibly be.  I don't have an air sniffer at present to see the traffic here, which would be far more informative, and for that I apologize.

[Edvin]

I understand. 

Well, sometimes a custom log can give some insight in whats going on, but it is not always conclusive. 

For the iOS part, if you are using the standard bootloader from the nRF5 SDK (without too much modifications), you should be able to use the nRF Connect for iOS app to perform the update, and then try to connect to it afterwards, to see if it also requires to re-bond. This is just for debugging purposes, to see whether this issue is limited to Android, or on all platforms. Perhaps it can narrow down possible reasons for this behavior.

Best regards,

Edvin