LESC "Just Works" Reconnection Issues

RE: LESC "Just Works" Reconnection Issues

ovrebekk — Thu, 03 Feb 2022 14:36:32 GMT

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

RE: LESC "Just Works" Reconnection Issues

swlnk — Thu, 03 Feb 2022 02:43:18 GMT

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!

RE: LESC "Just Works" Reconnection Issues

ovrebekk — Tue, 18 Jan 2022 11:28:13 GMT

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

RE: LESC "Just Works" Reconnection Issues

swlnk — Sat, 08 Jan 2022 00:49:28 GMT

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.

RE: LESC "Just Works" Reconnection Issues

ovrebekk — Fri, 03 Dec 2021 12:15:30 GMT

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

RE: LESC "Just Works" Reconnection Issues

Tom Jimenez — Wed, 01 Dec 2021 20:10:42 GMT

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

RE: LESC "Just Works" Reconnection Issues

ovrebekk — Wed, 01 Dec 2021 09:59:42 GMT

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

RE: LESC "Just Works" Reconnection Issues

Tom Jimenez — Tue, 30 Nov 2021 23:59:13 GMT

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

RE: LESC "Just Works" Reconnection Issues

ovrebekk — Tue, 30 Nov 2021 19:56:46 GMT

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