1st connection is bonded authenticated encrypted link, but 2nd connection becomes not bonded unencrypted link

RE: 1st connection is bonded authenticated encrypted link, but 2nd connection becomes not bonded unencrypted link

Einar Thorsrud — Mon, 15 Aug 2022 10:39:47 GMT

No, you are not. Your main loop in the zip you uploaded looks like this:

    for (;;)
    {
 
        c = SEGGER_RTT_WaitKey(); // will block until data is available
	if(c == 'r') {
		SEGGER_RTT_WriteString(0, "Resetting..\n");
		nrf_delay_ms(1000);
//		sd_nvic_SystemReset();
	}
        else {

        }
        char acIn[12];
        unsigned NumBytes = sizeof(acIn);
        NumBytes = SEGGER_RTT_Read(0, &acIn[0], NumBytes);
        acIn[NumBytes]=0;
        SEGGER_RTT_WriteString(0, "Get ");
        SEGGER_RTT_WriteString(0, acIn);

        idle_state_handle();
    }

This is not in the example, and this is why it is failing as I have explained before.

RE: 1st connection is bonded authenticated encrypted link, but 2nd connection becomes not bonded unencrypted link

snowuyl — Mon, 15 Aug 2022 09:13:57 GMT

devzone.nordicsemi.com/.../6404.ble_5F00_app_5F00_ancs_5F00_c.zip

RE: 1st connection is bonded authenticated encrypted link, but 2nd connection becomes not bonded unencrypted link

snowuyl — Mon, 15 Aug 2022 09:12:03 GMT

I am using unmodified ble_app_ancs_c example now. Please refer to the attached file.

RE: 1st connection is bonded authenticated encrypted link, but 2nd connection becomes not bonded unencrypted link

Einar Thorsrud — Mon, 15 Aug 2022 09:08:46 GMT

Are you testing with an unmodified example now, or are you still testing with your flawed project? Please clarify this. If you are testing with that, BLE_GAP_SEC_STATUS_TIMEOUT is expected. That is because the main loop does not run, so the app scheduler does not run. And that way, the LESC crypto operations are never run and the operation times out.

RE: 1st connection is bonded authenticated encrypted link, but 2nd connection becomes not bonded unencrypted link

snowuyl — Mon, 15 Aug 2022 08:59:06 GMT

devzone.nordicsemi.com/.../nRF_5F00_Connect_5F00_ANCS_5F00_pairing_5F00_BLE_5F00_GAP_5F00_SEC_5F00_STATUS_5F00_TIMEOUT.txt

RE: 1st connection is bonded authenticated encrypted link, but 2nd connection becomes not bonded unencrypted link

snowuyl — Mon, 15 Aug 2022 08:58:26 GMT

devzone.nordicsemi.com/.../ANCS_5F00_pairing_5F00_BLE_5F00_GAP_5F00_SEC_5F00_STATUS_5F00_TIMEOUT.mp4

RE: 1st connection is bonded authenticated encrypted link, but 2nd connection becomes not bonded unencrypted link

snowuyl — Mon, 15 Aug 2022 08:58:07 GMT

I click "Close" after the operation finishes this time. But the following error occurred.

Authentication failed with status BLE_GAP_SEC_STATUS_TIMEOUT

RE: 1st connection is bonded authenticated encrypted link, but 2nd connection becomes not bonded unencrypted link

Einar Thorsrud — Mon, 15 Aug 2022 08:25:58 GMT

Hi,

A few observations.

This is not from the unmodified example, but your code modified code. Can you try an unmodified example first, so that you know that how you do things with nRF Connect for Desktop is correct? Please do this to limit the number of unknowns at a singe time.
The procedure you use from nRF Connect is correct, with one important exception. After clicking the "Pair" button you click "Close" before the operation finishes. Please wait until you see the pairing text go green like this: . That means the operation has completed (alternatively you will see an error).
After you have tested with the unmodified example, fix you project like I explained in before the weekend. The code you have uploaded here will not work, and pairing will never succeed, as explained then (because you are blocking in your main loop).

