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 ?

[GaryG]

When I call sd_ble_gatts_sys_attr_get() from my application I get NRF_ERROR_NOT_FOUND returned. I am running with s110 8.0.0. I'm running with SDK version 8 components but this call is into the softDevice so the SDK version shouldn't matter, right?

This is the same value returned if called during a connection or after the disconnect.

When I change the bootloader so it calls sd_ble_gatts_sys_attr_set() with a null as the 2nd parameter and not with the attribute I don't have the bootloader works as far as I can connect to it from my central app and do the reflash. Given the application is using flash to communicate the application calls the reset vector address (0x00000004) to restart the system and doesn't just call the bootloader address. This means the softdevice is restarted so maybe the attribute table reset isn't needed? Just trying to figure out why it works to understand if this is a valid solution.

...Gary

[Hung Bui]

Hi Gary,

How did you test your app ? Make sure you have written to the Service Changed CCCD to enable indication. If you call sd_ble_gatts_sys_attr_set() with null, the CCCD for service changed will not be set and the bootloader won't send the indication => DFU master wont update the table.

Again, please provide us your sniffer trace, and please try a test with the ble_app_hrs_with_dfu

[GaryG]

Adding answer as I don't see how to attach WireShark log file in a comment.

This is a wireshark log file for the connection to my bootloader named "secure bootloader". Since the application jumps to address 0x4 to start the bootloader anything about the applications services etc will not still be around as the SoftDevice has been restarted. This is different from the Nordic solution of jumping to the bootloader start address for the restart.

I'm not sure how to get the Nordic solution going as I need an PC or Android application, a bootloader, and the Nordic device application. I got the Nordic device application to build in IAR, does the nRF Toolbox on Android support secure connection? That means the nRF Toolbox would be required to make a secure connection to the HRM, right?

...Gary

[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 ?

[GaryG]

Sorry, not sure how attachment got lost. I have added the attachment of the wireshark log to the original message. The central is another nRF51422 eval board for this tested with a PC over serial controlling it and it will be an nRF51 chip long term as well. ...Gary