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)

    

[Hung Bui]

Hi Paul, 
It's quite strange the MTU exchange would have something to do with security level. 
Could you try to capture a sniffer trace so that it's more clear on why we have that error ? 
Just for clarification, could you point me to where you find that the error was BT_ATT_ERR_AUTHORIZATION?  as far as I know error 0x0e means BT_HCI_ERR_INSUFFICIENT_SECURITY

[muli]

 Hung Bui Here is a sniffer trace from the peripheral / receiver device. This sniffer didn't seem to capture packets when the connection dropped this time . I noticed an LL_TERMINTE_IND during one capture though. 

However, what is the most interesting here I believe are the packets captured during the initial connection from number 4583. There is an Insufficient Authentication error at 4606. It's looking like this is the source of the issue.

What I don't understand though is why the connection still succeeds that first time, and the BASS gets discovered by the central device. Only if the peripheral drops the connection later when it is syncing to an audio broadcast, and the central connects again, BASS discovery fails because of the insufficient security. 

Again this only happens when using either the Packetcraft or Nordic Soft device controller on the central side and not the Zephyr controller (with the exact same application)

How to possibly solve this? Thanks 

capture-peripheral-authentication-issue.pcapng

[muli]

Hi Hung Bui Yes new-capture-issue-2 shows the first connection. All is well there. To decrypt the connection with the sniffer, I believe bonding is required? Unfortunately I need to have bonding disabled as it causes other issues.  

[Hung Bui]

Hi Paul, 

Could you try capture the trace for the 2nd connection where the issue occur ? 
It's possible to use CONFIG_BT_USE_DEBUG_KEYS to set the keys to the default debug key that you can feed to Wireshark. 

[muli]

 Hung Bui Sorry for the late reply. I was out.

The problem is still ongoing. I've attached some more traces here from the receiver with CONFIG_BT_USE_DEBUG_KEYS enabled.

We can see the initial connection established from the Broadcast Assistant / Central, then the write requests and responses when the Broadcast Assistant writes to the Broadcast Audio Scan Control Point on the receiver.

The connection eventually drops, but no information really as to why. Thanks in advance. 

new-capture-26-10-2.pcapng

new-capture-26-10-4.pcapng

new-capture-26-10-3.pcapng

[Hung Bui]

Hi Paul, 

Let me describe what I can read from the traces: 

- The connection terminated after the slave stopped responding: 

The connection timed out after that. This happened on all traces. 

- The master tried to re-connect after the connection is terminated but there was no response from the slave even though the slave still advertised. 

- In some traces (4&2) the sniffer didn't capture the empty packet from the master, which is quite strange:

So in this traces, I don't see a proper re-connection or 2nd connection as described in your initial question that you received BT_HCI_ERR_INSUFFICIENT_SECURITY. 
I don't see anything suspicious in the bonding process in the  initial connection. 

Could you let me know which device was used as the central/master ? 

I assume you are using our Audio DK for both central and peripheral ? 

If you simply flash normal BLE application on the central and peripheral would they connect and hold the connection ? 
If you use a phone to connect to the peripheral, would the same issue occurs ? 

[muli]

 Hi Hung Bui 

For both the central / master and peripheral / receiver I am using the nRF5340 Audio development kits.

On the receiver there is an application running based on the applications\nrf5340_audio project part of NRF. It is modified to have the Scan Delegator functionality integrated. 

The central device has a customized application that uses the Zephyr Broadcast Assistant functionality. 

Both devices are using the Packetcraft controller v 3393. 

This disconnecting also happens when using the nRF Connect phone app for example when connected to the receiver. 

This only happens when the receiver is syncing between different broadcasts sources. i.e when the central commands it to switch broadcasts. The disconnect may happen straight away, or after it switches 10 or more times. It's always hard to predict when

It's kind of hard to test a normal BLE application on both devices as to replicate this, the receiver needs to be getting commands and to switch broadcast sources.