irk_match when having a BLE_GAP_EVT_CONNECTED

[Marcel Mulder]

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

[Ulrich Myhre]

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.

[Marcel Mulder]

Ah ok, I see. I don't use white listing so that explains it :-) I am using S110 (7.2.0) as peripheral and connecting to iOS devices. So, if white listing is not used than the only way of identifying a device is by using the address or the diversifier. Does the softdevice match the irk to the diversifier? Because when using random addresses irk is needed to identify the device. not the diversifier. How does that work?

[Ulrich Myhre]

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.

[Marcel Mulder]

I understand the specification. I do not understand how your softdevice is working.

You are saying that the diversifier does not playing any role here. How do you explain the following code from the device_manager_peripheral.c in function device_instance_find(...)

if (((NULL == p_addr) && (div == m_peer_table[index].div)) || ((NULL != p_addr) && (memcmp(&m_peer_table[index].peer_id.id_addr_info, p_addr, sizeof(ble_gap_addr_t)) == 0)))

If no address is available than you use the diversifier to find the device in the peer table. I searched trough the code of device_manager_peripheral.c and irk is not used except when white listing. The bd address can change so that's not a unique key. The diversifier is not playing any role as you state. So the big question is. What do I use from the softdevice to identify a device?

[Ulrich Myhre]

In connection setup, the encryption diversifier plays no role. If you want to identify a device before connecting, you need to know the static peer address or its IRK. If you want to identify a (previously bonded) device by the means of instantly encrypting, then that is a way. The master sends the previously agreed-upon diversifier and you look up the LTK that belongs to it. These are the keys you need to store to be able to identify the master for encryption. A table of LTKs, indexed by the div. The device manager's device_instance_find() is only called when encryption has been started by the master.

In newer variants of the SoftDevice, we abandoned the combined diversifier approach and ask you to instead look up the LTK based on an EDIV and RAND which is sent from the master.

[Marcel Mulder]

Ok ,we understand each other than correctly now. The real question was already answered for, but I was curious if I understood correctly how your softdevice works. This was outside the scope of BLE_GAP_EVT_CONNECTED. There lies the misunderstanding between us. Will the new version of the softdevice, which abandon the diversifier and start using the EDIV and RAND, be released shortly? Because I have to change my device manager than and I will release in a couple of weeks.