BLE_GAP_SEC_STATUS_TIMEOUT after connecting to iOS devices

[BjoernSchmitz]

Hello,

we have a system utilizing a nrf52840, running a S140 softdevice and nRF5 SDK v15.0.0. We are already on the market and currently do only support android. Till now, we never experienced any problems when connecting to android device. However, while developing an application for iOS, we experienced the problem that the iOS device is disconnected from our nrf52840, exactly 30 s after connecting. 

During our investigation we saw that we receive a BLE_GAP_EVT_AUTH_STATUS with auth_status set to BLE_GAP_SEC_STATUS_TIMEOUT. After that, we terminate the connection. This is the code:

        case BLE_GAP_EVT_AUTH_STATUS:
            
                //Print out event specific information
                NRF_LOG_INFO("BLE_GAP_EVT_AUTH_STATUS, status: %u, source: %u,  bonded: %u, lesc: %u", 
                        p_ble_evt->evt.gap_evt.params.auth_status.auth_status,
                        p_ble_evt->evt.gap_evt.params.auth_status.error_src,
                        p_ble_evt->evt.gap_evt.params.auth_status.bonded,
                        p_ble_evt->evt.gap_evt.params.auth_status.lesc);
                //disconnect if authentication failed
                if(p_ble_evt->evt.gap_evt.params.auth_status.auth_status != BLE_GAP_SEC_STATUS_SUCCESS ) {
                        ble_gatt_disconnect();
                        NRF_LOG_INFO("Pairing procedure failed");
                }
                break;

 

To specify this more in detail: We do not receive this when bonding a device. Everything works as expected during bonding itself. We only see this when connecting to an already bonded iOS device. Even then, we first get a BLE_GAP_EVT_AUTH_STATUS event that tells us authentication succeeded. However, most of the time we get the  BLE_GAP_SEC_STATUS_TIMEOUT 30 s after establishing a secured connection. However, the corresponding event tells us we are bonded.

When just skipping the ble_gatt_disconnect, everything works fine. Bonding works as expected and iOS devices stay connected. We could live with that workaround, but I would prefer to understand why we get that event. I assumed that we would also get a PM_EVT_CONN_SEC_FAILED event from the peer manager in that case. But we did not observe that.

We implemented a passkey entry pairing. Here are the security parameters:

#define SEC_PARAM_BOND                      1                                       /**< Perform bonding. */
#define SEC_PARAM_MITM                      1                                       /**< Man In The Middle protection not required. */
#define SEC_PARAM_LESC                      0                                       /**< LE Secure Connections enabled. */
#define SEC_PARAM_KEYPRESS                  0                                       /**< Keypress notifications not enabled. */
#define SEC_PARAM_IO_CAPABILITIES           BLE_GAP_IO_CAPS_DISPLAY_ONLY            /**< We say that there is a display even if there is none.*/
#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. */

 

One more thing, I read in similar threads that not allowing repairing could cause that issue. We already have that enabled, so this is probably not the source of the issue:

	case PM_EVT_CONN_SEC_CONFIG_REQ: {
		
		pm_conn_sec_config_reply(p_evt->conn_handle, &conn_sec_config);
        NRF_LOG_INFO("PM_EVT_CONN_SEC_CONFIG_REQ");
	}
		break;

Thank you and best regards

Björn

[Einar Thorsrud]

Hi Björn,

I assume this happens after a call to pm_conn_secure? If the procedure times out, you will get the BLE_GAP_SEC_STATUS_TIMEOUT event. See snippet from API doc:

 *          If the connection is a slave connection, the function sends a security request to
 *          the peer (master). It is up to the peer then to initiate pairing or encryption.
 *          If the peer ignores the request, a @ref BLE_GAP_EVT_AUTH_STATUS event occurs
 *          with the status @ref BLE_GAP_SEC_STATUS_TIMEOUT. Otherwise, the peer initiates
 *          security, in which case things happen as if the peer had initiated security itself.
 *          See @ref PM_EVT_CONN_SEC_START for information about peer-initiated security.

In that case, I suggest you simply do not call it. The central should secure the link if/when needed.

Einar

[BjoernSchmitz]

Hi Einar,

thank you for the quick response. Yes pm_conn_secure seems to actually cause the issue. It seems that, when connecting to a bonded iOS device, the central secures the connection automatically, and my one request to secure the connection times out. This does not seem to happen on Android. 

The thing is, I would really like to force the central to secure the connection, thus my current solution would be to call pm_conn_secure anyway, ignore the BLE_GAP_EVT_AUTH_STATUS event and use the PM_EVT_CONN_SEC_FAILED from the peer manager to trigger a disconnect. Do you see any problem with that? This seems to solve my problems since this event only occurs if securing the connection actually failed.

[Einar Thorsrud]

Hi,

There is no good way to force the iOS device to encrypt the link or not, it will do it as it sees fit (if allready bonded or needing to access a peripheral with higher security level than currently used). So I agree you continue to call pm_conn_secure() secure then, so that you get the desired behavior with Android. And then also handle BLE_GAP_SEC_STATUS_TIMEOUT specifically, simply by ignoring it like you write. It is not an error, but just means that the central decided to ignore the request, so that is OK.