BT_HCI_ERR_INSUFFICIENT_SECURITY during re-discovery

[muli]

Note. This issue only occurs if using the Nordic Soft Device controller or the Packetcraft controller. 

I am working with the nRF5340 audio development boards. 

I have a project with a central device (used as a Broadcast Assistant) and a peripheral device (used as an audio broadcast receiver). They both form an ACL connection and exchange data. 

Whenever the receiver is syncing to a broadcast source and it gets disconnected from the central for whatever reason, the central manages to re-connect to the peripheral, however the BASS discovery fails with BT_HCI_ERR_INSUFFICIENT_SECURITY. The following error is displayed : 

<wrn> bt_gatt: gatt_exchange_mtu_func: conn 0x200018c8 err 0x0e

 . 

The only way to solve this is by rebooting the receiver / peripheral. 

For both the central and receiver applications, bonding is disabled in the proj.conf as follows : 

CONFIG_BT_BONDABLE=n

In that case, I can't understand why the BASS re-discovery would fail due to a security error error.

As mentioned above. This only happens when using the Nordic Soft Device controller or the Packetcraft controller. Using the Zephyr controller, the re-discovery works fine without this security problem. 

How can there be this security issue only when using those two controllers, and by using the Zephyr controller with the exact same configuration (bonding disabled etc.) it is fine?

Below are the logs from my central application when it re-connects. Thanks in advance for any help or suggestions. 

Disconnected from device EE:0B:7C:30:59:12 (random) (reason 0x3e)
About to connect to EE:0B:7C:30:59:12
Connection pending..
Successfully connected to device EE:0B:7C:30:59:12 (random)
Now discovering..
[00:01:04.517,425] <wrn> bt_gatt: gatt_exchange_mtu_func: conn 0x200018c8 err 0x0e
[00:01:04.517,456] <dbg> bt_bap_broadcast_assistant: service_discover_func: Could not discover BASS
Error! BASS discover failed (-6)

    

[muli]

ovrebekk Thank you for the investigation and reply.

Can you please explain step 1. I'm  not sure I understand properly.

I am currently updating my app to use the latest NCS version 2.5.0. It seems that there are have been alot of structural changes to the upstream audio app since 2.4.0. Also some of the Zephyr callbacks have changed, so there is some work involved in merging this, but will let you know how it goes. 

Regards,

Paul

  

[ovrebekk]

Hi Paul

The point of step 1 is to avoid the issue of scheduling BIS and ACL concurrently by taking down the BIS broadcast every time you establish an ACL connection. A bit crude perhaps, but assuming you don't need to configure your device very often this might be acceptable, from a usability point of view. 

But if you have success with steps 2, 3 or 4 you can hopefully skip step 1 altogether, I should probably have made it the last step, not the first

Best regards
Torbjørn

[muli]

@ovrebekk Ok thanks for the clarification. I am in the process of trying these things out.

One thing I have noticed so far is that when I set 

CONFIG_BLE_ACL_CONN_INTERVAL=80

, the disconnect doesn't happen as much. It used to happen within the first 5 minutes or so. Now it can take up to 30 + minutes, but unfortunately the disconnect still happens eventually. Then of course the re-discovery fails after the reconnection as before. 

Is it worth increasing this CONFIG_BLE_ACL_CONN_INTERVAL value even further do you think?

[ovrebekk]

Hi Paul

It is interesting that just doubling the connection interval leads to such a dramatic reduction in occurrences, but in the end the problem is just being masked and not really solved. You could try with higher values if you like, such as 120 or 160, but ideally we should be able to find a solution that solves the problem completely. 

Best regards
Torbjørn