cancel
Showing results for 
Search instead for 
Did you mean: 

BLE Whitelisting

aj.sk
Associate III

My BLE (BlueNRG-MS) application has to offer the following functions and I'm not sure what's the correct approach

  • I need to have a pairing mode where a central device can connect. I think this is achieved by using aci_gap_set_discoverable() with NO_WHITE_LIST_USE, this seems to work
  • When the application is not in the pairing mode, only devices which have been paired already should be able to connect. This is where I thought I can use whitelist by change the aci_gap_set_discoverable() with WHITE_LIST_FOR_ALL. Is this assumption correct and can I switch between the two discoverability modes without losing an already established connection?
  • To be able to use the WHITE_LIST_FOR_ALL, I add devices which connect while in pairing mode to the whitelist using hci_le_add_device_to_white_list(0x01, cc->peer_bdaddr) - is this how it should be done? If yes, what do I have to do in order to save the whitelist persistently, because it seems that after a reboot, I don't see the BLE device anymore when discoverability mode is WHITE_LIST_FOR_ALL.
  • Is there a way to figure out whether a certain Central device is already on the whitelist?

Any help is much appreciated and if further information is needed I'm more than happy to provide it!

Update:

Seems like as soon as the central device changes it's mac address the whitelist approach doesn't work anymore. What do I have to do in order to be able to resolve random addresses from the same central device?

5 REPLIES 5
aj.sk
Associate III

I found a connection and pairing procedure outlined in the PM0257 (sec. 3.10.1) that seems to cover pretty much what I'm looking for. My problem now is that the referenced function aci_gap_add_device_to_resolving_list() doesn't seem to exist in my API. Do I have to use another one instead? I couldn't find one that seems to do the job.

aj.sk
Associate III

I think I'm again one step further but still have some issues.

On EVT_LE_CONN_COMPLETE I call aci_gap_configure_whitelist to add the connected device to the whitelist. If I call aci_gap_get_bonded_devices I can see that a device has been added and that the added address matches with the connected one if I resolve it using aci_gap_resolve_private_address_IDB05A1 (to be honest I don't know where this IDB05A1 comes from, seems to be a dev board?).

So the device should be in the whitelist and the address should be resolvable. Still I cannot discover the peripheral with the discoverability filter policy WHITE_LIST_FOR_ALL. Or do I have to somehow add the bonded device to the whitelist on every startup?

Dann
Associate II

Have you solved your problem? I have the same issue, after successful bonding I call aci_gap_configure_whitelist and aci_gap_add_devices_to_resolving_list with data provided by aci_gap_get_bonded_devices function (bounded devices address' types and values) then I call aci_gap_set_undirected_connectable to perform a private connection and everything seems to work pretty well, however information about bonded devices seems to be lost after reboot and I need it to be persistent.

The question is: How to save and restore bonding data on flash so it won't be lost after power-down?

aj.sk
Associate III

Unfortunately I haven't had the time to further dig into this, but this will be a topic that I have to solve in the near future. My current approach would be to keep a copy of the whitelist in my application (NVM) and then restore the whitelist from this on startup. This way I also have the possibility to delete single devices from the whitelist. But I havent tried so I'm not sure whether this works or not. It would indeed be great if someone from ST could shed some light into this topic.

Dann
Associate II

It seems like a big deal to keep whitelist but there is no hints in documentation about the proces of saving and restoring that data. It would be great if anyone from ST would share any steps. Please contact me on e-mail when you get back to your BlueNRG project and we can discuss about this and any other issues in BLE, my e-mail: dann.laboratory@gmail.com

Dann