This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

sd_ble_gap_sec_params_reply() returns NRF_ERROR_INVALID_STATE

I have an nRF51822 application using the Soft Device 110. I want to perform bonding with a central without MITM protection. In my on_ble_evt() event handler, when the event ID is BLE_GAP_EVT_SEC_PARAMS_REQUEST, I reply in the same fashion as one of the example apps, like this:

        err_code = sd_ble_gap_sec_params_reply(m_conn_handle,
                                               BLE_GAP_SEC_STATUS_SUCCESS,
                                               &m_sec_params);
        APP_ERROR_CHECK(err_code);

The error_code is then 8, which is NRF_ERROR_INVALID_STATE.

The m_sec_params have earlier been set to these values:

#define SEC_PARAM_TIMEOUT                 30                                                /**< Timeout for Pairing Request or Security Request (in seconds). */
#define SEC_PARAM_BOND                    1                                                 /**< Perform bonding. */
#define SEC_PARAM_MITM                    0                                                 /**< Man In The Middle protection NOT required. */
#define SEC_PARAM_IO_CAPABILITIES         BLE_GAP_IO_CAPS_NONE                              /**< No I/O capabilities. */
#define SEC_PARAM_OOB                     0                                                 /**< Out Of Band data not available. */
#define SEC_PARAM_MIN_KEY_SIZE            7                                                 /**< Minimum encryption key size. */
#define SEC_PARAM_MAX_KEY_SIZE            16                                                /**< Maximum encryption key size. */

m_conn_handle has been set earlier on, when the BLE_GAP_EVT_CONNECTED event comes into the same handler, like this:

        m_conn_handle = p_ble_evt->evt.gap_evt.conn_handle;

I also know the connection event has happened, from my logs:

sd_app_evt_wait()
sd_app_evt_wait()
DM_EVT_CONNECTION
BLE_GAP_EVT_CONNECTED
sd_app_evt_wait()
DM_EVT_SECURITY_SETUP
BLE_GAP_EVT_SEC_PARAMS_REQUEST

How can I tell what's invalid about the state I'm in? The central is an Android app and is my code.

Parents
  • Hi Eliot,

    It would help if you had a sniffer trace of the transaction.

    What could be the reason is that there is a disconnection event that arrived right after you received the BLE_GAP_EVT_SEC_PARAMS_REQUEST, thus a pending disconnection event in the buffer. This could cause the NRF_ERROR_INVALID_STATE that you are receiving.

    Hope this helps

    [Update 1]

    After looking at the btsnoop log you provided I notice that the pairing procedure have actually started. (In frame 95, and continued until the start of exchanging keys in frame 128) At this point there are 6 packets that have not been exchanged. The EDIV and Rand from the slave, the IRK and Identity Address Information from both slave and master plus the CSRK from the master.

    This tells me that you have successfully replied to at least one BLE_GAP_EVT_SEC_PARAMS_REQUEST, but must have called sd_ble_gap_sec_params_resp one more time. thus it is out of state at that point. I'm not sure why it stops the procedure at that point. But it could be that you have asserted in the event handler, and the chip is only able to keep the link alive. Could you try to add a counter to where you call the sd_ble_gap_sec_params_reply and see how many times you call it?

    The reason you don't have the problem when disabling authentication on the characteristic is that the pairing procedure is never started.

    BR Pål

Reply
  • Hi Eliot,

    It would help if you had a sniffer trace of the transaction.

    What could be the reason is that there is a disconnection event that arrived right after you received the BLE_GAP_EVT_SEC_PARAMS_REQUEST, thus a pending disconnection event in the buffer. This could cause the NRF_ERROR_INVALID_STATE that you are receiving.

    Hope this helps

    [Update 1]

    After looking at the btsnoop log you provided I notice that the pairing procedure have actually started. (In frame 95, and continued until the start of exchanging keys in frame 128) At this point there are 6 packets that have not been exchanged. The EDIV and Rand from the slave, the IRK and Identity Address Information from both slave and master plus the CSRK from the master.

    This tells me that you have successfully replied to at least one BLE_GAP_EVT_SEC_PARAMS_REQUEST, but must have called sd_ble_gap_sec_params_resp one more time. thus it is out of state at that point. I'm not sure why it stops the procedure at that point. But it could be that you have asserted in the event handler, and the chip is only able to keep the link alive. Could you try to add a counter to where you call the sd_ble_gap_sec_params_reply and see how many times you call it?

    The reason you don't have the problem when disabling authentication on the characteristic is that the pairing procedure is never started.

    BR Pål

Children
Related