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]

Yes but I just need it again at a later stage. For that I need to disable and enable soft device. That's only going to happen once though. Can you please guide me on that instead?

[Vidar Berg]

Sure, but I need a bit more info to go on. Have you done any debugging of the app to see if it crashes, or if it successfully reaches the  ble_dfu_buttonless_bootloader_start_finalize() call where the program is reset into the bootloader?

[AliMahmood123]

Oh Yes Vidar

It does reach the ble_dfu_buttonless_bootloader_start_finalize() function and goes till the end until nrf_pwr_mgt_shutdown. After that I am just lost, the android app keeps trying to re- connect and ends up giving the same [DFU] disconnected by the remote device error.

[Vidar Berg]

Ok, assuming you use the nRF connect app, do you see the device advertising in DFU mode if you go back to the scanning view?

[AliMahmood123]

Also Vidar
If you don't mind I got another question, I could also post a separate thread but it would be very easy if you could answer it here.

Okay so we wanted some sort of encryption in the DFU image. If I choose bond forwarding buttonless example and same for DFU Mode, I will be doing BLE bonding right?
Once I achieve that, all BLE communication should be theoretically encrypted by the Link Layer Encryption from Security Manager if BLE bonding is implemented

Is that the case, then it would suffice us a bit, or is it not?

[Vidar Berg]

The image will still be unencrypted on the DFU controller side even if the link is encrypted. So I'm not sure bond sharing will help much if the goal is to prevent potential adversaries from gaining access to your FW image.

Bond sharing can be help prevent unauthenticated users from initiating a DFU update even though the have a valid update package.

[AliMahmood123]

Thanks for such abrupt responses. Yes the FW will still be un encrypted, but we are developing our own app and I think we could manage that, right now we are just looking into BLE stuff

Bond sharing can be help prevent unauthenticated users from initiating a DFU update even though the have a valid update package.

And yes this point is also true, benefits us

But even if the image is unencrypted on DFU controller / Central side, it will be transmitted using Link Layer transmission right?

[Vidar Berg]

Yes, the packet payload will become encrypted at the link layer, so data sent on air will be encrypted. It's not something I have investigated, but I suspect it would be trivial to find the FW image if it's stored in cleartext inside the mobile application image. It may also be possible to get it if the attacker logs the HCI commands traffic on their phone during a FW update. 

[AliMahmood123]

Thanks for that information. Btw the same goes for bootloader too? As the BL project is just 24KB. The BLE connection stays on when the connection shifts to DFUTarg, so I am assuming Link layer encryption is applicable there too?

[Vidar Berg]

Yes, the bootloader will use the same link encryption key when you have enabled bond sharing.