[ESP32] Device examples do not connect after pairing about btstack HOT 11 OPEN

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.

from btstack.

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

from btstack.

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?

from btstack.

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?

from btstack.

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.

from btstack.

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!

from btstack.

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)

from btstack.

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

from btstack.

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:

To further test this I manually returned false for the check here:

from btstack.

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?

from btstack.

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.

from btstack.