MAC Address Incrementation Pairing issue

RE: MAC Address Incrementation Pairing issue

Vidar Berg — Tue, 27 Jul 2021 09:34:45 GMT

Thanks for the update. I'm glad to hear that it worked! The main purpose of the IRK is to enable address resolving of 'private resolvable' type BLE addresses, but it can also be used as an unique device identifier like in this case.

Note that the SDK examples all use a non-resolvable random static address by default, so the IRK isn't needed for address resolving anyway.

Now knowing that the IRK was the culprit, I think you could have also have solved this by not exchanging the IRK during the bonding procedure. This is achieved by clearing the following bit in pm_init():

RE: MAC Address Incrementation Pairing issue

Roiger — Tue, 27 Jul 2021 09:13:10 GMT

Works like a charm!!!! Thanks Vidar!! Well worth the wait :)

Just out of interest - what exactly is the irk?

RE: MAC Address Incrementation Pairing issue

Vidar Berg — Tue, 27 Jul 2021 08:16:27 GMT

Hello,

Sorry for the delayed response. Have you had any progress on this issue in the meantime? The reason for the BLE_GAP_SEC_STATUS_UNSPECIFIED error seems to be related to the fact that the peripheral keeps re-using the same IRK (identity resolving key - is exchanged during bonding procedure). Updating the IRK along with the BLE address does the trick.

Modified main() in ble_app_hid_keyboard to generate new random BLE address and IRK on startup:

/**@brief Function for application main entry.
 */
int main(void)
{
    bool erase_bonds;
    uint32_t err_code;

    // Initialize.
    log_init();
    timers_init();
    buttons_leds_init(&erase_bonds);
    // Delete bonds on startup
    erase_bonds = 1;
    power_management_init();
    ble_stack_init();
    scheduler_init();
    gap_params_init();

    uint8_t random_bytes[16];
    ble_gap_addr_t addr;
    uint8_t capacity;

    do
    {
        err_code = sd_rand_application_bytes_available_get(&capacity);
        APP_ERROR_CHECK(err_code);
    } while (capacity < 16);

    err_code = sd_rand_application_vector_get(random_bytes, sizeof(random_bytes));
    APP_ERROR_CHECK(err_code);

    err_code = sd_ble_gap_addr_get(&addr);
    APP_ERROR_CHECK(err_code);

    // Swap out 3 of the address bytes with the random bytes to make the address unique.
    addr.addr[2] = random_bytes[0];
    addr.addr[3] = random_bytes[1];
    addr.addr[4] = random_bytes[2];

    err_code = sd_ble_gap_addr_set(&addr);
    APP_ERROR_CHECK(err_code);

    gatt_init();
    advertising_init();
    services_init();
    sensor_simulator_init();
    conn_params_init();
    buffer_init();
    peer_manager_init();

    pm_privacy_params_t privacy_params;
    ble_gap_irk_t irk;

    memset(&privacy_params, 0, sizeof(privacy_params));

    privacy_params.p_device_irk = &irk;

    err_code = pm_privacy_get(&privacy_params);
    APP_ERROR_CHECK(err_code);


    //Update the local IRK
    irk.irk[2] = random_bytes[0];
    irk.irk[3] = random_bytes[1];
    irk.irk[4] = random_bytes[2];

    err_code = pm_privacy_set(&privacy_params);
    APP_ERROR_CHECK(err_code);
    // Start execution.
    NRF_LOG_INFO("HID Keyboard example started.");
    timers_start();
    advertising_start(erase_bonds);

    // Enter main loop.
    for (;;)
    {
        idle_state_handle();
    }
}

RE: MAC Address Incrementation Pairing issue

Karlo — Thu, 08 Jul 2021 12:53:37 GMT

Same problem here,

<info> peer_manager_handler: Connection security failed: role: Peripheral, conn_handle: 0x0, procedure: Bonding, error: 136

after trying to connect on incremented mac. This is happening on a windows device, android is working fine.

