pairing fail with ncs 2.8.0

[ziv123]

hello Nordic 

we are working with nrf52832 and nrf 52840 .. migrated to ncs2.7.0 lately and now migrating to ncs 2.8.0 (at the moment building without sysbuild)

we did not change anything in the pairing mechanism but suddenly it seems to stop working

i first get the 'bt_conn_cb'  callback of " .security_changed" which inside it i get that  'bt_conn_get_security(const struct bt_conn *conn)  returns with value = 2 which indicates pairing 

but right after that i get another  'bt_conn_auth_info_cb' callback of " .pairing_failed" followed by the first callback .. indicating a fail 

i get this print (from ncs) " bt_smp: pairing failed (peer reason 0x3) "

any idea what has changed ?

and what does peer reason 3 means ?

hope to read you soon

best regards

Ziv

[Einar Thorsrud]

Hi Ziv,

I assume the reason you print is an bt_security_err instance (which you get in the pairing_failed callback). And then, reason 3 is BT_SECURITY_ERR_OOB_NOT_AVAILABLE. That is not an error I would expect unless you are doing OOB pairing?

[ziv123]

Hi Einar

Einar Thorsrud said:

I assume the reason you print is an bt_security_err instance (which you get in the pairing_failed callback)

in this callback i actually print reason 4 ->  BT_SECURITY_ERR_AUTH_REQUIREMENT (still wonder why, and now i know it also happens sometimes with ncs 2.7.0, but we did not had this issue before)

Einar Thorsrud said:

That is not an error I would expect unless you are doing OOB pairing?

we are not doing out of band pair.

the peer reason 3 is a print that exist in the ncs itself 

