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,

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.

[GalBrandwine]

Hey, I've worked on the same problem. I found the issue:

the client tried to access MCUMGR BT Transport before it was authenticated.

Hence the LL dropped the connection.

Adding `CONFIG_MCUMGR_TRANSPORT_BT_PERM_RW=y` solved the issue.

Thanks.

[ziv123]

hi Einar

as suggested here the issue on the ncs side is the attempt to work with mcumgr befor pairing was completed .. though it is strange to me.. 

in what layer/protocol/service the keys should pass between 2 sides to achieve the completion of the pairing before starting to use the smp service /mcumgr ? 

if authentication must occur before working with mcumgr then, how the keys are passed ? 

hope to read you soon

best regards

Ziv

[Einar Thorsrud]

Hi Ziv,

I am not sure I understand the question. By keys I assume you mean the key related to the pairing/bonding? Secrutiy in BLE is handled by the Security Management Protocol.