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 ovrebekk 

I've taken the latest Nordic audio application from nrf\applications\nrf5340_audio

I've made some modifications to start advertising if it's a receiver device as follows : 

bt_le_adv_start(BT_LE_ADV_CONN, ad, ARRAY_SIZE(ad), NULL,0);

and allows a connection from a central device. 

When a central is connected and the receiver is streaming broadcast audio, occasionally the connection drops and I get this error and crash :  

HL [00:01:13.699,676] <inf> bt_mgmt: Disconnected: C2:DA:2D:C3:36:C7 (random) (reason 0x08)
HL [00:01:13.699,707] <wrn> streamctrl_broadcast_sink: Unexpected/unhandled bt_mgmt event: 6
HL [00:01:13.699,707] <err> bt_mgmt_adv: No valid advertising data stored
HL [00:01:13.699,737] <err> bt_mgmt: ERR_CHK Err_code: [-2] @ line: 177
HL [00:01:13.699,737] <err> os: r0/a1:  0x00000003  r1/a2:  0x00000004  r2/a3:  0x00000003
HL [00:01:13.699,737] <err> os: r3/a4:  0x00060591 r12/ip:  0x0000000c r14/lr:  0x0006061b
HL [00:01:13.699,768] <err> os:  xpsr:  0x41100000
HL [00:01:13.699,768] <err> os: s[ 0]:  0x00000000  s[ 1]:  0x00000010  s[ 2]:  0x20017a70  s[ 3]:  0x0006fdd4
HL [00:01:13.699,768] <err> os: s[ 4]:  0x20017a78  s[ 5]:  0x00000000  s[ 6]:  0x00000000  s[ 7]:  0x00000000
HL [00:01:13.699,768] <err> os: s[ 8]:  0x00000000  s[ 9]:  0x00009903  s[10]:  0x00006d6f  s[11]:  0x200033d0
HL [00:01:13.699,798] <err> os: s[12]:  0x00000002  s[13]:  0x200033d0  s[14]:  0x00000002  s[15]:  0x20017a70
HL [00:01:13.699,798] <err> os: fpscr:  0x00000004
HL [00:01:13.699,829] <err> os: Faulting instruction address (r15/pc): 0x00009910
HL [00:01:13.699,829] <err> os: >>> ZEPHYR FATAL ERROR 3: Kernel oops on CPU 0
HL [00:01:13.699,859] <err> os: Current thread: 0x20004208 (sysworkq)
HL [00:01:13.699,859] <err> error_handler: Caught system error -- reason 3. Entering infinite loop

[ovrebekk]

Hi Paul

Thanks for the update. 

Like mentioned earlier we haven't tested the Packetcraft controller with a broadcast stream and an ACL connection concurrently, and it is quite common to see instability issues when using it outside the uses cases for which it was designed. 

I will set aside some time to test this in order to try and figure out what is going on, and if there is something that can be done to improve reliability, but unfortunately I won't be able to start this work until next week. 

I will get back to you as soon as I have some test results to share. 

Feel free to update the case if you make any new discoveries in the mean time

Best regards
Torbjørn

[muli]

Hi ovrebekk 

The thing is, the Packetcraft controller when used with the Zephyr broadcast_audio_sink, it doesn't disconnect at all when it's connected to my Broadcast Assistant. 

The disconnecting is definitely an issue in my case, but it's not in fact the main blocker for me as my Broadcast Assistant has an auto re-connect feature which re-connects successfully.

However, it fails to re-discover the BASS then due to BT_HCI_ERR_INSUFFICIENT_SECURITY.

What's frustrating is that the re-discovery only fails when using the Packetcraft controller or Soft Device controller on the Broadcast Assistant, but not when using the Zephyr controller.

I could just use the Zephyr controller in that case, but it doesn't support PAST:)

Thanks,

Paul

[muli]

I'm attaching a zip here anyways of the latest Nordic application with the ability for the receiver to connect to a central.   

nrf5340_audio.zip

[ovrebekk]

Hi Paul

Thanks for sharing the code. I will set aside some time to test it next week. 

In the mean time please have a great weekend

Best regards
Torbjørn

[ovrebekk]

Hi again

I got some input from one of the audio developers, who did some testing attempting to run broadcasting and a peripheral connection in parallel. He was able to make it work using the Packetcraft controller, but thinks it might be critical how the ACL connection is used in order for the scheduling to succeed. 

He provided the following advice: 

1. Try not to do BIS and BLE at the same time, but one at a time. In order to configure the device stop the BIS broadcast first, finish configuration, and then restart BIS.
2. Try to use fixed connection parameters (don't do connection parameter update automatically), and set ACL interval to 40ms or 80ms (should be 4 times of ISO interval). 
3. In our testing we do all the Bluetooth GAP/GATT procedures step by step, rather than running multiple in parallel using the auto procedures from Zephyr. 
   In other words we establish the connection first, in connection callback we trigger security update, in security update callback we trigger the MTU exchange, and so forth. By doing this, we can make sure all the link layer procedures occur in sequence, which is less likely to cause issues for the controller. 
4. Please run a test using the latest NCS version, there might be some more improvements there. 

Best regards
Torbjørn

[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