• State Not Answered
  • Replies 29 replies
  • Subscribers 58 subscribers
  • Views 905 views
  • Users 0 members are here
Attachments (7) Download All
Nordic Case Info
  • Case ID: 315476
Options
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

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)
    

  • 0

    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

  • 0 in reply to Hung Bui

      Thank you for your reply. My bad. Yes, the error means BT_HCI_ERR_INSUFFICIENT_SECURITY. I will fix it in the question. I will also collect a sniffer trace soon. 

  • 0 in reply to 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

  • 0 in reply to muli

    Hi Paul, 
    It's often normal to receive "Insufficient Authentication" when at the initial phase of the connection when the peers doing service discovery and try to read/write the characteristics. 
    After receiving that the peer should start pairing process and try the read/write again.

    There is an issue with the provided sniffer trace is that it didn't capture all packets, you can find in the trace that odd events were not captured. We see a Pairing Response without a Pairing Request. 

    I'm not sure why the sniffer missing packages like that. Could you please try to capture the trace again ? This time please place the sniffer close to the 2 devices. 

Related