LESC "Just Works" Reconnection Issues

[Tom Jimenez]

SDK: NCS 1.7.1.

Based on: Peripheral UART example

Central: nRF Dongle

Peripheral: nRF52832

Hi,

I am running into an issue using the "Just Works" pairing method when attempting to reconnect after successfully pairing and bonding. I modified the "Peripheral_UART" example based on the following link https://devzone.nordicsemi.com/f/nordic-q-a/77391/allow-lesc-just-works-pairing-bonding-with-nrf-connect-sdk-zephyr-after-pressing-button/336031#336031 and was successful in pairing and bonding on the initial connection. Upon reconnection, the connection is dropped, and the following output is seen using puTTy: 

E: SMP Timeout
Security failed: DE:56:61:DF:19:86 (random) level 1 err 8
Pairing failed conn: DE:56:61:DF:19:86 (random), reason 8

Reason 8 refers to "BT_SMP_ERR_UNSPECIFIED" so that doesn't give me much information.

I used an Ellisys Sniffer and I was able to see that the connection is dropped after the "LLCP Encryption Start" event when reconnecting.

Any advice would be appreciated!

Best,

Tom

[ovrebekk]

Hi Tom

Do you know if the bonding data is properly stored and recalled when you reconnect the already bonded connection?

Typically what happens after the encryption is started is that you need to reconfigure the encryption data that was stored during the bonding phase. 

I haven't tested LESC pairing in NCS myself yet, but I will check with my colleagues tomorrow if there is anything in particular to look out for. 

Best regards
Torbjørn

[Tom Jimenez]

Hello Torbjørn,

Yes, the bonding data is properly stored. 

Upon doing some more testing, the example works with an iPhone and an Android as the central. The link is correctly re-encrypted upon reconnection. 

It seems as if the nRF dongle is the cause of the issue that we have been seeing. The dongle has the latest firmware on it and we tested multiple dongles with the same result.

Best,

Tom

[ovrebekk]

Hi Tom

That is interesting. 

By 'nRF Dongle', do you mean this one?

Which application are you using on the central side to control the dongle?

Best regards
Torbjørn

[Tom Jimenez]

Hello Torbjørn,

Yes, that is the dongle that I am referring to.

I am using an unmodified firmware provided by the nRF Connect for Desktop application.

Thank you,

Tom

[ovrebekk]

Hi Tom

Thanks for the clarification. 

Would you be able to share your code with me so I can try to reproduce the problem here?

I can make the case private, if you don't want to share your code in a public ticket. 

Best regards
Torbjørn

[swlnk]

Hi Torbjørn-

I work with Tom, who asked the question above. I can see this issue using NCS v1.8.0 with the peripheral_lbs project, and it actually doesn't matter if using JustWorks or pairing with a passkey - it fails in both cases.

****************

Steps to reproduce:

-Use nRF52840 USB dongle with nRF Connect for Desktop v3.9.3, Bluetooth Low Energy app v3.0.0

-Open peripheral_lbs project (included in NCS v1.8.0) in Segger Embedded Studio, with target board as nRF52DK for nRF52832

-Under "Configure nRF Connect SDK project" window, find the "Nordic LED-Button BLE GATT service example" options and select "Enable security"

-Build and run project on nRF52 DK board, with TeraTerm running to monitor printk statements from the application

-Scan and connect to "Nordic_LBS" in nRF Connect for Desktop

-After connection, select "Pair" in menu, check "Enable LE Secure Connection pairing" and "Perform bonding", and click "Pair"

-Passkey will be required, so read passkey from the printk output in TeraTerm and enter it in nRF Connect for Desktop

-Pairing succeeds. In desktop log, it says "Security updated, mode:1, level:4", and it printk output it shows: "Pairing completed: E2:C9:26:D2:8A:4C (random), bonded: 1, Security changed: E2:C9:26:D2:8A:4C (random) level 4"

-Disconnect

-Try to reconnect in nRF Connect for Desktop. The connection immediately terminates. In the printk output it says: "Security failed: E2:C9:26:D2:8A:4C (random) level 1 err 9, Disconnected (reason 61)". In nRF Connect for Desktop it says: "Disconnected from device E7:ED:E5:26:FD:D6, reason: BLE_HCI_CONNECTION_TIMEOUT"

****************

A few notes:

-I made sure to use the "Delete bond information" option in nRF Connect for Desktop" and to complete erase the flash on the nRF52DK and reflash the board every time that I ran this test, to make sure I was starting "clean"

-If you just "Delete bond information" on the central side before reconnecting, then the connection doesn't fail. This implies that the problem is caused when the central is trying to encrypt the new link with the stored bond key

-I modified the peripheral_lbs application to no longer use a passkey (by setting the passkey_display callback to NULL), and I can still see the same issue - initial pairing with bonding works, but the re-encrpytion on subsequent connections fails

-As Tom mentioned, there's no issues if I use an iPhone or an Android phone as the central running LightBlue. In the case of the iPhone, I had to modify a characteristic to require encrpytion in order to force the iPhone to send a pairing request.

[ovrebekk]

Hi Sandeep

Sorry for the slow response, I just got back from an extended holiday. 

Thanks for the detailed description of the problem, I am now able to reproduce the problem here. 

I will discuss this with the software team and get back to you. It is possible that the bonding data is not properly stored when using the nRF Connect for Desktop BLE application. 

Best regards
Torbjørn

[swlnk]

Hello, I'm just checking to see if there's any progress here. Is there any plan for an update to nRF Connect for Desktop with this issue fixed?

We have been using the nRF Connect for Desktop BLE application as one of our main test tools during development, and I'd like to know whether we can continue to rely on it long-term.

Thank you!

[ovrebekk]

Hi Sandeep

Thanks for the reminder, and sorry for not getting back to you. 

The team confirmed that this is a limitation in the nRF Connect BLE application. 

Unfortunately they don't have any current plans to fix this, as they have a long backlog of other tasks to work on. As a short term quick fix they are planning to add a warning in the interface to inform users of the limitations in the bonding functionality. 

Best regards
Torbjørn