How to know that the device disconnected due to an authentication failure

[V.Lorz]

Hi,

I configured for using security BT_SECURITY_L2 for a device that I had previously configured for using BT_SECURITY_L4. When I try to connect with an Android phone that was previously paired when configured for BT_SECURITY_L4, it prints "SMP does not allow a pairing failure at this point. Known issue. Disconnecting instead." to the log and then disconnects.

From this question [here], for solving this issue I need to call bt_unpair(...) to erase bonding information.

How can I know, inside the callback disconnected, that the connection was closed with BT_HCI_ERR_AUTH_FAIL? I always receive reason 22 (BT_HCI_ERR_LOCALHOST_TERM_CONN).

BR

[Kenneth]

Hi Chase,

For test you can try to add (one or all):

• CONFIG_BT_ID_UNPAIR_MATCHING_BONDS=y
• CONFIG_BT_ID_ALLOW_UNAUTH_OVERWRITE=y
• CONFIG_BT_KEYS_OVERWRITE_OLDEST=y
• CONFIG_BT_SMP_ALLOW_UNAUTH_OVERWRITE=y

If that doesn't help, then my next suggestion is an on-air sniffer log:
https://www.nordicsemi.com/Products/Development-tools/nRF-Sniffer-for-Bluetooth-LE 
https://docs.nordicsemi.com/bundle/nrfutil/page/README.html 

You can send me the .pcapng file from wireshark, just make sure to sniff the specific connection by following:
https://docs.nordicsemi.com/bundle/nrfutil/page/nrfutil-ble-sniffer/guides/common_actions_sniffing_conn_single_periph.html 

Edit: Sorry, I can see I didn't really address your question.

How can I know, inside the callback disconnected, that the connection was closed with BT_HCI_ERR_AUTH_FAIL? I always receive reason 22 (BT_HCI_ERR_LOCALHOST_TERM_CONN).

Maybe register a bt_conn_auth_info_cb callback to capture authentication failures (pairing_failed). In the pairing_failed() callback, you can react appropriately, e.g., call bt_unpair().

Kenneth

[V.Lorz]

Thanks Kenneth,

I implemented the callback but I receive error code 9, according to enum bt_security_err this is BT_SECURITY_ERR_UNSPECIFIED.

Is this the intended behaviour? Or should I expect a different code?

BR

[Kenneth]

I suspect this is a corner case that you encounter during development and not on an end product.

You can try to add the kconfig options I have suggested just to check if that make any difference.

Can tell me which side had keys intact here when you encountered the issue, is it the phone or the peripheral that still had the keys intact?

Kenneth

[V.Lorz]

I seems like CONFIG_BT_ID_ALLOW_UNAUTH_OVERWRITE has a dependency on CONFIG_BT_SMP_ALLOW_UNAUTH_OVERWRITE being 'n'.

It is the peripheral which still has the keys intact.

BR