Soft device enable and disable - [DFU] disconnected by the remote device

[AliMahmood123]

Hello all

I am facing a very strange issue, already searched the forum but didnt find anything like it.

Okay so I can get DFU to work. For our custom application we have to disable the soft device for some time for sensor acquisitions and re enable it at a later time for OTA upgrades.

I simply use nrf_sdh_disable_request() to de initialize the soft device successfully, which it does.

I later re - enable soft device using the standard ble calls in example code:

ble_stack_init();
    peer_manager_init();
    gap_params_init();
    gatt_init();
    advertising_init();
    services_init_2();
    conn_params_init();   
     
    //Start execution.
    application_timers_start();
    advertising_start(erase_bonds);

BLE gets initialized successfully, device is advertised and connects to as well. The problem is in DFU. When I attempt DFU, it keeps getting stuck into trying to switch to bootloader, repeatedly giving
"[DFU] disconnected by the remote device"

The logs then try to open the firmware file again, re initiating the process but nothing happen. I have spend quite some time on this and hit a blocker. Any help is appreciated. There must be a step I am missing during re-enabling the soft device

[Vidar Berg]

Hello,

"[DFU] disconnected by the remote device"

Where is this message printed? Is it in the mobile app on iOS or Android? And have you tried to debug the FW app to see if it hangs or enters the app_error_fault_handler() function?

Okay so I can get DFU to work. For our custom application we have to disable the soft device for some time for sensor acquisitions and re enable it at a later time for OTA upgrades.

Sure you really need to disable the Softdevice for this? The only case I can think of where it makes sense to disable the Softdevice is when there is a need to stop the LF clock. 

Best regards,

Vidar

[AliMahmood123]

Hi Vidar.
I read an article here which said that in order to disable a service and re-enable it later, I need to disable the whole soft device as the services at start up become part of the "stack"

if there is another way, please let me know. Basically I just want to disable the DFU service and show that service at some other point

Also, this message appeared on the android app

[AliMahmood123]

Hmm and if bond sharing is not enabled then? I am a bit confused about this. Without bonds the connection still stays when switched to bootloader. I hope I can encrypt the link layer without bonding right?


Also, Logically, BLE protocol offers Link layer encryption (Security level 4) without bonding, it is not required.

on nRF Platform using soft device, is it necessary to "bond" to use link layer encryption for BLE communication, DFU or not?

[Vidar Berg]

There is always a re-connect taking place when you switch to bootloader DFU mode, the difference when bond sharing is enabled is that the connection will be secured with the encryption key provided by the app.

Buttonless Secure DFU Service with bonds vs. Buttonless Secure DFU Service without bonds.

You could modify the bootloader to support pairing and get link encryption that way. The problem then is how you are going to prevent other centrals from pairing with your bootloader.

[AliMahmood123]

Hi Vidar
Okay So I have managed to do pairing, not bonding from buttonless app, I protected the DFU write characteristic with Just Works

Now how should I ensure this when going into DFU Mode?

[AliMahmood123]

Wont the link be encrypted when it goes into DFU Mode as well, as the peer is forwarded?

[AliMahmood123]

Hi
I've made some progress and now I can ask some to the point questions. I would be very grateful if you can read all and provide me with detailed answer.
I have referred to https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.s132.api.v7.2.0%2Fgroup___b_l_e___g_a_p___p_e_r_i_p_h___s_e_c___m_s_c.html&cp=4_7_3_1_2_1_5_10 for the logs that I see.

So I have two situations
1) Bond forwarding - I have managed to encrypt the link and do bond forwarding as well. I did that by adding LESC crypto libraries separately. I got BLE_GAP_EVT_LESC_DHKEY_REQUEST and the whole flowchart as expected. I am still a bit confused as to how the default example (bond forwarding) could be encrypted without adding LESC and crypto support. That's just my curiosity.

