CC2652R: simple_peripheral from SDK 2_30_00_34 fails to pair with Windows 10

Hi Tobias,

That website that you linked your sniffer logs is blocked by our network. Can you please attach the file by going to the reply box and clicking insert code, attach files and more to provide a link for us to download the logs? We will need some time to examine the logs.

Hi Evan,

thanks for your reply.

I have zipped and attached the Frontline cfa.

Regards.......tobias

simplePeripheral_2_30_00_34__pairingFailed--attempt2.zip

Hi Tobias,

Are you using the out of box example or have you made any changes to your simple peripheral example?

Hi Jessica,

I took the SDK and compiled the example using IAR Workbench. No change to the source code or settings at all.

We tested with Lubuntu and BlueZ 5.48, too: all working, no problem. It seems that the issue appears only with Windows 10.

...and I made two observations:

Windows sets the AuthReq CT2 h7 support bit (pls see attached picture). Could this lead into problems?

And when pairing fails, CC2652R 's reply contained the Public Pairing Debug Keys.

The Frontline capture doesn't show the pairing key exchange because DLE can be active at that point and Frontline BPA can't capture DLE. But somtimes - depending on when DLE is activated - the pairing keys are exchanged with link layer fragmented packets which could be captured and decoded. And to be 100% sure we captured with an Ellisys Bluetooth Tracker with DLE support, too :)

So I can say for sure that the Pairing Public Keys are exchanged always right before the master replies with "Pairing Failed", "Invalid Parameters" (although my previous Frontline file doesn't show the pairing key exchange).

What do you think, could it be that the master replies with "Pairing Failed" because the CC2652R is sending the Public Pairing Debug Keys?

Cheers......tobias

Hi Tobias,

Can you send us your Ellisys files? As explained in our BLE5-Stack User's Guide, the device uses a Public Pairing Debug Key so you can decipher over-the-air sniffer logs with LE Secure Connections enabled so that should not be the cause. The AuthReq CT2 bit is new for BLE5 which is why it was reserved in the BLE4.2 Core Spec. We have been able to pair with other devices that set CT2 but we can look into this further with the Ellisys logs. I would like to point out that we can give general support on this, but I would recommend also contacting Microsoft with this issue in case they have had similar issues with their BLE stack.

Hi Jessica,

what is your experience with Windows 10 and latest BT5 SDK for CC2652R?

The Ellisys file is attached. The Access Address of interest is 0xEE1C7885 and the error appears in CE #10. The master's BD address is 00:28:F8:5F:F1:21.

20181108-tibt5stack_windows_01.zip

Hi Tobias,

I am still looking into this and examining your Ellisys file. I have not heard any specific reports yet about Windows 10 and the latest BT5 SDK for CC2652R. In the mean time, can you tell me what version of BT is running on your Windows 10 computer?

Hi Tobias,

Can you give some steps for me to reproduce this? What are you using on Windows 10 to connect to the CC2652R? Are you using a BLE Scanner app?

Hi Jessica,

sorry, I was ooo...

Windows 10 has HCI version 8.256 and LMP version 8.256 what is Bluetooth 4.2 as far as I know.

I'm using the Windows 10 system control "Bluetooth and other devices" to pair the SimplePeripheral.

Please find screenshot below: 1) enable BT, 2) add new device 3) when "SimplePeripheral" appears, click it

Thanks......tobias

Hi Tobias,

Sorry for the delayed response, I was ooo now. One of my teammates told me that they were able to reproduce this issue with you. We will work on finding the root cause of this.

Hi Tobias,

Any updates on this?

Hi Jessica,

sorry for my delayed response.

I made several more tests with different SDKs, chips and Windows versions.

All tests show the same results like we have seen together with Sean in Oslo.

Windows 10 1803 disconnects if no BLE service is used - this is right. This is valid for 1703, too, but not folder older versions like 1507.

These older versions of Windows 10 keep the BLE connection even when no BLE service is used.

The second difference is the SC_HOST_DEBUG feature/define.

1. If SC_HOST_DEBUG is enable in stack configuration, it won't be possible to pair with any version of Windows 10 - not with 1803, not with 1703 and not with 1507.

2. If SC_HOST_DEBUG is removed/deactivated, it will be able to pair with any version Windows. Depending on the version of Windows 10, the connection will be terminated or not after several seconds.

This behaviour of SC_HOST_DEBUG is the same for CC2640R2 SDK 2.30.00.28 with BT4.2 and BT5 as well as for CC2642/CC2652 for SDKs 2.10.00.44 and SDK 2.30.00.34.

