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

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

Kenneth — Wed, 19 Sep 2018 07:49:20 GMT

Hi,

It is very likely that the BLE analyzer will not be able decrypt any traffic when using LE secure connection.

Best regards,
Kenneth

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

edfirmware — Tue, 18 Sep 2018 19:18:13 GMT

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?

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

edfirmware — Tue, 18 Sep 2018 15:45:48 GMT

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.

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

Kenneth — Mon, 17 Sep 2018 07:19:40 GMT

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

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

edfirmware — Thu, 13 Sep 2018 21:36:23 GMT

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.

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

Kenneth — Thu, 13 Sep 2018 12:20:54 GMT

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