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 Gary,

The sniffer couldn't tell much because it couldn't decrypt the connection . You will see it's full of "Encrypted packet decrypted incorrectly" packet. To let the sniffer decrypt the connection, you would need to capture also the bonding procedure, where the keys are distributed then the sniffer can use that keys to decrypt the connection when you re-bond (in one shot, don't stop the sniffer)

Could you clarify, that you are using the nRF51422 running serialization and act as a DFU master where you update another nRF51 board ? This mean you writing your own DFU master software on PC ?

I would suggest you test first using our Master Control Panel software on PC to test the bootloader on the DFU target board first. A question, if you don't do bonding (just DFU with no encryption) would the DFU works ?