RE: 1st connection is bonded authenticated encrypted link, but 2nd connection becomes not bonded unencrypted link

snowuyl — Mon, 15 Aug 2022 08:04:22 GMT

devzone.nordicsemi.com/.../6472.ble_5F00_app_5F00_ancs_5F00_c.zip

RE: 1st connection is bonded authenticated encrypted link, but 2nd connection becomes not bonded unencrypted link

snowuyl — Mon, 15 Aug 2022 08:02:14 GMT

devzone.nordicsemi.com/.../nRF52832_5F00_ANCS_5F00_pairing.txt devzone.nordicsemi.com/.../nRF_5F00_Connect_5F00_ANCS_5F00_pairing.txt

RE: 1st connection is bonded authenticated encrypted link, but 2nd connection becomes not bonded unencrypted link

snowuyl — Mon, 15 Aug 2022 08:01:10 GMT

devzone.nordicsemi.com/.../ANCS_5F00_pairing.mp4

RE: 1st connection is bonded authenticated encrypted link, but 2nd connection becomes not bonded unencrypted link

Einar Thorsrud — Mon, 15 Aug 2022 07:03:20 GMT

The ble_app_ancs_c supports bonding out of the box, so if you are using an unmodified version of that, you should be good.''

Can you do this?

Ensure that you are testing with an unmodified ble_app_ancs_c. If in doubts, program a pre-built hex file from <SDK>\examples\ble_peripheral\ble_app_ancs_c\hex\
Use nRF Connect to connect and initiate pairing. As this should just work I am having problems understanding what you are doing, I suggest making a screen recording showing exactly how you do it.
Please click "OPEN LOG FILE" in the lower bar and upload the complete log here (use Insert - Insert image/video/file). Also, check the log on the nRF side and upload here. That should hopefully tell us more.

RE: 1st connection is bonded authenticated encrypted link, but 2nd connection becomes not bonded unencrypted link

snowuyl — Fri, 12 Aug 2022 13:54:00 GMT

Yes, I have initiated pairing from nRF Connect. But I don't know why nRF Connect doesn't pop up window for me to enter passkey. I am using ble_app_ancs_c example now, do I need to change firmware for encryption link testing?

RE: 1st connection is bonded authenticated encrypted link, but 2nd connection becomes not bonded unencrypted link

Einar Thorsrud — Fri, 12 Aug 2022 13:06:16 GMT

Did you initiate pairing here? I do not see that from the log? And did you do the fixes to your firmware that I described in my previous post, ensuring that your main loop is not blocked? With that this should work and does on my end.

RE: 1st connection is bonded authenticated encrypted link, but 2nd connection becomes not bonded unencrypted link

snowuyl — Fri, 12 Aug 2022 01:35:26 GMT

RE: 1st connection is bonded authenticated encrypted link, but 2nd connection becomes not bonded unencrypted link

snowuyl — Fri, 12 Aug 2022 01:34:31 GMT

I am using nRF Connect v3.0.1. And I check "Enable LE Secure Connection" and "Performing bonding". And then I click But when I click "Pair ...". But nRF Connect doesn't show window for me to enter paskey and still shows "Not bonded, Unencrypted link". Do I need to check other options?

The following is log messages of nRF52832 device with ble_app_ancs_c example.

00> BLE_ADV_EVT_WHITELIST_REQUEST
00> BLE_ADV_EVT_FAST
00> Hello World!..

RE: 1st connection is bonded authenticated encrypted link, but 2nd connection becomes not bonded unencrypted link

Einar Thorsrud — Thu, 11 Aug 2022 11:09:10 GMT

Hi,

It depends a bit on what you mean. Do you want to only allow already bonded peers to connect? If so, advertising with whitelisting is what you want, and in that case you add the bonded peer(s) to the whitelist, an ignore connections from any non-whitelisted device. This is commonly done, and you can see an example of this in the ANCS example that you are using (search for "whitelist").

If you on the other hand want to allow any device to connect, but disconnect if the link is not encrypted there is no standard way to do this. You could achieve it by for instance starting a timer when you get the BLE_GAP_EVT_CONNECTED event, and stop the timer if you get the PM_EVT_CONN_SEC_SUCCEEDED event. If not, and the timer runs out, disconnect.

