Android Device Fails to Reconnect after Firmware Update with Preserved APP data

[yaoCheng]

Hello,

I am currently working on a product with nRF51822 chip, based on SDK10.0.0. The problem is, after a firmware update, my device fails to reconnect to an Android mobile, even though the bonding information is preserved.

The bootloader is the same as the DFU example provided in the SDK with some adaptations for HW. It preserves application data (bonding information for BLE mainly). Before the firmware update begins, my device is bonded with an Android mobile and they can communicate with each other.

However, after a firmware update, when I try to reconnect to the Android mobile, it always sends me a pairing request, as if it did not know my device. After this pairing procedure, they still fail to communicate with each other. Only after deleting the bonding information on my device can they pair with each other correctly again and start to communicate.

I am sure that the bonding data are correctly preserved on my device, because an IOS mobile can reconnect successfully after firmware update. As far as I know, the APP on Android mobile does not delete bonding information either.

So I would like to ask, it there any behaviour in the updating process that might lead an Android mobile to believe that the updated device is a new device?

[bjorn-spockeli]

Hi Yao, 

could you capture a on-air trace of the communication between the nRF51822 and the Android device using our nRF Sniffer plugin in Wireshark and a NRF52 or NRF51 DK?

Which SoftDevice are you using on the nRF51422?

Do you receive the BLE_GAP_EVT_SEC_INFO_REQUEST event when you try to re-connect after the DFU, see the Peripheral Encryption Establishment using stored keys Message sequence chart? If so, then please debug the application and see what arguments the application is passing to sd_ble_gap_sec_info_reply() in device_manager_peripheral.c

Best regards

Bjørn

[yaoCheng]

Hi Bjørn,

thanks for your reply.

I am using S110, v8.0.0.

The communication between my board and the Android mobile is captured by nRF sniffer, filtered by packet length non-zero (please refer to the following file):

reconnect_with_android_after_fw_update.pcapng

 After the FW update, when I try to reconnect to the Android mobile, I do receive the BLE_GAP_EVT_SEC_INFO_REQUEST event. The arguments passed to sd_ble_gap_sec_info_reply() are listed below:

conn_handle: 0x0000

*p_enc_info:

*p_id_info:

*p_sign_info: NULL

best regards,

Yao

 

[bjorn-spockeli]

Hi Yao, 

the sniffer trace confirms that its the Master, i.e. Android device that issues the Pairing request ( Packet No 1245) to which the Slave, i.e. the nRF51422, responds with a Pairing response. Then the Pairing confirm and pairing random values are exchanged and the encryption process is started. 

The Device Manager allows the bond information to be refreshed so this is why it accepts the Pairing request.

I do not have any explanation for why the Android sends a the Pairing Request, but you could modify the DM source to reject a pairing request if you are already bonded and see if the Android device then tries to re-encrypt the link with the stored keys. You can do this by modifying the case BLE_GAP_EVT_SEC_PARAMS_REQUEST in dm_ble_evt_handler() in device_manager_peripheral.c to call sd_ble_gap_sec_params_reply() with sec_status== BLE_GAP_SEC_STATUS_UNSPECIFIED 

Does the nRF51 device have the same Link Layer address, i.e. fb:9e:df:ab:fe:6f, before and after the DFU?

Best regards

Bjørn

[yaoCheng]

Hi Bjørn,

the address shown by nRF sniffer is the same before and after firmware update.

I also tried to change the input argument of sec_status to BLE_GAP_SEC_STATUS_UNSPECIFIED, but my device and the Android mobile still fail to communicate with each other after firmware update.

Here is the communication captured by nRF sniffer (pairing request from already bonded device rejected),

fw_update_then_reject_bond_info_refresh.pcapng

which shows the process of bonding, firmware update and then the failed trial to reconnect.

I think the request of pairing is rejected as you said (nRF sniffer No. 9688) . But I do not know why they still can not communicate with each other.

Yet I find something that looks strange to me without the modification mentioned above. Here is the communication captured by nRF sniffer (pairing request from already bonded device accepted):

fw_update_then_accept_bond_info_refresh.pcapng

After the firmware update and the new pairing process, the master keeps on sending the packet LL_START_ENC_RSP(from nRF sniffer No 9982). Does this mean that there is something wrong with the APP?

best regards,

Yao