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,

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

[David Duan]

HI Terje

1.  sd_ble_gap_auth_key_reply returns NRF_SUCCESS without any error messages, until the pairing response times out.

2.I have attached the Ellisys packet capture log above, and there is no DHKey Check packet.

BR

[tesc]

Hi,

We can conclude then, that the reason for the missing SMP Pairing Failed packet from the peripheral, is the missing DHKey Check packet from the central. From what we can tell, this implementation of the peripheral is allowed by the Bluetooth Specification.

The behavior seems to have changed for the SoftDevice Controller of nRF Connect SDK, which in turn has led to better interoperability with central devices not sending DHKey Check packets. The change will not be backported to the SoftDevices of nRF5 SDK. This means when they see this issue, the workaround is to close the pairing dialog manually at the central end or wait for a central side timeout.

Regards,
Terje

[David Duan]

Thank you so much for the detailed explanation.