MAC Address Incrementation Pairing issue

[Roiger]

Hi,

We are testing mass pairing on our windows machines, as we have seen problems with a high number of paired devices.

I am able to increment the mac address by using sd_ble_gap_addr_set, and saving it in a noinit ram section, and soft reseting the device.

I also erase bonds post reset, and have tried pre reset as well.

I see the advertisement on the incremented mac address, but I receive a pairing error (136 - which from what I have seen, is the result of an invalid state of the PM).

What can I do to fix this?

Thanks!

Roi

[Vidar Berg]

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();
    }
}

[Roiger]

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

Just out of interest - what exactly is the irk?

[Vidar Berg]

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():