[ESP32] Device examples do not connect after pairing

[DerEchteJoghurt]

Describe the bug

When testing all of the device examples my Android 14 phone is always stuck on "Connecting...", after accepting the pairing, and never connects to the device.

To Reproduce

Steps to reproduce the behavior:

1. Clone the latest esp-idf and integrate develop branch of BTstack.
2. Build the hid_mouse_demo.
3. Build, flash and monitor the demo.
4. Pair to the device.
5. After pairing the phone is stuck on "Connecting...".

Expected behavior

Connecting should work without issues and the hid_mouse_demo controls a virtual mouse on the phone.

HCI Packet Logs log.pklg.zip

Environment:

• Current BTstack branch: develop
• Bluetooth Controller: ESP32-WROOM-32D
• Remote device: Google Pixel 6a with Android 14.

Additional context The bluetooth examples which are part of the esp-idf work, so this does not seem to be a hardware issue. The demo also works with my phone on a Pico W.

[mringwal]

Hallo @DerEchteJoghurt Indeed, there was a bug in the logic to handle cross-transport key derivation during pairing. The stack did reject the request to derive an LE key, which causes Android to give up on Classic as well. Please retest with the latest commit on develop.

[DerEchteJoghurt]

Hallo @DerEchteJoghurt Indeed, there was a bug in the logic to handle cross-transport key derivation during pairing. The stack did reject the request to derive an LE key, which causes Android to give up on Classic as well. Please retest with the latest commit on develop.

Hey, thanks for the quick response! After pulling the latest changes from develop I seem to be getting a lot more logs from sm.c, unfortunately my phone still isn't able to connect. I've attached the latest logs below: log.pklg.zip

[mringwal]

Weird. It is/was working with Android 14 on Pixel 7a (pretty close...). I'll attach the log from a Infineon CYW20707 (Ezurio BT-851 USB dongle).

In your log, the ESP32 responds with Command Status for Read Remote Extended Feature, but fails to actually do so. After 10 seconds, the connection fails. That looks like a bug in the ESP32 Controller. Which esp-idf version do you use? Can you try their latest version?

[DerEchteJoghurt]

Hmm, I tried using the latest release and also the latest commits from the esp-idf, but with the same result. I also tried another ESP32 board.

Something worth noting is that my boards are not official Espressif development boards, but I assumed they work the same/have the same chip on a different board. Maybe someone with access to an official ESP32-WROOM-32D/U development board can confirm this issue?

[mringwal]

This is not an issue with your specific device, it looks like some kind of race condition in the proprietary Bluetooth Controller implementation.

Workaround: if you call gap_secure_connections_enable(false), CTKD is not possible and it will probably work for you.

[DerEchteJoghurt]

This is not an issue with your specific device, it looks like some kind of race condition in the proprietary Bluetooth Controller implementation.

Ah good to know. I wonder if I can figure out a minimal example to reproduce this, so this can be reported to Espressif.

Workaround: if you call gap_secure_connections_enable(false), CTKD is not possible and it will probably work for you.

Yup, that works!

[mringwal]

It would be great if you could post an issue on the esp-idf tracker. You can directly suggest to use the hid_mouse_demo - I do the same. Here, already the standard example shows the problem. If you do, please post the link to the issue here. (I might try to reproduce, but I won't get around to that the next 3 weeks unfortunately)

[DerEchteJoghurt]

Hey, sorry for the late response. I submitted an issue to the esp-idf repo: https://github.com/espressif/esp-idf/issues/13661

[DerEchteJoghurt]

I got a response for the esp-idf issue, where they mentioned that the Read Remote Extended Feature command is not supported by the basic ESP32. I assume this should usually be covered by the SUPPORTED_HCI_COMMAND_READ_REMOTE_EXTENDED_FEATURES check.

I noticed a small mistake here: https://github.com/bluekitchen/btstack/blob/cb92fd343998b0ca7a4cb5700654429febb21b44/src/hci.c#L163 According to the Bluetooth 5.0 Core Specification, bit 5 is the Read Remote Supported Features command. This should probably X( SUPPORTED_HCI_COMMAND_READ_REMOTE_EXTENDED_FEATURES , 2, 6), since bit 6 is the Read Remote Extended Features command: This doesn't matter for the ESP32 though, since for both commands the bit is set.

To further test this I manually returned false for the check here: https://github.com/bluekitchen/btstack/blob/cb92fd343998b0ca7a4cb5700654429febb21b44/src/hci.c#L3921 Unfortunately the example still doesn't work with this, I attached the logs without Read Remote Extended Features below. log.pklg.zip

[mringwal]

Good catch. I've updated the bit positions for SUPPORTED_HCI_COMMAND_READ_REMOTE_EXTENDED_FEATURES on the develop branch.

Back to your actual issue. In the last log, without the Read Remote Extended Features command & issue, the CTKD / SM Paring looks connect. Also, the SDP queries for HID and other services look ok. If this doesn't work, but it works without the CTKD, e.g. by disabled BR/EDR Secure Connections, we can compare the logs for these two cases. Could you post that here as well for completeness?

[DerEchteJoghurt]

Using the updated libbtdm_app.a from the esp-idf issue here, btstack now properly receives the Remote Extended Features Complete event and everything works as expected!

Let me know if I should close this, or if you still want the other logs.

[mringwal]

@DerEchteJoghurt Could you check if this is fixed with the latest esp-idf release, i.e. if the fix has been integrated into their main line?

[DerEchteJoghurt]

I just tried using the latest esp-idf commit (5ca9f2a) and the the latest develop branch of btstack, but unfortunately it is still very unreliable. It takes multiple attempts to get the device to pair successfully. I have attached a log from a successful attempt (log_works.pklg) and one from one of the unsuccessful attempts (log_fail.pklg). These are both from the exact same build.

I tried using the libbtdm_app.a from the esp-idf issue again, and everything works as expected. I attached that log as log_libbtdm.pklg. I'm not sure if this fix never made it into their master branch or if this is a regression.

logs.zip

[mringwal]

Thanks. I've posted on the esp-idf issue and asked for integrating this fix into a release branch.