Can´t pair again after disconnection

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

Parents
  • Hi Einar, thanks for the quick response.

    I'm pairing using fixed passwords sent in .passkey_entry callback.

    I did some additional testing:

    1) When paired, if I only reset the peripheral, the central gets the error code (2) when trying to pair again.

    2) When paired, if I erase the peripheral memory (recover board) and reprogram it, I get error code (2) also.

    3) When paired, if I reset the central, when it goes live again the devices will re-pair properly by .passkey_entry callbacks.

    Based on that, can we assume the issue is on the central side? When the peripheral resets, the central thinks it will get back live with the previous bonding settings, which is not the case.

    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?

Reply
  • Hi Einar, thanks for the quick response.

    I'm pairing using fixed passwords sent in .passkey_entry callback.

    I did some additional testing:

    1) When paired, if I only reset the peripheral, the central gets the error code (2) when trying to pair again.

    2) When paired, if I erase the peripheral memory (recover board) and reprogram it, I get error code (2) also.

    3) When paired, if I reset the central, when it goes live again the devices will re-pair properly by .passkey_entry callbacks.

    Based on that, can we assume the issue is on the central side? When the peripheral resets, the central thinks it will get back live with the previous bonding settings, which is not the case.

    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?

Children
No Data
Related