This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

irk_match when having a BLE_GAP_EVT_CONNECTED

Hi all,

I have made my own device manager because the device manager from Nordic is somewhat bloat (in code and resources) and I needed to add a feature, ranking the devices so the less used device is removed when the storage is full and a new devices wants to bond. I was not able to create this feature outside the device manager. Anyway, I want to test the manager and every thing is working well. The only thing I am not able to test is irk. I never see an irk_match. The devices gets identified by means of the address or by means of the diversifier. I find this rather strange be cause the iPhone uses a random address, so it should be identified with an irk. Does anybody knows why I do not get a irk_match in a connect event?

Thanks in advance,

Marcel

Parents
  • Hi,

    You will only get an irk_match if you advertise or connect using a whitelist with IRKs in it (irk_count > 0). As a peripheral, the SoftDevice will resolve all devices trying to connect to or scan it and only respond if there is a hit in the address or IRK whitelists. As a central, the SoftDevice will process all connectable advertisers that use resolvable address types and match them before trying to connect

    If a connection happens due to a match coming from the IRK part of the whitelist, the index to entry which was matched will be present in the irk_match field of the connected event.

  • No, the diversifier is (AFAIK) only used to look up the actual IRK in case you have many of them stored. The spec explains the resolving process pretty well, but in short it is like this: Resolvable random address consists of 3 random bytes (2 bits in the first byte is address type, and thus not random) and 3 hash bytes. The hash bytes are generated using the IRK and the random bytes. When using our SoftDevice, the radio will detect the first bits and start resolving them by trying to hash the random bytes with all available IRKs. When a match happens, a connection (or scan request) happens. So the diversifier is not in play here.

Reply
  • No, the diversifier is (AFAIK) only used to look up the actual IRK in case you have many of them stored. The spec explains the resolving process pretty well, but in short it is like this: Resolvable random address consists of 3 random bytes (2 bits in the first byte is address type, and thus not random) and 3 hash bytes. The hash bytes are generated using the IRK and the random bytes. When using our SoftDevice, the radio will detect the first bits and start resolving them by trying to hash the random bytes with all available IRKs. When a match happens, a connection (or scan request) happens. So the diversifier is not in play here.

Children
No Data
Related