Hi,
If you know the address and IRK you can use filter accept list to only allow the pre-defined device to connect, and perform bonding on the first connection. You can refer to the Bluetooth: Peripheral Accept List sample to see how it can be done (this is getting the address from an existing bond, but that is not a requierment).
Hi, thanks for your quick response !
I already checked peripheral accept list example, and it seems that it's not what I'm trying to achieve.
Actually, I have devices that uses the same IRK, and the devices adresses are random. I need to be able to connect to these peripherals when they are in reach.
The previous project that was using the same devices was based on the previous nRF SDK. This project was using "peer_manager" to create a default peer (random fake addr + known irk) at startup and then launched direct connection to this peer.
I need to reproduce the same process, do you know if this is feasible with Zephyr BLE stack ?
Hi, thanks for your quick response !
I already checked peripheral accept list example, and it seems that it's not what I'm trying to achieve.
Actually, I have devices that uses the same IRK, and the devices adresses are random. I need to be able to connect to these peripherals when they are in reach.
The previous project that was using the same devices was based on the previous nRF SDK. This project was using "peer_manager" to create a default peer (random fake addr + known irk) at startup and then launched direct connection to this peer.
I need to reproduce the same process, do you know if this is feasible with Zephyr BLE stack ?
As you mention the peer manager I assume the devices were pre-bonded, so it was not just that you did whitelisting? So that you also have the LTK stored? If so, I am not aware of any way to handle that with Zephyr BLE APIs. However, it should be possible in a different way. I do not have an example for this, but conceptually you could make a dummy bond with some arbitrary device, and read out the flash region used by settings. Then make a script that modifies this, overwriting the address, IRK and LTK and potentially other peer related information with the data used for thie specific peer this device should be bonded with, and program that as a separate hex file in addition to the application. This cold be scripted so it sould work alson on a production line.
Yes, my bad, old project was using whitelisting with peer_manager.
From what I can see, here is a sample pseudo-code that old project is running to create a default bond with targeted peripherals (I'm not the person who developped this project):
/* Default Bond adding in peer manager */ static pm_peer_data_bonding_t bonding_data; memset(&bonding_data, 0x00, sizeof(bonding_data)); bonding_data.own_role = BLE_GAP_ROLE_CENTRAL; bonding_data.peer_ble_id.id_addr_info.addr_type = BLE_GAP_ADDR_TYPE_RANDOM_STATIC; memcpy(bonding_data.peer_ble_id.id_addr_info.addr, targeted_peripheral_fake_addr, 6); memcpy(bonding_data.peer_ble_id.id_info.irk, targeted_peripheral_IRK, 16); ret = pm_peer_new(&new_peer_id, &bonding_data, NULL);
After the creation, whitelist is loaded and direct connection is made.
NRF_LOG_DEBUG("Whitelist ok. Direct connexion.");
m_scan_params.use_whitelist = 1;
m_scan_params.adv_dir_report = 0;
ret = sd_ble_gap_connect(NULL, &m_scan_params, &m_central_connection_param, APP_BLE_CONN_CFG_TAG);
APP_ERROR_HANDLER(ret);
Navigating through the devzone forum, i noticed someone had the same problem (as far as I can see) as me : devzone.nordicsemi.com/.../resolve-ble-address-using-zephry
Hi,
I see. So only whitlisting (but with IRK to handle resolvable random addresses), but no bonding yet. In that case you have the problem with the limited API as described in the other thread, but the appraoch in this post in the same thead seems to make sense.