Nordic connect application does not always trigger pairing flow when reading out secure characteristic

[doozMen]

Using the NRF connect app we can simulate the problem we have in our app Cowboy. Some customers cannot pair with the bike that uses the nRF52840. We have secure and non secure characteristics. Normally to trigger the pairing and entering the static pairing key we read out a secure characteristic. Using the NRF connect app we can do this with most of the products only some respond with authentication failed. 

So why does this not trigger the pairing again? 

 

The software versions that we are using is

• SDK 17.0.2
• Soft device S140 7.2.0

Workaround is that when we are stuck in this state the soft device keeps responding that authentication is needed when reading out a secure characteristic but does not trigger the pairing flow on the OS. We are however able to do a DFU update as that is not secured, or better secured different. After the DFU update the device seams to have been reset and the pairing is triggered correctly on the OS when reading out a secure characteristic.

Could this be a bug in the soft device? It should recover from the authentication needed by forcing the OS to start the pairing flow no? 

Conclusion

This happens in the Nordic connect application on both iOS and Android so we are now implementing a reset on a timeout if we are stuck in this state. But could you investigate why this is occurring?

[Simonr]

Hi

Do these failing products have other "secure characteristics" or services than the succeeding ones? How do you set up the specific characteristics to trig the pairing procedure? When the peer sends an ATT read request the SoftDevice will generate a BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST to the application. You'll then have to set a flag at BLE_GAP_EVT_AUTH_STATUS to find out if the connection procedure results in a LE secure connection or not (check if auth_status.lesc is set or not). Since the authentication fails with a GATT AUTH FAIL I'm guessing this is not handled correctly in this specific application.

Can you try going to "DEBUG" in the nRFConnect app instead of "INFO" (bottom left) to see if we can get some more information there. Alternatively I think I would need a sniffer trace so we can see what's going on over the air to see what's missing. Preferablytwo sniffer traces (one where this procedure succeeds and one where it fails). If you don't have a dedicated sniffer device you can use the nRFSniffer, Wireshark, and an nRF52 DK.

Best regards,

Simon

[doozMen]

Could you help us with how to put the nrf connect app in debug? Should it be in the setting tab of the NRF connect app?

We found this in the log setting

 

Is that what you mean? Thanks