Anyways for the above situation, the LTK is generated and it's being used in DFU. My question here is that when the device goes into DFU Mode, is the session still encrypted?

Another question here is regarding bond deletion, I get really weird behaviour when I delete bonds, it wasnt working with simply deleting from app in this case 1). I had to delete bonds from peer as well. I have still more testing to do but since we have a few days gap in replies that's why I prefer to ask everything up front

2) Without bond forwarding - Only LESC - I disabled bond forwarding and bonding and just did pairing (No BLE pairing phase 3 of key exchange which is bonding). I also added CONN_JUST_WORKS on DFU characteristics.
DFU works fine.
My question here also is that when the device goes into DFU Mode, is the session still encrypted?

Another question here is that when I do DFU with LESC and no bond forwarding, the device says "Bonded". That doesn't make any sense. I think this is a bug as I have not bonded in the first place. So on the upgraded firmware I simply forget the bonds and use the updated application. I dont have much problem with this but I just dont get the concept. I realize its due to adding just works on DFU characteristic. But I clearly "Pairing" logs as the role from peer manager. Then why does it say bonded?

Please answer me clear cut on this so I can compare the above two situations to what I want
And please answer all questions for easiness for you and me both. Thanks a lot in advance for hearing me out

[Vidar Berg]

Hi,

AliMahmood123 said:

1) Bond forwarding - I have managed to encrypt the link and do bond forwarding as well. I did that by adding LESC crypto libraries separately. I got BLE_GAP_EVT_LESC_DHKEY_REQUEST and the whole flowchart as expected. I am still a bit confused as to how the default example (bond forwarding) could be encrypted without adding LESC and crypto support. That's just my curiosity.

The crypto libraries are only needed for the DH key exchange that takes place during the bonding procedure. Link encryption is done with the built-in AES HW block after the app has provided the softdevice with the LTK, and has no additional SW dependencies.

AliMahmood123 said:

My question here is that when the device goes into DFU Mode, is the session still encrypted?

The device is reset when you enter DFU mode, so the central has to re-connect, and then encrypt the link again with the LTK (Encryption Establishment using stored keys).

AliMahmood123 said:

s regarding bond deletion, I get really weird behaviour when I delete bonds, it wasnt working with simply deleting from app in this case 1).

Please see this post: https://devzone.nordicsemi.com/f/nordic-q-a/51965/pairing-and-bonding-after-deleting-synchronization

AliMahmood123 said:

I disabled bond forwarding and bonding and just did pairing (No BLE pairing phase 3 of key exchange which is bonding).

I understand why you disable bond forwarding, but not why you're disabling bonding. Note that you don't need bond forwarding to support bonding in the main app.

AliMahmood123 said:

My question here also is that when the device goes into DFU Mode, is the session still encrypted?

No. The current session will be terminated when you enter dfu mode.

AliMahmood123 said:

Then why does it say bonded?

Seems like it may be a bug in android's BT stack: https://devzone.nordicsemi.com/f/nordic-q-a/43338/android-pairing-without-bonding---nrf-connect/. My impression is that very few use pairing, so that may explain why it has not been addressed, assuming it is indeed a bug.

[AliMahmood123]

Hi. Thanks for the response

The device is reset when you enter DFU mode, so the central has to re-connect, and then encrypt the link again with the LTK

No. The current session will be terminated when you enter dfu mode.

Okay regarding this, I have removed the disconnect functionality from BLE_DFU_EVT_BOOTLOADER_ENTER_PREPARE event and the DFU still works. The connection seems to be maintained, so is the link encrypted in DFU mode or not? If the answer is yes here then I will be very relieved. I don't see a disconnection or an NRF log event fire up saying disconnection

Note that you don't need bond forwarding to support bonding in the main app.

Okay so I can just set SEC_PARAM_BOND to 1 and not set DFU bond forwarding flags in sdk_config.h? Can I do that?