(v2.8.0/zephyr/subsys/bluetooth/host/smp.c , line 1299 and/or line 3811

(v2.7.0/zephyr/subsys/bluetooth/host/smp.c , line 1236 and/or line 3733

any idea what this '3' error is or why i get  BT_SECURITY_ERR_AUTH_REQUIREMENT ? 

hope to read you soon

best regards

Ziv

[Einar Thorsrud]

Hi Ziv,

Ah, yes - I missed that. As you get BT_SECURITY_ERR_AUTH_REQUIREMENT I wonder if there is allready an existing bond with the peer? If so, the bond needs to be deleted, or you need to allow re-pairing by adding CONFIG_BT_SMP_ALLOW_UNAUTH_OVERWRITE=y and CONFIG_BT_ID_UNPAIR_MATCHING_BONDS=y. This means that bonds can be replaced without specific actions, which is often the desiered behaviour, but not always.

[ziv123]

Hi Einar

Einar Thorsrud said:

f there is allready an existing bond with the peer? If so, the bond needs to be deleted

not sure i follow, because we pair once and then save the generated keys in flash for next pairing,  not to go through the process every time. i don't think we deliberately unpair, and we do not use multiple ble identities (.. the only scenario that could be is that a device connects with 2 different nodes and has to pair with each one separately and another scenario that is not yet active is pairing with 2 different adaptores on the same node).

.. so by deleting the bond it will mean that the key generation will take place in every connection ? 

Einar Thorsrud said:

which is often the desiered behaviour, but not always.

can you elaborate a bit on why it is desired and in what ,example ,case can this be undesired ?

and also is this something that was added or changed in ncs 2.7.0 or 2.8.0 that cause this issue to arise for us now ?

and last but not least .. when added the configs you mentioned to prj.conf i get a different err from my callback implementation for pairing failed -> reason is BT_SECURITY_ERR_UNSPECIFIED .. any ideas what i am doing wrong ?

hope to read you soon

best regards

Ziv

[Einar Thorsrud]

Hi Ziv,

ziv123 said:

.. so by deleting the bond it will mean that the key generation will take place in every connection ? 

I should have specified better. You can only bond once with the same peer. If allready bonded, the bonding information (key etc) is re-used every time. However, if the peer device lost the bonding information for some reason (typically a user deleted it on a phone or similar), the old bond information is no longer valid. In this case, bonding again is not allowed, as a bond allready exist. I am wondering if that is what has happened here? If so, and i fyou want to allow bondign again even if a bond exist (to gracefully handle the case where the peer device no longer has the bond), you need to explicitly allow it.

ziv123 said:

can you elaborate a bit on why it is desired and in what ,example ,case can this be undesired ?

For usability reasons, you often want to be able to bond again with a device you have an existing bond with, if the bond has been deleted (deliberately or not) on that device without explicitly deletign that bond first. For many products this is in practice a requierment. However, this also opens up the possability that an attacker can spoof the address of another device and replace it's bond, which is why it is not allowed by default.

ziv123 said:

and also is this something that was added or changed in ncs 2.7.0 or 2.8.0 that cause this issue to arise for us now ?

and last but not least .. when added the configs you mentioned to prj.conf i get a different err from my callback implementation for pairing failed -> reason is BT_SECURITY_ERR_UNSPECIFIED .. any ideas what i am doing wrong ?

No, there has not been significant changes on this part. But this is a common issue that we often see when testing, if a bond is deleted during that process. But it seems you are seeing a different issue.

Can you debug and see where exactly the BT_SECURITY_ERR_UNSPECIFIED comes from? It is not much used, so a simple way to do it could be to set a breakpoint on all lines with "return BT_SECURITY_ERR_UNSPECIFIED;" in the code.

Einar

[ziv123]

Hi Einar

well debugging is a bit tricky i have another thread open on that and some one suggested allowing local ip ports but from hat i see this is not the issue, i will elaborate on the relevant thread if i manage to solve the issue...

back to our issue .. i actually got the BT_SECURITY_ERR_UNSPECIFIED by checking with a tool on my laptop that is running the same app as my node devices, and i actually see different results for each device i am attempting to pair with.

with the tool running on my laptop i get 

i don't even get the first pairing completed callback, i get right on start

bt_smp: pairing failed (peer reason 0xc) , followed by pairing_failed callback with error  BT_SECURITY_ERR_AUTH_FAIL

with one type of node (ble 4.2) 

i get the callback for pairing completed followed by the ".security_changed" callback with status 

BT_SECURITY_L2. which looks like it actually working, though i did not see the first ".security_changed" callback which i usually see.

and another node with (ble 5.0) and i think the ble device is actually nrf52840

i get 'pairing_completed' call back followed by the initial error i posted (seems the extra config did not solve the issue ) -> bt_smp: pairing failed (peer reason 0x3) , followed by the ".security_changed" callback giving error  BT_SECURITY_ERR_AUTH_REQUIREMENT. 

just to be clear i do not try to connect with all of them at the same time, with each device i did several pairing attempts without the noise of other devices and those were the results  

regarding the debug the one time it did run i did not get to the break point on the BT_SECURITY_ERR_UNSPECIFIED, which is reasonable since we got different types of errors

any ideas ? 

do i see different results cause of different ble stacks ? or there is something else

Einar Thorsrud said:

No, there has not been significant changes on this part. But this is a common issue that we often see when testing

i will point again that before migrating to v2.7.0 and 2.8.0 we did not have an issue with pairing to each one of those node types. 

hope to read you soon 

best regards

Ziv 

[Einar Thorsrud]

Hi Ziv,

I understand that this issue appeared after migrating to v2.8.0, but I am not ablet o see any changes that obviously explan this. It is interesting that you get different failures with didfferent error codes. Does it depend on the peer device, or does it also vary with the same peer device? Or is there another pattern here?  Are you able to share logs and sniffer traces for some of the specific error codes, so that we can understand more about what happened?

[ziv123]

Einar Thorsrud said:

or does it also vary with the same peer device

each peer device give the same type of error all the time.. the difference is between different peer devices

[Einar Thorsrud]

I see. Would it be possible to make sniffer traces of each case so that we can see what happens on air? It could also be interesting to compare those with traces from 2.7 so that we can see what has changed (if any). Hopefully this can point to where to look next.