Bonding - difference between IRK and address in whitelist

RE: Bonding - difference between IRK and address in whitelist

Pål Håland — Thu, 15 Aug 2013 11:36:35 GMT

You can identify the peer device based on the IRK index received in the BLE_GAP_EVT_CONNECTED (if it was a IRK match) and you can remove that index from the IRK whitelist.

(Check the ble_gap_evt_connected_t structure) irk_match is set to 1 if it was connection by IRK and irk_match_idx is the index number of the IRK's

RE: Bonding - difference between IRK and address in whitelist

Manuel Urfer — Wed, 14 Aug 2013 12:21:07 GMT

thank you for the answer.

Then a further question: I have the nrf51822 as slave with bonding manager, and multiple centrals (Iphone using IRK). How can I identify 1 specific Iphone to kick only this one out of the whitelist(not deleting all)?

RE: Bonding - difference between IRK and address in whitelist

Pål Håland — Wed, 14 Aug 2013 10:48:25 GMT

If you connect to a device that uses a Random Resolvable Address, then there is no point in adding the address to the whitelist, because that address would at least change every 15 minutes.

Ideally you should receive a public/"random static" address during the exchange of the IRK, that you could put in to the whitelist as well. So that if the privacy of the device is turned off you would still be able to connect.

The only addresses that should be added to the whitelist is Public device address or random static device address as these would never change for the lifetime of the device, as random resolvable and non-resolvable random device addresses would change, and you might not be able to connect anymore.

If all of the "devices" you talk about is different SDK examples, and they do not use the bond manager to handle the whitelist, then I'm not sure how to respond to this question. And hopefully someone else can help you with it.

In case they do use the bond manager, then you can modify the code to only use one of the options, but as explained, you might have difficulties connecting at a later point.