This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Bonding - difference between IRK and address in whitelist

Why some devices makes just an IRK entry in Whitelist of SDK and other put the address into? Is it possible to config which entry should be done?

Parents
  • 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.

  • 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

Reply
  • 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

Children
No Data
Related