Looking To Advertise but Keep DFU Service Disabled

[Anders]

Hello,

I'm working on an nRF52832 with SoftDevice v6.1.0 and SDK 15.3.0. We have made a custom application that was created from the ble_app_uart example project. We've also added the buttonless DFU (with bonding) capability to the project. I'm hoping to get some guidance on tweaking our device's behavior a little further.

We would like the device to continue advertising the buttonless DFU service to any clients that are looking for BLE devices to connect to, but we don't want the DFU service to do anything until the client connected to our device has completed our own authentication process. I was wondering what the best way would be to make our device do nothing, but stay connected, if a connected client tries to write to the DFU service. If that is possible, is there an optimal location to do this? We're thinking that it might result in some slight changes to some SDK files. Any guidance would be appreciated.

Right now our plan is to use a global flag to track whether the connected client is authenticated, and to check that flag before proceeding if the client tries to initiate a DFU. 

Thank you!

Anders

[Einar Thorsrud]

Hi,

There is no support for this in the buttonless DFU service, but it should not be difficult to add. I suggest you check your flag in the handling of the DFU_OP_ENTER_BOOTLOADER event in ble_dfu_buttonless_on_ctrl_pt_write() in \ble_dfu_bonded.c or ble_dfu_unbonded (depending on which you use). There you could ignore commands to enter DFU mode if the peer is not authenticated.

[Anders]

Hi Einar,

Thank you for the response, that makes sense. I'd been looking around ble_dfu_bonded.c already and saw that event. From what I've read that event gets generated when a mobile client writes 0x01 to the DFU service, correct?

I'm also curious if it would be better to send an RSP code back to the connected client when we ignore the control point write? We were considering sending back DFU_RSP_OPERATION_FAILED. Our accompanying mobile app has also made use of the DFU library. Does it matter if we send back an RSP code or not?

[Einar Thorsrud]

Hi,

Anders said:

From what I've read that event gets generated when a mobile client writes 0x01 to the DFU service, correct?

Yes.

Anders said:

I'm also curious if it would be better to send an RSP code back to the connected client when we ignore the control point write? We were considering sending back DFU_RSP_OPERATION_FAILED. Our accompanying mobile app has also made use of the DFU library. Does it matter if we send back an RSP code or not?

It would probably be cleaner to make a new RSP code for this, something like DFU_RSP_OPERATION_NOT_ALLOWED, and add support for that in the DFU library on the mobile phone side as well. In any case, it is not implemented by us, so the details are up to you an how you prefer to do it.