Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs

BT_HCI_ERR_INSUFFICIENT_SECURITY during re-discovery

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)
    

  •  Hi  

    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.  

  • Hi Paul, 

    I will need to check with the BLE Audio team to see if they have any idea. 
    But could you confirm what you captured with the trace is the same problem that you described in the original question of BT_HCI_ERR_INSUFFICIENT_SECURITY issue ? 


    From what I can see in the trace, it doesn't seem it hay anything to do with insufficient security and reconnection. 

  • Hi  ,

    Yes, these traces were captured during those tests. 4 nRF5340 Audio development kits were used. One for the receiver, one for the central, and two Auracast broadcasters. 

    I can't understand either how we don't see the packets when the central re-connects to the receiver and tries to re-discover with that error. This is what is going on from the central when it happens :  

    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)

  • Hi Paul, 

    I got some tips from our Audio R&D team: 

    - The application is not official support integrating scan delegator and broadcast assistant

    - We are suspecting that the ACL connection is affected by the Broadcast ISO. 

    - Could you capture the trace with Zephyr controller  ? 

    - It's suggested to capture the trace using professional sniffer (for example Ellisys) so that we can see if ACL connection is overlapped by the broadcast ISO. 

  • Hi  ,

    Do you mean to capture traces from the receiver device again, but using the Zephyr controller instead of the Packetcraft one?

    The disconnect still happens when using that controller , but oddly the re-connect and re-discovery works fine with that one.

    Or did you mean to capture traces from the commander / Broadcast Assistant device? 

    On another note, before I integrated the Scan Delegator into that audio application, I had a Nordic Uart Service (NUS) implemented there so that a commander could connect and send messages to the receiver over the NUS. It used to disconnect randomly in the exact same way if it was syncing to broadcast streams during the connection.  

    Just on observation today (for what it's worth), I flashed the receiver device with the Zephyr sample ncs\v2.5.0\zephyr\samples\bluetooth\broadcast_audio_sink .It contains a Scan Delegator.  I flashed this together with the Packetcraft controller. The disconnect never happens when using this together with my Broadcast Assistant application.  

Related