<debug> nrf_sdh_ble: BLE event: 0x10.
<debug> nrf_ble_gatt: Requesting to update ATT MTU to 256 bytes on connection 0x0.
<info> app: Connected
<debug> nrf_sdh_ble: BLE event: 0x23.
<debug> nrf_ble_gatt: Peer on connection 0x0 requested a data length of 251 bytes.
<debug> nrf_ble_gatt: Updating data length to 27 on connection 0x0.
<debug> nrf_sdh_ble: BLE event: 0x24.
<debug> nrf_ble_gatt: Data length updated to 27 on connection 0x0.
<debug> nrf_ble_gatt: max_rx_octets: 27
<debug> nrf_ble_gatt: max_tx_octets: 27
<debug> nrf_ble_gatt: max_rx_time: 2120
<debug> nrf_ble_gatt: max_tx_time: 328
<debug> nrf_sdh_ble: BLE event: 0x55.
<debug> nrf_ble_gatt: Peer on connection 0x0 requested an ATT MTU of 527 bytes.
<debug> nrf_ble_gatt: Updating ATT MTU to 256 bytes (desired: 256) on connection 0x0.
<debug> nrf_sdh_ble: BLE event: 0x3A.
<debug> nrf_ble_gatt: ATT MTU updated to 256 bytes on connection 0x0 (response).
<debug> nrf_sdh_ble: BLE event: 0x13.
<debug> peer_manager_handler: Event PM_EVT_CONN_SEC_START
<debug> peer_manager_handler: Connection security procedure started: role: Peripheral, conn_handle: 0, procedure: Bonding
<debug> peer_manager_handler: Event PM_EVT_CONN_SEC_PARAMS_REQ
<debug> peer_manager_handler: Security parameter request
<debug> nrf_sdh_ble: BLE event: 0x1A.
<debug> nrf_sdh_ble: BLE event: 0x19.
<debug> peer_manager_handler: Event PM_EVT_CONN_SEC_FAILED
<info> peer_manager_handler: Connection security failed: role: Peripheral, conn_handle: 0x0, procedure: Bonding, error: 136
<debug> peer_manager_handler: Error (decoded): BLE_GAP_SEC_STATUS 0x88
<debug> nrf_sdh_ble: BLE event: 0x11.
<info> app: Fast advertising.
<info> app: Disconnected

RE: MAC Address Incrementation Pairing issue

Roiger — Thu, 01 Jul 2021 13:41:14 GMT

Hi Vidar,
I also tried erasing bonds before the reset, to no avail.
We want this test to be able to happen w/o being physically connected to a debugger, so the nrjfprog option is not possible for us.

Thanks!
Roi

RE: MAC Address Incrementation Pairing issue

Vidar Berg — Thu, 01 Jul 2021 12:46:15 GMT

Hi Roi,

I think I would probably have created a random BLE address after every boot so I didn't have to keep track of the increment in RAM. Apart from that, it sounds like a good way to test this issue.

As for the pairing issue, did you try to reset the device after deleting the bonds? It may be an idea to use nrfjprog to erase the flash pages between each test to be absolutely sure the bonding information is erase:

1. nrfjprog --erasepage <fds_page_start-fds_page_end>

2. nrfjprog --reset

Vidar

RE: MAC Address Incrementation Pairing issue

Roiger — Tue, 29 Jun 2021 14:40:04 GMT

Hi Vidar!

Yes, the problem we see is definitely on the windows side. We simply want to try and estimate the number of paired devices windows can deal with before "going crazy".
I erase bonds only on the nRF end, because part of the issue on the windows end is the amount of LTKs and cached GATT tables, so I want to keep them.
You are correct - we want the windows PC to pair with the incremented mac as if it is a new device. Is there a more elegant solution that you can suggest?

Thanks for your quick reply!

Roi

RE: MAC Address Incrementation Pairing issue

Vidar Berg — Tue, 29 Jun 2021 13:29:02 GMT

Hi,

Error 136 corresponds to BLE_GAP_SEC_STATUS_UNSPECIFIED assuming it reported via the PM security failed event, so it's not the most helpful error code I'm afraid. I'm not sure how I should try to replicate this error here, can you maybe provide the steps for me?

[quote user=""]high number of paired devices[/quote]

Just to confirm, is this an issue on the Windows PC or on the nRF side?

[quote user=""]I also erase bonds post reset, and have tried pre reset as well.[/quote]

On PC, nRF, or both?

[quote user=""]I see the advertisement on the incremented mac address[/quote]

What's the purpose changing the address, is it to make the windows PC see the nRF as a new device.

Thanks,

Vidar