Unnecessary Central Address Resolution characteristic as part of the Generic Access Service breaking HID over GATT in Windows 10

[edfirmware]

We are implementing a Nordic NFR52832 using the ARM mbed ble stack that leverages the Nordic SDK using a HID over GATT profile. Windows 10 seems to have an issue with this Central Address Resolution characteristic when it tries to set things up. Upon review of the BLE SIG spec from there website no where does it require or even ask for the Central Address Resolution characteristic as part of the Generic Access Service. From looking at our BLE v4.2 analyzer as well as the LightBlue app this characteristic has been added to the Generic Access Service probably by the softdevice since I can't see where it gets created in the SDK during the gap init. 

https://www.bluetooth.com/specifications/gatt/viewer?attributeXmlFile=org.bluetooth.service.generic_access.xml

For whatever reason windows 10 has an issue with this Central Address Characteristic as noted in this issue:

https://devzone.nordicsemi.com/f/nordic-q-a/34869/how-to-use-direct-advertising-to-connect-the-central-successfully/144254

We have looked at other commercially available HID over GATT devices using a BLE v4.2 analyzer, and notice that none of those devices have a Central Address Resolution characteristic as part of the Generic Access Service. This makes sense as this is not even supposed to be in the Generic Access Service as shown the BLE SIG link above. What can we do to remove this unnecessary and technically incorrect characteristic as part of the Generic Access Service? Otherwise we are dead in the water.

[Kenneth]

Hello,

The Central Address Resolution (CAR) characteristic is mandatory for BLE central role that support privacy feature, and optional for BLE peripheral role. Our stack supports both roles, and thereby the CAR is mandatory. The characteristic is setup by the softdevice, and can't be disabled by the application.

We are aware of the issue with Windows 10, and I can confirm that a Windows release is planned this month that patches the issue. You can test this yourself by downloading the Windows insider build.

We have also done an improvement in nRF5 SDK v15.2 for directed advertisement, which will read the CAR value of the peer during bonding, to ensure we don't use private resolvable address if not supported by the peer during directed advertisement. We have verified this work with the upcoming Windows release.

Best regards,
Kenneth

[edfirmware]

This did not fix our issue with Windows 10. It is still behaving the same way. Seems to cause issues when the windows 10 driver issues a Read by Type Request for characteristics within the handle range of 7 to 9. The NRF52 responds with handles 7 & 8, but handle 9 characteristic (0x2aa6) is read as an "Unknown UUID [0x2aa6]."

Windows 10 then attempts a Read by Type Request on a characteristic with handle range 9 to 9 (the CAR). The NRF52 returns with an error response "Error Code: Attribute not found." After which no more attribute protocol requests are sent across. 

[Kenneth]

Hello,

Please specify which Windows 10 PC you are using, SDK version and SD version.

Also make sure to use the unmodified HID keyboard or HID mouse example from the SDK "as-is" on an nRF52-DK for test. 

Then please take an on-air sniffer log so we might look at.

Best regards,
Kenneth

[edfirmware]

Windows 10 Insiders Build 17758, sd 5.0 and  SDK14.2.  The Nordic mouse example works on the NRF52 with no issues. This implies the mbed BLE api that leverages the SDK14.2 is doing something different. I'm trying to look at the differences between the mbed BLE way vs the pure Nordic SDK route. I'll update with my findings just in case someone else needs the help.

[edfirmware]

Alright I think we have the culprit, but not sure it makes sense. After changing some code around in the mbed BLE API to force LE secure connections off, the Windows 10 HID over GATT driver finishes loading perfectly. Before even when we had installed the latest Windows 10 insider build, LE secure connections was on by default and the driver would load but not completely (at least from what we could see in the GATT protocol traces). Not sure why though? Does windows require LE secure connection to be off for HID over GATT profile? Or does LE secure connection hide the GATT traffic from the BLE analyzer making it seem as if not all characteristics were discovered properly?