Reject non-LESC pairing (not allowing Legacy pairing)

RE: Reject non-LESC pairing (not allowing Legacy pairing)

Nathan O. — Wed, 27 May 2020 07:26:47 GMT

Thanks, I no longer have an error.

I am still wondering though why I am getting SEC_PARAMS_REQ event with lesc flag at 0 on connections after the first one (to a bonded device). Can you explain this ?

RE: Reject non-LESC pairing (not allowing Legacy pairing)

Turbo J — Tue, 26 May 2020 16:59:05 GMT

You are not supposed to call sd_ble_gap_sec_params_reply directly - use pm_conn_sec_params_reply instead.

The PM events all supply a conn_handle in the event argument

And yes, dependig on how handlers priorities are set up, you might get the PM event before the BLE_GAP_EVT_CONNECTED was delivered to your applications event handler.

RE: Reject non-LESC pairing (not allowing Legacy pairing)

Nathan O. — Tue, 26 May 2020 15:32:01 GMT

Thanks.

I have implemented this change and it first seemed to work.

Unfortunately, it seems that I still have an issue :

When I connect to my device with a smartphone that supports LESC, the connection is established correctly. If I disconnect and try reconnecting again, I get into an error because PM_EVT_CONN_SEC_PARAMS_REQ seems to happen before BLE_GAP_EVT_CONNECTED, so I end up calling sd_ble_gap_sec_params_reply with a conn_handle of 0xFFFF.

Is it normal to get PM_EVT before GAP_EVT_CONNECTED ?

RE: Reject non-LESC pairing (not allowing Legacy pairing)

Turbo J — Fri, 22 May 2020 07:49:08 GMT

The BLE_GAP_EVT_SEC_PARAMS_REQUEST is handled by the peer manager, which probably has already called sd_ble_gap_sec_params_reply() function.

Try the PM_EVT_CONN_SEC_PARAMS_REQ event in the peer manager event handler function - using pm_conn_sec_params_reply() with a NULL p_sec_params pointer (that rejects security procedure).