Part Number: CC2540
we still have several CC2540 devices active. Since latest Windows 1903 update microsoft blocks devices using a known LTK see:
It apreas our devices are affected.
Bonding = true
MITM = true
PassKey = "XXXXX"
To be more precise:
- we are using Stack 18.104.22.168
- not all devices are affected - it seems it is mainly a 2016 production line (but not all devices) - are there any known problems about those chips?
- the error occurs when we first pair one device - then a second - we can see the error in the windows event log and seconds device wont get paired
- if we do it the other way round we also can pair one device and we get an error on the second
- other devices from same production line still work fine - it might be MAC address related? Is the LTK based on the MAC?
As stated here:
"You can find the following sentence in our software developer's guide, section 5: "Most of the Bluetooth low energy protocol stack is object code in a single library file (TI does not provide the protocol stack source code as a matter of policy). A developer must understand the functionality of the various protocol stack layers and how they interact with the application and profiles. This section explains these layers." TI's BLE STACK takes care of the LTK generation and make sure the distribution follows the Bluetooth Specification. Users do not need to worry about the LTK generation while using pairing and bonding feature in our BLE STACK."
It seems we can't affect LTK creation - even this is not for the CC254x i assume it will be te same?
Still the question is - how can we fix that?
Help is needed urgent!
Customers are angry & devcies don't work anymore!
Assigning one of the experts to look into the details asap. Stay tuned.
NB! The user J Lindh is out of office until September 23rd.
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to J Lindh:
thanks for your help - meanwhile we also spottet a 2017 production line in wich even more sensors are affected!
So devices produced in 2016 seem to have same LTK sometimes - and devices produced in 2017 have same LTKs.
Interesting enough different procution line don't block eachother.
So for the devices having that problem we are seeing:
- Pair 1 device 2016 - works
- Pair 2 devices 2016 - fails - 1 gets paired - 2nd will fail (always the first pairing attempt is successful)
- Pair 1 device 2017 - works
- Pair 2 devices 2017 - fails - 1 gets paired - 2nd will fail (always the first pairing attempt is successful)
- Pair 1 device 2016 & 1 device 2017 - works !!!
Windows blocks a device if there is already another paired device with same key since update 1903.
We tested this with 18 devices from 2017 prodcution line - 11 seem to create same LTK (can't be paired together anymore) - 7 devices still work as expected
Further more we can rule out that the problem is receiver related since we tested this with two BCM20702 chipset devices & 1 CSR device.
Also it is not PC dependent - we could reproduce the problem with the same affected sensors on 3 PCs having latest 1903 udpate.
We also investigated the problem with BTool & an Nordic receiver - were we COULD NOT see that the devices produce the same LTK - still in windows environment we can't pair them anymore.
Next step here is sniffing the pairing process...
Even the above mentioned microsoft article tells windows will create error 22 we get error 35!
Protocolname: SystemSource: BTHUSBID: 35Das Gerät (xx:xx:xx:xx:xx:xx) versucht, einen Identitätsauflösungsschlüssel zu verteilen, der bereits von einem gekoppelten Gerät verwendet wird. Das Pairing wurde abgelehnt. Wenn Sie beabsichtigen, mit diesem Gerät zu koppeln, müssen Sie möglicherweise zuerst die vorhandenen Pairing-Informationen löschen.
(sry german pc)
So the problem is not exacly the described one (default key) but more that microsoft also added a new block for devices wich create same LTK & that seems to happen.
If you need the HW IDs for investigation please PM me.
In reply to Frederik:
According to my translation the error message is something like:
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.
1) Are you using bonding?
2) If you are - is the bonding information erased on any of the devices before the second (failing) pairing attempt? (Seems like this could happen is if bonding information is erased on one device but not the other)
3) Do you use MITM, what are the I/O capabilities on the devices (what kind of pairing is used)?
4) When you say 2016 production line and 2017 production line, are all the devices using the same software (BLE Stack 22.214.171.124)?
Cheers, Marie H.
In reply to Marie H:
the translation doesn't sound too bad - you might be right that windows is complaining about the same IRKs while pairing a 2nd device not LTKs.
"The probability that two devices will have the same IRK and generate the same random number is low, but not absolute."
If that is the problem - how could we fix it? Im not aware of any special privacy functions in our FW? Our devcies are connectable via public address.
2) We dont erase any bonding information on the sensor manualy
Our Firmware is fully based on SimpleBlePeripheral - nothing aditional - BondMgrCBs = NULL
Yes - latest FW for all product lines is based on 126.96.36.199 - but I even tested with an old 1.4.0... stack FW -> same results
Yes I can confirm the IRK is the same for some devices!
I just tested 3 devices from the 11 "non working ones" & 1 from the "working ones" with BTool
The 3 devices all have the same IRK !
The wokring one has another IRK !
Sorry I wasn't aware of the IRK yet since we don't use private address / privacy functions.
So it seems windows blocks devices with same IRK from 1903 update !
In It is stated the IRK will be randomly generated if it is set all 0s.... we don't explicitly set this value.
1) What would happen if i set this to 0 at startup? Will it be random at each startup -> Change with each startup?
2) Woudl 1) be a problem for already bonded devices (since it would change again AFTER the central saved that key already)? (Would it be spec conform?)
3) How is the current process for IRK generation if we dont set this up explicitly ? (= our FW = SimpleBlePeripheral)
4) So why so many devices !!! 11 of 18 !!! randomly choosen devices have the same IRK? Is it a bug? According to the source mentioned above it should rarely happen... [We also tried some devices form 2016 series - there it happened to 3 of 7 devices - so I guess this happens a lot]
5) How can we change the IRK generation to fix this problem?
1) The IRK is stored in NV, so it will only be set once. On startup it is read from NV. (See peripheral.c.) If you want a new IRK at startup you would have to intentionally overwrite the SNV BLE_NVID_IRK area.
2) No, since you are not using privacy the IRK isn't really being used. (I am not sure whether the spec explicitly forbids this.)
3) IRK is generated by using the RFPSRND register. You can see the document you linked (swru191), chapter 25.10 Random Number Generation.
4) Here I need to get back to you.
5) Yes, you can manually assign different IRKs to the devices.
- Alternatively, since you are not using Privacy you could try altering the Pairing response packet not to include the IRK.
- You should also manually delete all paired devices under the Bluetooth settings menu in Win10 before starting the test.
Did you figure it out?
I will close this thread due to inactivity.
I still was hopping for an answer to 4) since this seems to be the main problem & it still exists... As soon as we understand the reason we can fix it properly.
I would expect each device to have a new IRK. Are you programming his devices from an image that contains the OSAL NV image of a ‘golden’ unit that previously computed and stored it’s IRK? (This can be ruled out if you reprogram simpleBLEperipheral on the device, then use the CC debugger to check the return value from the associated NV read of the IRK and GAP DeviceInit, if the NV value is read as all FF’s. GAP DevInit should give you a “random” IRK. )
We currently dont do that but create one SuperHex by joining images. But it might be that way in older production lines. Will check an come back to you...
Thanks for the hint. Still I'm not sure since we also have devices with different keys from same production as well. So either all devices should be affected or none? Any other suggestions?
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.