Secure DFU, OTA failed scenario is not as expected

RE: Secure DFU, OTA failed scenario is not as expected

PouyaSe — Wed, 30 May 2018 11:12:01 GMT

Hi Einar

Ok, great. I wanted to make sure that I'm not doing anything wrong.

I will tell the Mobile Application developer guys to do the check before doing OTA in a first place. until we migrate the production code to SDK v14 at some point.

Thanks again.

Pouya

RE: Secure DFU, OTA failed scenario is not as expected

Einar Thorsrud — Wed, 30 May 2018 11:05:38 GMT

You are absolutely right. The only way to continue from this state is to upgrade with a valid DFU image. This behavior has been remedied by the introduction of a inactivity timer in SDK 14, which triggers a reset if there has been no activity for some time. This is essentially a application timer that is restarted every time there is activity, and calls NVIC_SystemReset() if it times out, so it should not be much work to port it to SDK 12.3 if you want it. A simpler alternative if you want to reset if prevalidation failed is to just call NVIC_SystemReset() after logging "Prevalidate FAILED".

RE: Secure DFU, OTA failed scenario is not as expected

PouyaSe — Wed, 30 May 2018 07:10:36 GMT

Hi Einar

Thanks for you response and time.

That is exactly What I have was expecting, but not seeing in action. I'm pretty much sure that I don't have DEBUG defined.

and if you take a look at the on_ctrl_pt_write() function, you would see the following code:

case BLE_DFU_OP_CODE_EXECUTE_OBJECT:
            NRF_LOG_INFO("Received execute object\r\n");

            // Set req type
            dfu_req.req_type     =  NRF_DFU_OBJECT_OP_EXECUTE;

            res_code = nrf_dfu_req_handler_on_req(NULL, &dfu_req, &dfu_res);
            return response_send(p_dfu, BLE_DFU_OP_CODE_EXECUTE_OBJECT, res_code);

nrf_dfu_handler_on_req will return a fail state as expected (the prevalidate failed), then it send the response the the mobile phone. when sending the response to the phone is successful, it would return success, noting else.

And, if you take a look at the on_ble_evt (inside nrf_ble_dfu.c), you would see the following code:

case BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST:
            if (p_ble_evt->evt.gatts_evt.params.authorize_request.type
                != BLE_GATTS_AUTHORIZE_TYPE_INVALID)
            {
                if (on_rw_authorize_req(&m_dfu, p_ble_evt))
                {
                    err_code = on_ctrl_pt_write(&m_dfu, 
                           &(p_ble_evt->evt.gatts_evt.params.authorize_request.request.write));
#ifdef NRF_DFU_DEBUG_VERSION  
                    if (err_code != NRF_SUCCESS)
                    {
                        NRF_LOG_ERROR("Could not handle on_ctrl_pt_write. err_code: 0x%04x\r\n", err_code);
                    }
#else
                    // Swallow result
                    (void) err_code;
#endif
                }
            }
            break;

the code I see, will swallow the return code of on_ctrl_pt_write().

So, Am i tracking the issue in a wrong place?

RE: Secure DFU, OTA failed scenario is not as expected

Einar Thorsrud — Tue, 29 May 2018 12:29:40 GMT

Hi,

The most likely reason for this is that you have DEBUG defined in your project.

I expect that NRF_ERROR_INVALID_STATE is returned from the call to on_ctrl_pt_write() in this case, which should be caught by the APP_ERROR_CHECK(). The app_error_handler_bare() or app_error_handler() which calls app_error_fault_handler() behaves differently if DEBUG is defined or not. The state of the system will be preserved without a reset to ease debugging in case DEBUG is defined. However, NVIC_SystemReset() is called if DEBUG is not defined.