ESP32 Bluetooth fails to Read Remote Extended Features when using btstack (IDFGH-12669)

[DerEchteJoghurt]

Answers checklist.

• [X] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• [X] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• [X] I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.

v5.3-dev-3225-g5a40bb8746

Espressif SoC revision.

ESP32-D0WD-V3 (revision v3.1)

Operating System used.

Linux

How did you build your project?

Command line with idf.py

If you are using Windows, please specify command line type.

None

Development Kit.

Custom Board

Power Supply used.

USB

What is the expected behavior?

When using btstack, the peripheral examples do not pair with a Google Pixel 6a on Android 14, due to the controller implementation failing to properly respond to the Read Remote Extended Feature command.

See the following issue for further details: https://github.com/bluekitchen/btstack/issues/586

What is the actual behavior?

The VHCI implementation should properly respond to the Read Remote Extended Feature command when using btstack.

Steps to reproduce.

1. Integrate the develop branch of BTstack into esp-idf.
2. Enable hci logging and 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..." and the logs show not properly responding to the Read Remote Extended Feature command (see https://github.com/bluekitchen/btstack/issues/586#issuecomment-2057401266).

Debug Logs.

See https://github.com/bluekitchen/btstack/issues/586#issuecomment-2057401266

More Information.

No response

[esp-zhp]

The ESP32 does not support BLE5.0. The Extended Features refer to BLE50 features.

[esp-zhp]

@DerEchteJoghurt If you want to use BLE5.0 features, please consider using other chips in the ESP series, such as ESP32-C2, ESP32-C3, ESP32-C6, ESP32-H2, ESP32-S3, etc.

[DerEchteJoghurt]

Thank you for the quick response, shouldn't this be represented in the Supported Commands HCI Configuration Parameter? Octet 2, Bit 6 is currently set here, which would falsely indicate that the command is supported.

[mringwal]

@zhp0406 In the log here, https://github.com/bluekitchen/btstack/issues/586#issuecomment-2057401266, the HCI Read Remote Extended Features for a BR/EDR ACL Connection is pending. If the command would not be supported by the Controller, the Controller should return a HCI Command Complete event with status UNKNOWN HCI COMMAND (0x01) or something similar.

[ESP-YTGerd]

Hi, @DerEchteJoghurt Can try with the attached new lib? in which I have made some changes and added debug info. You can replace the old lib with new lib in path controller/lib_esp32/esp32/libbtdm_app.a.  It's also suggested deleting  the old build via rm -rf build in project path before re-building your project with the new lib. libbtdm_app.zip

[DerEchteJoghurt]

Hi, @DerEchteJoghurt Can try with the attached new lib? in which I have made some changes and added debug info. You can replace the old lib with new lib in path controller/lib_esp32/esp32/libbtdm_app.a. It's also suggested deleting the old build via rm -rf build in project path before re-building your project with the new lib. libbtdm_app.zip

With the new lib, btstack receives a Read Remote Extended Features Complete (0x23) event and everything works as expected. Thanks for the quick patch!

[ESP-YTGerd]

Hi @DerEchteJoghurt If the BR/EDR secure connection doesn't need to be opened, it's advisable to disable this feature. In fact, the issue you encountered arises from enabling AES-CCM encryption. We encounter some problems when sending ACL-U packets when AES-CCM is on.

[DerEchteJoghurt]

Hi @DerEchteJoghurt If the BR/EDR secure connection doesn't need to be opened, it's advisable to disable this feature. In fact, the issue you encountered arises from enabling AES-CCM encryption. We encounter some problems when sending ACL-U packets when AES-CCM is on.

Is this issue fixed with the build you uploaded here or do you still recommend disabling secure connections?

[mringwal]

@DerEchteJoghurt Could you upload a PacketLog file with the new libbtdm_app? We can check if Secure Connections are used.

[mringwal]

If the BR/EDR secure connection doesn't need to be opened, it's advisable to disable this feature. In fact, the issue you encountered arises from enabling AES-CCM encryption. We encounter some problems when sending ACL-U packets when AES-CCM is on.

Thanks for looking into this. BR/EDR Secure Connection is an optional feature of Bluetooth Controllers. While it's not clear to me that the AES-CCM encryption is better than the one for legacy connection, it replaces a custom crypto algorithm by a modern/standard one, which is a good thing.

If the ESP32 supports BR/EDR Secure Connection, then the implementation should be improved to work in all supported configurations.

[ESP-YTGerd]

Hi @DerEchteJoghurt If the BR/EDR secure connection doesn't need to be opened, it's advisable to disable this feature. In fact, the issue you encountered arises from enabling AES-CCM encryption. We encounter some problems when sending ACL-U packets when AES-CCM is on.

Is this issue fixed with the build you uploaded here or do you still recommend disabling secure connections?

The new lib has addressed the issue you raised, but it won't be updated to the release version for now. If want to use the release version, you can temporarily disable the secure connection.

[mringwal]

@ESP-YTGerd Thanks for the clarification!

[Indastri]

Closing the issue as solved. If you encounter any more problems feel free to reopen this or create a new issue.

Cheers!

[mringwal]

Hi @Indastri Has the 'new lib' from this comment https://github.com/espressif/esp-idf/issues/13661#issuecomment-2081302134 been integrated into the latest Release(s)?

[mringwal]

Hi. According to @DerEchteJoghurt, this issue is still present on the master branch, hence it cannot be considered as resolved yet. It is resolved once the fix is in one of the release versions.

I cannot re-open this ticket. Can you re-open it, or should we create a new issue?

Thanks!

[ESP-YTGerd]

Hi, @mringwal Yes, the fix hasn't been merged into the release branch yet because we cannot fully guarantee that it will resolve the issue without introducing new problems. And we are still conducting further internal testing and evaluation.