CC2652P7: Fail bond device to Windows 10

Hi,

Thank you for reaching out. To be safe, can you confirm that both devices are advertising different addresses via a sniffer log or through a BLE scanning application? As a test, could you use the public address mode on the project you are using and not modify the device's MAC address?

Best Regards,

Jan

Hi. In our project, we use public addresses (they don't change during operation) and both devices have completely different addresses.

Hi,

I believe Windows machines have certain strict requirements on the devices they allow to connect via BLE which depend on address mode, profiles present, advertising params, connection params, etc.

As a quick test, can you try setting the address mode to RPA with Public ID to see if the same behavior occurs?

Best Regards,

Jan

Hi,

I conducted experiments with another type of device addressing (replacing ADDRMODE_PUBLIC with ADDRMODE_RP_WITH_PUBLIC_ID). Indeed, the issues I described are not observed in this case. However, I would like to use a static device address. Therefore, I would still like to find an explanation for my problem.

Hi,

Understood. Thank you for clarifying. Do you have pairing enabled? If so, which pairing mode? Are you initiating pairing upon connection? If not, then can you try using that option?

Best Regards,

Jan

Hi. Sorry for the wait.

Yes, both pairing and binding are enabled. I'm attaching more detailed

settings below.

uint8_t pairMode                =    GAPBOND_PAIRING_MODE_INITIATE;

uint8_t mitm                    =    true;

uint8_t ioCap                   =    GAPBOND_IO_CAP_DISPLAY_ONLY;

uint8_t bonding                 =    true;

uint8_t secureConnection        = GAPBOND_SECURE_CONNECTION_ALLOW;

uint8_t authenPairingOnly       =    false;

uint8_t autoSyncWL              =    false;

uint8_t eccReGenPolicy          =    0;

uint8_t KeySize                 =    16;

uint8_t removeLRUBond           =    true ;

uint8_t bondFailAction          =    GAPBOND_FAIL_INITIATE_PAIRING;

uint8_t KeyDistList             =    GAPBOND_KEYDIST_MENCKEY |

GAPBOND_KEYDIST_MIDKEY | GAPBOND_KEYDIST_MSIGN | GAPBOND_KEYDIST_SENCKEY

| GAPBOND_KEYDIST_SIDKEY | GAPBOND_KEYDIST_SSIGN;

uint8_t eccDebugKeys            =    false;

uint8_t allowDebugKeys          =    true;

uint8_t eraseBondWhileInConn    =    false;

uint8_t sameIrkAction           = GAPBOND_SAME_IRK_UPDATE_BOND_REC;

Hi,

Can you try the following settings?

gapBondParams_t gapBondParams = {
    .pairMode             = GAPBOND_PAIRING_MODE_WAIT_FOR_REQ,
    .mitm                 = false,
    .ioCap                = GAPBOND_IO_CAP_NO_INPUT_NO_OUTPUT,
    .bonding              = true,
    .secureConnection     = GAPBOND_SECURE_CONNECTION_ALLOW,
    .authenPairingOnly    = false,
    .autoSyncAL           = false,
    .eccReGenPolicy       = 0,
    .KeySize              = 16,
    .removeLRUBond        = false,
    .KeyDistList          = GAPBOND_KEYDIST_CENCKEY | GAPBOND_KEYDIST_CIDKEY | GAPBOND_KEYDIST_CSIGN | GAPBOND_KEYDIST_PENCKEY | GAPBOND_KEYDIST_PIDKEY | GAPBOND_KEYDIST_PSIGN,
    .eccDebugKeys         = false,
    .eraseBondWhileInConn = false,
    .sameIrkAction        = GAPBOND_SAME_IRK_UPDATE_BOND_REC
};

Ive used these settings successfully in an HOGP demo with a Windows machine which requires pairing.

Best Regards,

Jan

Hello. I've tried your settings, but the result is the same. The first device pairs correctly with Windows 10, but when I try pairing the second device, it returns the error SMP_PAIRING_FAILED_UNSPECIFIED.

Which version of Windows 10 are you using? What else could this be related to?

Hello. We tried to establish BLE connections using the standard Windows
10 tools with our device. The results are shown below.

1. Windows 10 Home. OS version 10.0.17134 N/A Build 17134. Build
17134.1. Use VirtualBox.           [BLE WORK CORRECT]

2. Windows 10 Pro. OS version 10.0.19042 N/A Build 19042. Build
19042.1466. Just WorkStation.     [BLE WORK NOT CORRECT]

3. Windows 10 Pro. OS version 10.0.18363 N/A Build 18363. Build
18363.1256. Notebook.                 [BLE WORK NOT CORRECT]

4. Windows 10 Pro. Build 15063.0. Use VirtualBox.    [BLE WORK CORRECT]

5. Windows 10 Pro. Build 19045.5737. Workstation. [BLE WORK NOT CORRECT]

It looks like connections work correctly up until a certain version of
Windows 10. Can you confirm that?
Is there any solution for this issue (for example, on the TI BLE stack
side or a specific sequence of commands on the Windows side)?

Hi,

My apologies for the delay. This may be an issue on the Windows side if we are seeing a discrepancy in behavior based off version number alone. I think we may need to try to understand what the Windows behavior is and what they are expecting to see.

Can you post this question on the microsoft support forums to understand what may be going on?

Best Regards,

Jan

Hello, I apologize for the long silence.
I have conducted some research and have a few questions that I hope to get answers to.

1. As expected, Microsoft support is very slow, so I have not received an official response from them. However, you previously mentioned that it works correctly for you. Can you confirm that the device address type is set to ADDRMODE_PUBLIC? What version of Windows are you using? Can you confirm that it works correctly on different versions of Windows 10, as I tried to do?

2. I found a similar issue on a forum with another person. Here is the link to the discussion:
   https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/826255/cc2540-cve-2019-2102---ltk-authentication-problem
   There, the person writes that they are having issues pairing with multiple devices, just like I am. They refer to the Windows 10 event log with error 35, and I also observe this error in the log. The description of this error in the log states: "The device (xx:xx:xx:xx:xx:xx) attempts to distribute an identity resolution key that is already being used by a paired device. The pairing was rejected. If you plan to pair with this device, you may need to clear the existing pairing information first."
   I found a similar issue on the STM forum: https://community.st.com/t5/stm32-mcus-wireless/connect-multiple-identical-ble-devices-to-windows/td-p/754140
   Eventually, I found a similar issue on Microsoft: https://answers.microsoft.com/de-de/windows/forum/all/bluetooth-le-ger%C3%A4te-mit-gleichen-identity/4a7c4993-1a5f-4308-b6f7-61e4753e1ac0
   From these discussions, I infer that at some point, Windows 10 changed the connection algorithm for BLE devices. I believe that Windows 10 somehow uses the IRK as a device uniqueness identifier. Since I am using a public (static) address, according to the source code in "gap.c" within the "GAP_DeviceInit" function, the IRK parameter is equal to 0, as it is not used in this case. Consequently, I have two devices with different MAC addresses but with the same (zero) IRK. This results in a situation where I pair the first device with Windows 10, but when I try to connect the second device, Windows 10 reads the zero IRK and assumes it is the first (already paired) device, thus transmitting incorrect encryption keys.
   First, I attempted to forcibly set a different IRK when ADDRMODE_PUBLIC in the "GAP_DeviceInit" function. It seems that if the address type is set to ADDRMODE_PUBLIC but the IRK is not equal to 0, I can pair both devices simultaneously. However, this led to another problem. It appears that before broadcasting advertising messages, the TI BLE stack uses the IRK to generate the MAC address. Because the IRK is non-zero, I see my device already with a different MAC address!
   Can you confirm this behavior?
   Is it possible to somehow set the IRK when ADDRMODE_PUBLIC without affecting the device's MAC address?
   How can this issue be resolved?

Hi Nick,

No worries. My apologies on the delay:

Nick Braun said:

As expected, Microsoft support is very slow, so I have not received an official response from them. However, you previously mentioned that it works correctly for you. Can you confirm that the device address type is set to ADDRMODE_PUBLIC? What version of Windows are you using? Can you confirm that it works correctly on different versions of Windows 10, as I tried to do?

I am using Address Mode public. I have tested with Windows 10 Pro (not use which exact version) a while back and Windows 11 Pro (Version 10.0.22631 Build 22631).

Nick Braun said:

I found a similar issue on a forum with another person. Here is the link to the discussion:
https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/826255/cc2540-cve-2019-2102---ltk-authentication-problem
There, the person writes that they are having issues pairing with multiple devices, just like I am. They refer to the Windows 10 event log with error 35, and I also observe this error in the log. The description of this error in the log states: "The device (xx:xx:xx:xx:xx:xx) attempts to distribute an identity resolution key that is already being used by a paired device. The pairing was rejected. If you plan to pair with this device, you may need to clear the existing pairing information first."
I found a similar issue on the STM forum: https://community.st.com/t5/stm32-mcus-wireless/connect-multiple-identical-ble-devices-to-windows/td-p/754140
Eventually, I found a similar issue on Microsoft: https://answers.microsoft.com/de-de/windows/forum/all/bluetooth-le-ger%C3%A4te-mit-gleichen-identity/4a7c4993-1a5f-4308-b6f7-61e4753e1ac0
From these discussions, I infer that at some point, Windows 10 changed the connection algorithm for BLE devices. I believe that Windows 10 somehow uses the IRK as a device uniqueness identifier. Since I am using a public (static) address, according to the source code in "gap.c" within the "GAP_DeviceInit" function, the IRK parameter is equal to 0, as it is not used in this case. Consequently, I have two devices with different MAC addresses but with the same (zero) IRK. This results in a situation where I pair the first device with Windows 10, but when I try to connect the second device, Windows 10 reads the zero IRK and assumes it is the first (already paired) device, thus transmitting incorrect encryption keys.
First, I attempted to forcibly set a different IRK when ADDRMODE_PUBLIC in the "GAP_DeviceInit" function. It seems that if the address type is set to ADDRMODE_PUBLIC but the IRK is not equal to 0, I can pair both devices simultaneously. However, this led to another problem. It appears that before broadcasting advertising messages, the TI BLE stack uses the IRK to generate the MAC address. Because the IRK is non-zero, I see my device already with a different MAC address!
Can you confirm this behavior?
Is it possible to somehow set the IRK when ADDRMODE_PUBLIC without affecting the device's MAC address?
How can this issue be resolved?

Thank you for looking into this so thoroughly! Can you try calling GapConfig_SetParameter to configure the IRK beofre the device_init api call? I think this should allow you to configure the IRK in any way you want. You can also set the device address to whatever you want before calling the device_init call through HCI_EXT_SetBDADDR()

Best Regards,

Jan

Hi
I'm facing the exact same issue on Windows.
I'm wondering what is the solution to connect multiple BLE devices on Windows while keeping Public Address mode ?
Thanks 

Hi,

I took a look further and found the following Microsoft resources:

https://learn.microsoft.com/en-us/windows-hardware/design/component-guidelines/bluetooth

https://learn.microsoft.com/en-us/windows-hardware/design/component-guidelines/bluetooth-prepairing

https://learn.microsoft.com/en-us/windows-hardware/design/component-guidelines/bluetooth-swift-pair

I also found the following microsoft support forum threads:

https://learn.microsoft.com/en-us/answers/questions/390918/unable-to-connect-ble-device-with-ble-privacy-enab

https://learn.microsoft.com/en-us/answers/questions/229207/windows-10-bluetooth-le-stack-privacy-mode-(privat

It seems like there are some issues with different address modes on the windows side.

Has Microsoft support responded to your thread with some things to try?

Best Regards,

Jan

I made small progress on my side.

I'm using Public address, setting IRK manually using GapConfig_SetParameter(GAP_CONFIG_PARAM_IRK, customIrk) before GAP_DeviceInit() AND unchecking Peripheral IRK key distribution works on Win 10, with this settings I can connect 2 devices and communicate with them.
Unfortunately this does not work on Win 11.
To make this working on Win 11, it seems the Central IRK key distribution should be unchecked too, but doing this causes issues when connecting to iOS (device must be deleted if power cycling bluetooth on iOS occurred), otherwise the reconnection fails, while it still works on MacOS.
Any other idea to solve this issue ?

Another thing that could be done seems to switch to RPA address mode, but I found this mode erase bonding after an OAD firmware upgrade.
I read somewhere IRK keys could be retrieved and save into another NVS area, do you have some source code to achieve this ?
Thanks 

Hello,

Thank you for sharing your progress! You are able to export and import keys to re-establish pairing. We have a section in the user's guide (linked below) that discusses how to do this:

https://dev.ti.com/tirex/content/simplelink_cc13xx_cc26xx_sdk_8_30_01_01/docs/ble5stack/ble_user_guide/html/ble-stack-5.x/gapbondmngr-cc13xx_cc26xx.html#extract-bonding-information

https://dev.ti.com/tirex/content/simplelink_cc13xx_cc26xx_sdk_8_30_01_01/docs/ble5stack/ble_user_guide/html/ble-stack-5.x/gapbondmngr-cc13xx_cc26xx.html#import-bonding-information

Best Regards,

Jan