Is it possible to whitelist only selected peer(s)?

RE: Is it possible to whitelist only selected peer(s)?

annapalu — Thu, 06 Apr 2017 06:46:26 GMT

Hi, if i have understood correctly the dm_device_delete() deletes the bonding information and whitelist, too. If i'm using a peer manager, i used pm_peers_delete, but doesn't cleat the whitelist. How can i delete the whitelist with peer manaher?

RE: Is it possible to whitelist only selected peer(s)?

NrfFan — Mon, 19 Oct 2015 07:18:26 GMT

So it turns out function dm_whitelist_create() returns IRK/addresses of bonds not being in CONNECTED state. Therefore you need to wait until peer disconnection to extract his (newly added) IRK/address, which is somewhat inconvenient.

RE: Is it possible to whitelist only selected peer(s)?

Petter Myhre — Thu, 08 Oct 2015 07:38:40 GMT

Yes. I agree, but try it. If you figure out some other solution please consider posting it here. I should also mention that we are currently doing some work on the device manager. If you are interested in more information about this you can contact the Sales Manager for you area. If you don't know who it is, send me a PM with your location and I'll let you know.

RE: Is it possible to whitelist only selected peer(s)?

NrfFan — Thu, 08 Oct 2015 06:21:02 GMT

Thank you, that should actually work. Although the process of cherry-picking newly added addr/irk from whitelist semms a bit desperate to me :) . Anyway, overall it is a very good idea, I will certainly try that. Thanks again. Tom.

RE: Is it possible to whitelist only selected peer(s)?

NrfFan — Wed, 07 Oct 2015 12:29:33 GMT

Yes, I was thinking of being more in charge of managing this bonding "slots". Eg. waking up with long-press will put my peripheral in undirected advertisement mode and first device connected and bonded will be (somehow) associated with slot dedicated to that button. And yes, user/application should have full control over unbinding and overwriting specific bonding slots.

RE: Is it possible to whitelist only selected peer(s)?

Petter Myhre — Wed, 07 Oct 2015 12:21:54 GMT

I see. So what should happend if you press button 2? Should the device put the device that bonded secondly in the whitelist? Or are you thinking of a more manual way of binding the buttons to central devices? For example that you press button 2 and then you connect and bond to a central, and then that central is bound to button 2? Should you be able to unbind central devices?

RE: Is it possible to whitelist only selected peer(s)?

NrfFan — Wed, 07 Oct 2015 12:01:53 GMT

Yes, peripheral device should have 4 input buttons, each dedicated to single "bonding slot". When user presses button 2, device is waked up from sleep and starts whitelist-advertisement with previously bonded peer associated with slot number 2. Basically whitelisting in this application serves as the way for user to select which remote peer he wants to connect. Peer may be phone, tablet or desktop PC. I have strong feeling now, I will need to tweak device manager.

RE: Is it possible to whitelist only selected peer(s)?

Petter Myhre — Wed, 07 Oct 2015 11:55:27 GMT

You need some way of identifying that particular central. You need some way of telling the peripheral device what IRK/address that is special. I'm not sure what is the best way of doing this. You say "Section is made my user", does this mean that the peripheral device has some user input? What is your central? Smart phone? Could you explain a bit more about your application?

RE: Is it possible to whitelist only selected peer(s)?

Petter Myhre — Wed, 07 Oct 2015 11:10:42 GMT

You shouldn't use that, it is for setting/getting the IRK for your device, not the peers.

RE: Is it possible to whitelist only selected peer(s)?

NrfFan — Tue, 06 Oct 2015 19:43:38 GMT

Thank you. Could you please tell me how can I receive IRK for connected device? I've been trying to figure out how device_manager_peripheral.c is doing this, yet I was not quite successfull. The only softdevice API call returning IRK (and some other data) I've found was following:

sd_ble_opt_get(BLE_GAP_OPT_PRIVACY, ...)

RE: Is it possible to whitelist only selected peer(s)?

Petter Myhre — Tue, 06 Oct 2015 15:15:58 GMT

From a SoftDevice perspective it is possible. The application decides what addresses/IRKs that should be given to sd_ble_gap_adv_start().

You just need to figure out what the address/IRK of the central is and put it into the whitelist.

Edit 07.10.2015 I may have a solution.

You have four slots, so set up device manager to store maximum 4 bonds.

The user presses button 2. This notifies the main application that slot 2 should be used. Then advertise->connect->bond. When bonding is complete the BLE_GAP_EVT_AUTH_STATUS event will be received by the main application. This event is handled by device manager, but in it you can find information like if the bonding was succesful (p_ble_evt->evt.gap_evt.params.auth_status.auth_status), if bonding was performed (p_ble_evt->evt.gap_evt.params.auth_status.bonded). So you can check if these are correct and then you can call dm_whitelist_create().

This will return two lists, one with addresses and one with IRKs. At this point there should only be one address or one IRK in the lists. You take this IRK or address and store it in slot 2 in a struct in your main application.

If then button 3 is pressed most of the procedure will be repeated but you will have 2 addresses/IRKs in the lists when you call dm_whitelist_create(). Compare the address/IRK of slot 2 (and the other slots that are not empty) to figure out which one is the new address/IRK and store it in slot 3.

Bond deletion. When you call dm_whitelist_create() you can also call dm_handle_get(). Then you will get the dm handle of the bond you are currently in connection with. Store this in the correct slot together with the IRK/address. Then if button 2 is long pressed (for example) you know what dm handle to use when you call dm_device_delete() to delete the bond in the device manager. Then clear the slot..

The device manager stores bonds persistently, so I would store the slots persistently as well.

This may work, and it doesn't require you to change the device manager library. It is just an idea though.