In any case though, you can configure security restrictions on each characteristic to prevent a peer from accessing them without having the right level of security (for instance minimum just works legacy pairing, or minimum LESC with authentication), etc.

RE: 1st connection is bonded authenticated encrypted link, but 2nd connection becomes not bonded unencrypted link

snowuyl — Thu, 11 Aug 2022 10:12:04 GMT

Thanks for your reply! I have another question that is how can I modify nRF52832 firmware to reject unencrypted link connecting?

RE: 1st connection is bonded authenticated encrypted link, but 2nd connection becomes not bonded unencrypted link

Einar Thorsrud — Thu, 11 Aug 2022 09:43:15 GMT

It does not bond automatically with nRF Connect by default. First connect, like you did and then:

Click the gears icon on the device
Click "Pair..."
Check the "Bonding" checkbox
Click the "Pair" button

Now the devices are bonded.

If you now disconnect and reconnect again the link will be automatically encrypted as the devices was bonded from before.

(You can also change the nRF Connect configuration by clicking the gears icon on the device close to the right, which is the one used for connectivity. There select "Security parameters..." and check the "Perform bonding" box. This is used by default if the peripheral request security, which is the case here, and then bonding will be automatic".)

Both of the above procedures works with any Bluetooth LE device that supports bonding, like for instance the ANCS example in the SDK. However, if you look at the log from nRF while pairing/bonding you get a timeout, and that is because of your main loop where you wait for RTT etc, so your idle state handler with the here important app_sched_execute() does not run. So I fixed it simply by removing everything in your main loop except for the call to idle_state_handle().

In a nutshell, the root cause of the issue you are seeing is that you block in your main loop, preventing the app scheduler from running.

RE: 1st connection is bonded authenticated encrypted link, but 2nd connection becomes not bonded unencrypted link

snowuyl — Thu, 11 Aug 2022 09:08:14 GMT

devzone.nordicsemi.com/.../ble_5F00_app_5F00_ancs_5F00_c.rar

RE: 1st connection is bonded authenticated encrypted link, but 2nd connection becomes not bonded unencrypted link

snowuyl — Thu, 11 Aug 2022 09:06:55 GMT

RE: 1st connection is bonded authenticated encrypted link, but 2nd connection becomes not bonded unencrypted link

snowuyl — Thu, 11 Aug 2022 09:06:31 GMT

I test ble_app_ancs_c example. But nRF Connect shows "Not bonded, Unencrypted link". But what I need to do is encrypted link.

RE: 1st connection is bonded authenticated encrypted link, but 2nd connection becomes not bonded unencrypted link

Einar Thorsrud — Wed, 10 Aug 2022 08:53:15 GMT

[quote user="snowuyl"]

Do you mean this example?

nRF5_SDK_16\examples\ble_peripheral\ble_app_ancs_c

[/quote]

Yes (though any BLE peripheral example that use bonding should do).

[quote user="snowuyl"]Beside I can't see disconnect button on nRF Connect, which method do you suggest to disconnect from nRF Connect?[/quote]

Click on the gears icon on the device, and then select disconnect:

RE: 1st connection is bonded authenticated encrypted link, but 2nd connection becomes not bonded unencrypted link

snowuyl — Wed, 10 Aug 2022 08:46:51 GMT

Do you mean this example?

nRF5_SDK_16\examples\ble_peripheral\ble_app_ancs_c

Beside I can't see disconnect button on nRF Connect, which method do you suggest to disconnect from nRF Connect?

RE: 1st connection is bonded authenticated encrypted link, but 2nd connection becomes not bonded unencrypted link

Einar Thorsrud — Wed, 10 Aug 2022 08:39:08 GMT

Hi,

You can refer to for instance the ANCS example in SDK 16.0.0, where this should also work. Does it on your end? If not, did you by any chance restart nRF Connect Bluetooth or click "Delete Bond Information"? (Based on the log of the second screenshot it does not look like the device is known for some reason, even though I see it has the same address so it should be seen as the same device.)