nRF5 SDK 17.1.0: Numeric Comparison pairing dialog on phone fails to dismiss after peripheral rejects pairing

[David Duan]

Hi DevZone,

My customer is using nRF5 SDK v17.1.0 with LESC Numeric Comparison pairing. They have encountered an issue during the pairing process: when the central (phone) initiates pairing, the

peripheral correctly displays the passkey. However, if the pairing request is rejected on the peripheral side, the pairing dialog box on the central side does not disappear. According to the

customer, BLE chips from other vendors do not exhibit this behavior.

I replicated and tested this issue using a standard nRF5 SDK v17.1.0 example on an nRF52832 DK.

The results confirmed that when the peripheral rejects the pairing, the pairing dialog box on the phone remains visible. Interestingly, when I ran the same test using NCS 3.4, the pairing dialog dismissed normally as expected.

After further investigation, I noticed that in NCS, if the peripheral rejects the pairing, it explicitly sends an SMP Pairing Failed packet. However, in the nRF5 SDK, even though the corresponding code logic triggers key_type = BLE_GAP_AUTH_KEY_TYPE_NONE, the device does not actually send the SMP Pairing Failed (Reason: 0x04 - Confirm Value Failed) command.

static ret_code_t num_comp_reply(uint16_t conn_handle, bool accept)
{
    uint8_t    key_type;
    ret_code_t err_code;

    if (accept)
    {
        NRF_LOG_INFO("Numeric match confirmed. Conn handle: %d", conn_handle);
        key_type = BLE_GAP_AUTH_KEY_TYPE_PASSKEY;
    }
    else
    {
        NRF_LOG_INFO("Numeric match rejected. Conn handle: %d", conn_handle);
        key_type = BLE_GAP_AUTH_KEY_TYPE_NONE;

        // Must be set before the reply: replying with BLE_GAP_AUTH_KEY_TYPE_NONE makes the
        // SoftDevice send an SMP Pairing Failed PDU (Numeric Comparison Failed) and raise
        // BLE_GAP_EVT_AUTH_STATUS, which in turn produces PM_EVT_CONN_SEC_FAILED.
        m_num_comp_rejected_locally = true;
    }

    err_code = sd_ble_gap_auth_key_reply(conn_handle, key_type, NULL);

    // Do NOT use APP_ERROR_CHECK() here: a failure must stay visible instead of
    // resetting the chip, because on an error nothing is transmitted and the SMP
    // request is still pending.
    if (err_code == NRF_SUCCESS)
    {
        NRF_LOG_INFO("sd_ble_gap_auth_key_reply(key_type=%d) OK", key_type);
    }
    else
    {
        m_num_comp_rejected_locally = false;
        NRF_LOG_ERROR("sd_ble_gap_auth_key_reply(key_type=%d) failed: 0x%x (%s)",
                      key_type, err_code, nrf_log_push((char *)nrf_strerror_get(err_code)));
        NRF_LOG_ERROR("Nothing was sent on air; the SMP request is still pending.");
        printf("\r\nauth_key_reply failed: 0x%lx\r\n", (unsigned long)err_code);
    }

    return err_code;
}

NCS 3.4 Test Result: When the peripheral rejects the pairing request, the pairing dialog box on the phone disappears normally.

nRF5 SDK 17.10 Test Result: When the peripheral rejects the pairing request, the pairing dialog box on the phone fails to disappear.

The test project for NRF5 SDK(nrf5sdk 17.10,SEGGER Embedded Studio for ARM v5.68)

ble_app_uart_tst.7z

The test project on NCS3.4.0 

peripheral_lesc.7z

Question:
I would like to confirm whether the nRF5 SDK SoftDevice itself inherently does not support sending this SMP Pairing Failed command in this scenario?

[tesc]

Hi,

Question:
I would like to confirm whether the nRF5 SDK SoftDevice itself inherently does not support sending this SMP Pairing Failed command in this scenario?

The SoftDevice should send the SMP Pairing failed command. The code that you shared looks correct. Setting key_type = BLE_GAP_AUTH_KEY_TYPE_NONE and sending that value in sd_ble_gap_auth_key_reply() should lead to the SoftDevice sending SMP Pairing failed, as per the Bonding: Numeric Comparison Message Sequence Chart.

I see from the logs that the error code returned by the SoftDevice from the call to sd_ble_gap_auth_key_reply() is NRF_SUCCESS, so if there is no SMP Pairing failed command sent then this looks like an issue with the SoftDevice. However I do not find any similar prior reports, and nRF5 SDK is several years old at this point. Are you able to confirm there is indeed no SMP Pairing failed command sent, by using a sniffer (such as for instance the nRF Sniffer)?

Regards,
Terje

[David Duan]

HI  Tesc 

my result is same customer,we both use ellisys to capture the data, we can't see the sd_ble_gap_auth_key_reply()

below it is my snifer result.

ellisys sniffer result:

sniffer_result.btt

if you use my project with NRF52 DK, this can be easy to reproduce by any smart phone with nrf connect.

BR

[David Duan]

HI Tesc 

any update on this 

BR

[tesc]

Hi,

We have investigated the issue, but here we see the peripheral sends a Pairing Failed (0x05) with reason Numeric Comparison Failed (0x0c), in response to a Pairing DHKey Check sent from the central. That Pairing DHKey Check is missing from the MSC, but that packet is essentially what the peripheral responds to. From what we can tell, this way of handing it is allowed by the Bluetooth specification.

Therefore:
1. Can we confirm the return value from sd_ble_gap_auth_key_reply(BLE_GAP_AUTH_KEY_TYPE_NONE, NULL)? (Should be NRF_SUCCESS. If something else, that error code would be important for figuring out what happens.)
2. When we see the issue (dialogue on central does not go away), does the central send a Pairing DHKey Check packet?

Regards,
Terje