Sharing bonding info with DFU but getting BLE_GAP_EVT_CONN_SEC_UPDATE that causes issues

[GaryG]

I have the application saving off the information it should from the Nordic documentation titled "Sharing bonding information" which is part of the Info center software developers kit example section: m_peer_data.addr = key_set.keys_central.p_id_key->id_addr_info; m_peer_data.irk = key_set.keys_central.p_id_key->id_info; m_peer_data.enc_key.enc_info = key_set.keys_periph.enc_key.p_enc_key->enc_info; m_peer_data.enc_key.master_id = key_set.keys_periph.enc_key.p_enc_key->master_id;

I get the bootloader to start up and find the information, it bonds to my application and according to the Nordic Sniffer application the connection is encrypted. Then the S110 bootloader quickly gets a BLE_GAP_EVT_CONN_SEC_UPDATE event with data of security mode = 1, level = 2, and encr_key_size = 0x10. This causes the bootloader to call into service_change_indicate() which calls sd_ble_gatts_sys_attr_set() and this fails with a NRF_ERROR_INVALID_DATA. The sys_serv_attr is all zeros since the application doesn't set this to any values but I don't see how to get it set correctly. If I just call sd_ble_gatts_sys_attr_set() with the 2nd param NULL then everything works fine.

What am I missing?

I have changed the way the application is sharing the peer_data is it is going through a dm flash area that is shared between the app and bootloader, but that seems to be working as it gets the whitelist etc data to the bootloader to allow pairing with my application but another device running nRF Master Control Panel sees the device but doesn't have a "Connect" option for that device. If I don't do the sharing of bonding info it does show the "Connect" option.

...Gary

BootloaderSecureConnectionForNordic.pcapng

[Hung Bui]

Hi Gary,

Well, the event BLE_GAP_EVT_CONN_SEC_UPDATE tells the bootloader that the link is encrypted. When the link is encrypted the bootloader will try to send the "Service changed" indication to tell the DFU master to do a service discovery to update the attribute table. This is needed because the attribute table changed from application to bootloader.

In this case I suspect that the system attribute (the value and handleid of the CCCD of service changed characteristic) has not been saved and passed to the bootloader. If you have a look in bootloader_start() function in dfu_app_handler.c file in the ble_app_hrs_s110_with_dfu example you can find that we read it out and then store it in m_peer_data.sys_serv_attr.

I guess it's not saved and passed to bootloader in your implementation where you use flash to pass the information?

Could you try to follow what we do there and let me know the result ?

If that didn't help could you share the sniffer trace you captured. A trace contains the pairing procedure with the application, then application switch to bootloader, then the issue, would be great. Also please let me know your SDK version and the DFU master you used. Also, do you have any issue when testing with our example ?

[Hung Bui]

Hi GaryG, You can edit the question to add your sniffer file in. It's still missing in your answer ( I converted it to comment but the file was missing at the beginning). By default the hrm profile won't require encryption/bonding so you would need to force a bonding (using nRFMaster Control Panel on Android or on PC). If you are testing with iOS, you may need to modify the application so that it requires bonding (change from BLE_GAP_CONN_SEC_MODE_SET_OPEN to BLE_GAP_CONN_SEC_MODE_SET_ENC_NO_MITM when init the service).

Your solution is totally fine, as it's mentioned here in our FAQ at question C. You simply need to restore the CCCD for service changed characteristic that allow the bootloader to send the service changed indication and restore the LTK to re-encrypt the link.

I'm just wondering if the DFU central actually set the CCCD for service changed to 1 or not (that's why I need the sniffer trace). I assume you are using iOS device as the Master ?