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, could you clarify which devices are connecting and advertising here? And what SoftDevice are you using?

[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?