My impression is that very few use pairing, so that may explain why it has not been addressed, assuming it is indeed a bug.

Okay so I dont mind using bonding, but I am having problems for link encryption.

When you speak of:

The crypto libraries are only needed for the DH key exchange that takes place during the bonding procedure. Link encryption is done with the built-in AES HW block after the app has provided the softdevice with the LTK, and has no additional SW dependencies.

Do you mean that even if I dont include crypto libraries, and especially if I don't see BLE_GAP_EVT_LESC_DHKEY_REQUEST exchange, the link layer is encrypted? i.e, By just enabling bond forwarding conventional example. the layer is encrypted? I dont think so, what do you think?

Dont I need to enable LESC associated flags in SDK and peer manager?

If the answer is yes, when I do that (enable LESC, add crypto AND enable bonding and bond forwarding), the solution doesn't work 100%. There are a few bonding problems here and there. I will post them next

[Vidar Berg]

Hi,

AliMahmood123 said:

Okay regarding this, I have removed the disconnect functionality from BLE_DFU_EVT_BOOTLOADER_ENTER_PREPARE event and the DFU still works. The connection seems to be maintained, so is the link encrypted in DFU mode or not?

The transition from app to bootloader is transparent seen from the user. You have to view the debug logs in nRF connect to see that the connection gets terminated after ble_dfu_buttonless_bootloader_start_finalize() call in your main app, and re-established once the bootloader starts advertising again on the following boot.

ble_dfu_buttonless_bootloader_start_finalize() will perform a system reset and cause the device to boot into the bootloader, which will then enter DFU mode and start connectable advertising.

AliMahmood123 said:

Okay so I can just set SEC_PARAM_BOND to 1 and not set DFU bond forwarding flags in sdk_config.h? Can I do that?

Yes you can. Users still have to be bonded to initiate buttonless DFU as long as you have increased the sec. level of the buttonless characteristic.

AliMahmood123 said:

Do you mean that even if I dont include crypto libraries, and especially if I don't see BLE_GAP_EVT_LESC_DHKEY_REQUEST exchange, the link layer is encrypted? i.e, By just enabling bond forwarding conventional example. the layer is encrypted? I dont think so, what do you think?

No, what I meant to say is that these crypto libraries are only used for the bonding procedure where the encryption key is exchanged. So you do need these libraries to support LESC bonding in the app. But the pairing method does not affect the security of the bootloader (not directly at least), it simply uses the app provided encryption key to secure the link.

AliMahmood123 said:

Dont I need to enable LESC associated flags in SDK and peer manager?

Yes, if you want LESC bonding, and not legacy bonding.

[AliMahmood123]

Hmm
So bottomline is that the session is not encrypted when I go into DFU Mode if I just pair from base firmware? RIght?

Having said that, I managed to implement Bonding + LESC but its quite buggy I have to say, Sometimes there is GATT Error and what not, I'll update this post soon
Also, with this implementation DFU only works in the second, third or even fourth try sometimes. It does upload, but after 50,60,70 % it just resets the device being unable to DFU. What could be the issue?

Btw

Yes you can. Users still have to be bonded to initiate buttonless DFU as long as you have increased the sec. level of the buttonless characteristic.

This doesnt work, it was giving me error on ble_dfu_buttonless_async_svci_init(). I did secure the characteristic. Now I was assuming this occurred as the Bootloader supported bonds, but the application did not. Hence, I didnt move forward with it. What could be the issue?

I just want my DFU to be encrypted btw, thats the ultimate goal.

[AliMahmood123]

ble_dfu_buttonless_bootloader_start_finalize() will perform a system reset and cause the device to boot into the bootloader, which will then enter DFU mode and start connectable advertising.

Yes I know. I dont know much about connectable advertising though so please fill me in? The device auto connects and starts DFU instantly, but the key is lost in pairing mode then? The temporary key generated when the main app was running, it's gone then? That's why I need to bond and use the LTK?