BLE_GAP_SEC_STATUS_TIMEOUT after connecting to iOS devices

RE: BLE_GAP_SEC_STATUS_TIMEOUT after connecting to iOS devices

Einar Thorsrud — Fri, 24 Sep 2021 10:17:57 GMT

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.

RE: BLE_GAP_SEC_STATUS_TIMEOUT after connecting to iOS devices

BjoernSchmitz — Thu, 23 Sep 2021 14:47:41 GMT

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.

RE: BLE_GAP_SEC_STATUS_TIMEOUT after connecting to iOS devices

Einar Thorsrud — Thu, 23 Sep 2021 12:29:34 GMT

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