Please find attached Ellisys files for different SDKs each with and without SC_HOST_DEBUG.

Sean mentioned in Oslo that the stack's behaviour is different if SC_HOST_DEBUG is used. Maybe this different implementation causes problems...?

Cheers......tobias

cc2652r1_bt5-secure-conn_debug-keys_sdk_2_10_00_44.zip

cc2652r1_bt5-secure-conn_debug-keys_sdk_2_10_00_44--attempt2.zip

cc2652r1_bt5-secure-conn_debug-keys_sdk_2_30_00_34.zip

cc2652r1_bt5-secure-conn_sdk_2_10_00_44.zip

cc2652r1_bt5-secure-conn_sdk_2_30_00_34.zip

And, as always feel free to reach out for more questions if needed to Sean, Jessica or I.

Hi Evan,

#1 is not a thing. When starting the investigation on SC_HOST_DEBUG, it was a little bit hiding what was going on actually. But at the end it does not matter.

But we don't think that #2 comes from Windows.
My first thought was that Windows detects the debug keys and then rejects them for security reasons. Therefore I changed the debugs key (it is possible to do in hex file as well as in gapbondmgr.c) so that Windows doesn't see the debug keys anymore and therefore can't reject them.
But even with these non debug keys, the identical problem appears.

There are several code blocks which the preprocessor define SC_HOST_DEBUG enables/disables.
The internal flow and processing of the stack could be different when no ECC keys are generated compared to the case when new ECC keys are generated.
Couldn't it be that this difference causes the pairing problems?

Hi Evan,

I made an additional test with CC2652R1 and SDK 2.30.00.34 with a slightly modified SimplePeripheral example.

SC_HOST_DEBUG was NOT(!) defined.

The following code was added to SimplePeripheral.c:

static gapBondEccKeys_t my_gapBond_eccKeys =
{
  { 0x7B, 0x21, 0xDF, 0x4A, 0x51, 0x3F, 0x10, 0xA2, 0xEB, 0x13, 0x29, 0x73,
    0x8B, 0x22, 0x8F, 0x11, 0xD0, 0x2E, 0x1A, 0x7B, 0xB4, 0x32, 0xE2, 0x2F,
    0x4C, 0xBE, 0x97, 0xE2, 0xD2, 0x03, 0xA0, 0x20
  },

  { 0x36, 0x9D, 0x35, 0x7E, 0x46, 0x51, 0x13, 0x2C, 0x0B, 0x2D, 0xF4, 0xFC,
    0xBF, 0x12, 0x3C, 0xDD, 0xA6, 0xB8, 0x99, 0x58, 0x99, 0x57, 0x42, 0xEB,
    0x38, 0x13, 0x12, 0xA3, 0xD4, 0xF6, 0x49, 0x3F
  },

  {
    0x11, 0x91, 0x34, 0xEF, 0x19, 0xA5, 0xE9, 0xE9, 0xF7, 0x85, 0x2C, 0x5E,
    0xC2, 0x45, 0x63, 0x72, 0x52, 0x14, 0x5F, 0x5F, 0xBA, 0x2A, 0x32, 0x63,
    0x6D, 0xEB, 0x2A, 0x15, 0x49, 0x3C, 0x80, 0xFC
  }
};

And used it in 

SimplePeripheral_init()

GAPBondMgr_SetParameter(GAPBOND_ECC_KEYS, sizeof(gapBondEccKeys_t), &my_gapBond_eccKeys);

to use fixed keys that are different to the debug keys.

The Frontline air trace shows exactly the keys that I have placed in C code so  GAPBondMgr_SetParameter() is working fine.

The issue is the same. Pairing with Windows is not possible.

I didn't have the Ellisys next to me so I had to use the Frontline. Hope you can open it.

For me, it looks like an issue in CC26xx stack and not in Windows.

cc26x2r1_2_30_00_34__without-SC_HOST_DEBUG__customized-ECC-keys.zip

Hey Tobias,

I do agree, we need to look into this. I will do my best to look into this early next week and provide a response by end of the week, but with the holidays, we are limited in staff some so there is a chance it could bleed over into the holidays. Do you have a strict timeline?

Hi Evan,

there is no strict timeline and this topic is not a show-stopper.
We're waiting for the new samples with the new ROM and then we want to finish the port of the first application from CC2640R2F in Q1/2019.

Thanks for the update. I wanted to quickly update you, with the holidays we were short staffed and support has slowed. I will look into this ASAP though, but may not be until after the holidays. Happy holidays!