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?

[Randy Lee]

iOS: my engineers are reporting that iOS does not have this problem..  

They did run into a services cache problem on that platform, but that's another problem (see https://developer.apple.com/forums/thread/76339)

[Edvin]

As it is mentioned in that ticket, you need to enable the SERVICE_CHANGED in sdk_config.h of your application. Ironically, adding it later wouldn't help, but if you add it in your initial application, that should solve that. So for the phones that have already cached the services, First forget the device from the iPhone's bluetooth menu, then turn off bluetooth from the phone's settings (Settings menu, not the "drag up from bottom menu"). Wait for about 15 seconds, and turn bluetooth back on. Then it should be forgotten. Then, if you have the service changed service enabled, then the peer manager will use this to tell the phone to do a new service discovery if it has new services.

Now, regarding our issue:

I need you to check the number of peers in the peer manager (using the snippets in my answer from 13th of june. 

Does this also happen if you use the "normal" bootloader and e.g. the ble_app_buttonless_dfu example to perform the update? Did you test this? If you test this with ble_app_buttonless_dfu, there is a setting in sdk_config.h called NRF_DFU_BLE_BUTTONLESS_SUPPORTS_BONDS. Leave this set to 0, because this does a couple of things. Then try to open ble_dfu_unbonded.c, and set:

    add_char_params.cccd_write_access = SEC_JUST_WORKS;
    add_char_params.write_access      = SEC_JUST_WORKS;
    add_char_params.read_access       = SEC_OPEN;

in ble_dfu_buttonless_char_add(). That should trigger the pairing/bonding in the app, and then you can perform a DFU and try to connect again. Does that trigger the issue where you need to bond again?

NB: This example already have the NRF_SDH_BLE_SERVICE_CHANGED set to 1.

Best regards,

Edvin

[Randy Lee]

Our app uses the Nordic buttonless bootloader as the base for the bootloader portion and is called by the application to get it started..

The version we're running has those parameters set:

    add_char_params.cccd_write_access = SEC_OPEN;
    add_char_params.write_access      = SEC_OPEN;
    add_char_params.read_access       = SEC_OPEN;

since we can't get there but by a bonded thing that is explicitly whitelisted.

I'm still attempting to get the number of peers seen.  For some interesting reason that particular piece of code is being an issue in situ.  It gives me an output using SES directly but not if I'm using RTT viewer. Curiously all the stuff around it gives me output so I'm having some experiments done to figure out just why that it... I hope to have some usable data early next week.

[Randy Lee]

so we got that code to work... I've annotated the output from that code with "bounds: " so as to note it specifically from the other things that are logging... You'll find it towards the back.  This output here is right after the thing is booting after a DFU:

00> [1634810895.013] POR Vbat: (2.41V)
00> <debug> nrf_sdh_freertos: Creating a SoftDevice task.
00> <debug> ble_scan: Adding filter on RWStudentID name
00> <debug> nrf_sdh_freertos: Enter softdevice_task.
00> [1634810895.253] FDS: File found
00> [1634810895.253] FDS: File read successfully
00> [1634810895.253] Whitelist: Whitelist file found. peer_id=0
00> [1634810895.255] FDS: File found. Writing data into it
00> [1634810895.255] FDS: Write succeeded.
00> [1634810895.260] Baby service: Version=0.8.4.9, Family=91, ProgramChecksum=87778671
00> [1634810895.263] BLE: bounds: peer_count: 2
00> [1634810895.263] BLE: bounds: peer id 0 is valid
00> [1634810895.263] BLE: bounds: peer address: f0:5c:77:f5:2f:63
00> [1634810895.263] BLE: bounds: peer id 1 is valid
00> [1634810895.263] BLE: bounds: peer address: 94:be:46:11:e2:5b
00> [1634810895.265] FDS: File found
00> [1634810895.265] FDS: File read successfully
00> [1634810895.265] BLE: Whitelist contains a peer. Start advertising.
00> [1634810895.265] Whitelist: Applied whitelist with addr_cnt=1 irk_cnt=1

The first one (peer ID 0) is the current MAC address of the device talking to it.. I don't know what the second one is, but it's possible it's the same device as Android phones can apparently change MAC addresses from time to time (this one is a Pixel 4 running Android 11

[Edvin]

Randy Lee said:

I don't know what the second one is, but it's possible it's the same device as Android phones can apparently change MAC addresses from time to time

Yes they do, but they shouldn't take up more than one peer. There are mechanisms to recognize peers that have changed addresses using an IRK (Identity resolving key).

When you connect to the bonded device after the DFU is performed, do you get the event (on the nRF) PM_EVT_BONDED_PEER_CONNECTED?

BR,

Edvin