Delete bonding information from central only

[Youngjun]

Hi,

I'm implementing LESC.

• SDK version : 16.0.1
• SD version : 7.0.1
• example code : ble_app_hrs

I checked that the LESC(just works) function is working.

But, I found a problem when delete bonding information from central.

If the bonding information is deleted only from the central, central does not become bonding after.(bonding information exist in peripheral)

So, i added allow_repairing in pm_evt_handler() like this thread.

After allowing repair, the central can bonding with peripheral even if peripheral have bonding information.

But here comes another problem.

After allowing repair, the central ask pairing request twice.

This is the log of nRF Connect. (android application)

Connection parameters updated (interval: 45.0ms, latancy: 0, timeout: 5000ms)
[Broadcast] Action received: android.bluetooth.device.action.PAIRING_REQUEST, pairing variant: PAIRING_VARIANT_CONSENT (3)
[Boradcast] Action received: android.bluetooth.device.action.BOND_STATE_CHANGED, bond state changed to: BOND_BONDED (12)
Device bonded

My implementation goals are as follows.

1. delete bonding information in central only
2. pair central to peripheral
3. ask pairing request once (like first bonding)

Is there a way to use it like bonding for the first time without deleting the information from the peripheral?

[Einar Thorsrud]

I am not sure I  understand the issue here. Can you upload a full log as well as a sniffer trace, and explain in detail how this differs from what you would have expected?

[Youngjun]

Hi,

I'm testing bonding function.

And I encountered bonding pop-up issue like this thread. This problem occurred when using re-pairing function.

I used re-pairing function because I want to connect central and peripheral when bonding information deleted only from central.

I wonder how Nordic handles this situation(when bonding information deleted only from central).

Does Nordic also use the re-pairing function? Or is there another way?

Regards,

Youngjun

[Einar Thorsrud]

Hi Youngjun,

Youngjun said:

Does Nordic also use the re-pairing function? Or is there another way?

Nordic doe snot make end products, but we provide SDKs that allow customers (like you) to do this in different ways.

Youngjun said:

And I encountered bonding pop-up issue like this thread. This problem occurred when using re-pairing function.

This has a good explanation of what happens. I do not see anything wrong in the handling on either side here, but the "issue" seems to occur when the nRF initiates encryption early after the connection is established, as it still has the bonding information, and this is before the Android devices has initiated pairing.

There are (at least) two ways to change this behavior, though this is timing dependent so exactly what works may change over time if Android starts behaving differently:

1. Make all characteristics require security, to make Android pair earlier, as was done by the customer in the other thread (see this post).
2. Prevent or delay the nRF from initiating encryption with already bonded peers (which this is seen form the nRF). You can easily add a delay here by setting PM_HANDLER_SEC_DELAY_MS in your sdk_config.h to a higher number (the default value is 0, where there is no delay).