Can´t pair again after disconnection

Question

Hello,

I have a custom peripheral and a custom central device. I based my code on central_uart and central_hids.

The central scans for the peripheral, and once found (by UUID) connects, an sets security to L4 (paired and encrypted, using fixed password).

Up here everything works fine.

The issue happens when I reset the peripheral device.

The central will go to disconnected, kill the open connections and call bt_scan_start again. It will once again find the peripheral, connect, but I will get an error in the pairing, as follows:

[00:00:05.145,904] <inf> ble_scanner: pairing_complete: Pairing completed: F9:FC:08:12:08:72 (random), bonded: 1
[00:00:05.146,148] <wrn> ble_scanner: security_changed: Security changed: F9:FC:08:12:08:72 (random) level 4
[00:00:05.146,148] <dbg> ble_scanner: gatt_discover: Running Gatt Discover Function
[00:00:06.045,776] <inf> ble_scanner: discovery_completed_cb: The discovery procedure succeeded
[00:00:06.085,418] <dbg> simple_service: bt_simple_service_handles_assign: Getting handles from Custom Auth service.
[00:00:06.085,449] <dbg> simple_service: bt_simple_service_handles_assign: Found handle for LED Write characteristic = 0x15.
[00:00:06.085,479] <dbg> simple_service: bt_simple_service_handles_assign: Found handle for BUTTON Read characteristic.
[00:00:06.085,510] <dbg> simple_service: bt_simple_service_handles_assign: Found handle for CCC of BUTTON Read characteristic.
[00:00:06.085,571] <dbg> simple_service: bt_simple_service_subscribe_receive: [SUBSCRIBED]
(peripheral is reseted here)
[00:00:12.345,794] <dbg> simple_service: on_received: [UNSUBSCRIBED]
[00:00:12.345,977] <inf> ble_scanner: disconnected: Disconnected: F9:FC:08:12:08:72 (random) (reason 8)
[00:00:12.710,083] <inf> ble_scanner: scan_filter_match: Filters matched. Address: F9:FC:08:12:08:72 (random) connectable: 0
[00:00:12.816,650] <inf> ble_scanner: connected: Connected: F9:FC:08:12:08:72 (random)
[00:00:13.068,176] <err> ble_scanner: security_changed: Security failed: F9:FC:08:12:08:72 (random) level 1 err 2

Based on some DevZone tickets, I ensured my disconnected function calls the bt_conn_unref for all open connections.

As I can reconnect again, I think open connections are not the issues.

Somehow the new connection pairing / security handshake is not happening when reconnecting.

Is there something else that I need to clean up / unset to get this working? I can only connect again if I reset the central board.

Please see attached code if needed.

simple_service.zip

Einar Thorsrud · Accepted Answer

Hi, 
 The error code (2) is BT_SECURITY_ERR_PIN_OR_KEY_MISSING. Is the slave just reset or is the flash erased (or at least the bonding info)? If so, that could explain the error. And in that case, the fix would be either to not delete the bonding info on the peer, or add CONFIG_BT_SMP_ALLOW_UNAUTH_OVERWRITE=y to allow repairing in case the peer has lost the bonding information (this is not without down-sides though, as it would allow an attacker to replace an existing bond with by spoofing the peer address and pairing).

Einar Thorsrud · Answer

Hi, 
 Joao Dullius said: Based on that, can we assume the issue is on the central side? 
 Not necessarily. Are you only pairing (establishing a single encrypted session), or are you bonding as well (where the keys should be used for consecutive connections)? If you are only pairing, it wold seem the central is in error (as it looks like it has kept the bonding information). But if you are bonding, the issue seems to be with the peripheral, as it should keep the bonding information and use that the next time. 
 Joao Dullius said: Is there anyway to do the opposite from CONFIG_BT_SMP_ALLOW_UNAUTH_OVERWRITE=y, and force the central to do the bonding from scratch, doing all the .password_entry on both sides again? 
 If you want to do that on every connection, then simply don't bond (but pair). If you never want to bond, add CONFIG_BT_BONDABLE=n to your prj.conf.

Einar Thorsrud · Answer

Hi, 
 You always need to call settings_load() after reset when using settings. This is also the case when using CONFIG_BT_SETTINGS=y, as described in the documentation .