how to avoid bonding of device more then one time.

[sunil kumar]

Hello iam using softdevice 110 and SDK 10.0.0, i want to know the way to avoid bonding of device more then once, or deleting the bonding information from persistent memory if bonded device requests for bond again. Iam using device manage APIs.

[Hung Bui]

Hi Sunil,

In SDK v10 device manager actually will replace old bond with new one if the device request to pair again. But if your master uses Random Resolable Addess, device manager only manages to find the central if you use whitelist when advertising and the IRK matches is returned.

In SDK v11, we changed the behaviour and device manager will deny the central to pair again, but still whitelist is needed.

You can either modify the device manager, to add code to resolve the IRK on its own to find the previously bonded master or you can use peer manager.

With peer manager in SDK v11 and later, all master who want to rebond will be rejected, regardless if you advertise with whitelist or not.

[sunil kumar]

I want to allow central to bond if it is requesting for second time, but not to store bonding information again, will using whitelist solve this.

[sunil kumar]

If i use whitelist the device will not pair with more then one device. although it will not pair with same device(which uses Random Resolable address) again, kindly help me to solve this.

[Hung Bui]

Hi Sunil,

It need to be clarified here about with and without whitelist.

When advertising with whitelist, no more new central can connect to your device, only the centrals in the list. Usually you only allow advertising without whitelist when you don't have any master in the list, or when you want to allow a connection from a new device. Usually there is a "Pair" button on the device to allow the device to advertise in "open mode".

Advertising with whitelist is important to recognize an already bonded master, especially the master with "Random Resolvable address" because the address may already changed.

If you don't use whitelist and the bonded master connect, the softdevice won't be able to tell if it's a bonded master in the whitelist or not. The application will treat it as a new master.

We solved this issue by manually resolve the master address in the application. This is implemented in the peer manager. Please have a look in BLE_GAP_EVT_CONNECTED event in im_ble_evt_handler() in id_manager.c to see how we do it. In Peer manager, we defined the PM_EVT_CONN_SEC_CONFIG_REQ event, when the application need to reply it will allow re-bonding or not.

In your case, you want to allow bonding again but you don't want to store bonding information, I think what you need to modify in the code is:

• Add manual address resolving, so you can recognize the central with or without whitelist.

• Add a flag, you set the flag if you connected to a already bonded central, you can use the flag to allow bonding but no storing. The storing of the bond information is done in BLE_GAP_EVT_AUTH_STATUS event, in dm_ble_evt_handler().