esp_hid_device bluetooth example doesn't work properly with input passkey (IDFGH-10566) #11806
Closed
3 tasks done
Assignees
Labels
Resolution: Done
Issue is done internally
Status: Done
Issue is done internally
Type: Bug
bugs in IDF
Comments
github-actions
bot
changed the title
|
This seems to be something to do with the way the controller is interrogating the GATT server. When I first connect to the device, System Report shows: But after power cycling and manually reconnecting (note that the battery level is now visible): So it seems that the GATT interrogation is failing somewhere |
|
Got it, I will check it later. |
|
I tried to collect some logs with more debugging enabled (only after the auth is complete): This is the first connection: And the second that is working: |
|
I think the issue is that the code in |
|
This seems to be to do with encryption not being enabled on the link. I can see the following error in the mac os console: |
|
I have found a workaround (or maybe even a fix), if you edit Since the HID over BLE standard requires encryption anyway, I don't see a problem with doing this. |
|
So the real solution is that both iOS and Mac require the report map characteristic and the report reference descriptor to have their permissions set as encrypted, otherwise when the initial connection occurs the device is considered not encrypted and the HID reports are not parsed and enumerated. This isn’t documented anywhere, but it is the way that they behave. The problem only appears when pairing OOB or with passkey input on the device. The battery and device info service do not need to be encrypted. On the second connection where pairing and bonding is already complete, the check is skipped because the connection is encrypted before the GATT operations. The characteristics probably should be set as encrypted anyway, as this follows the spirit of the BLE HOGP spec requiring all HID data to be transferred over an encrypted connection. |
espressif-bot
added
Status: In Progress
|
In the latest version（by commit 5727802）, we have addressed the issue by setting some characteristic properties to be encrypted. Thank you very much for reporting the issue. |
espressif-bot
added
Status: Done
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Answers checklist.
IDF version.
v5.1
Operating System used.
macOS
How did you build your project?
Command line with idf.py
If you are using Windows, please specify command line type.
None
Development Kit.
ESP32-C3-WROOM-02
Power Supply used.
External 3.3V
What is the expected behavior?
After modifying the example to accept a passkey (entered over SPI) I expect the HID device to work immediately after pairing.
What is the actual behavior?
The HID device does not work, even though pairing was successful.
Steps to reproduce.
esp_ble_passkey_reply(passkey_auth_target, true, passkey);ESP_GAP_BLE_AUTH_CMPL_EVTbeing triggered and printed to UART log. Device is listed as connected on the PC, but the eventESP_HIDD_CONNECT_EVENTis never sent to the the hidd callback and HID messages are not sent to the PCESP_HIDD_CONNECT_EVENTis now triggered and HID messages are finally able to be sentesp32-c3-pairing.zip
Debug Logs.
More Information.
I tried to connect to the device on Ubuntu 22.04 over BLE, but it doesn't even show a pairing code and just works as-is. I am also not sure why this is the case, but I think that is an ubuntu problem.
Also, for some reason the
esp_hidlibrary seems to disable MITM protection?esp-idf/components/esp_hid/src/ble_hidd.c
Line 484 in cbce221
The text was updated successfully, but these errors were encountered: