Question: Utilizing mbedtls v2 within IDF v5 (IDFGH-12000)

[HamzaHajeir]

Answers checklist.

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

General issue report

Hi there,
I've a serious bug that did happen after upgrading to IDF v5, which was accompanied with upgrading mbedtls from version 2.28.3 to 3.4.0, alongwith other upgrades.

I've narrowed down the issue to either IDF 5 or mbedtls 3, therefore I want to run the test by compiling the previously working version of mbedtls and note the difference.

I've tried to make an esp-idf testbed project having mbedtls 2.28.3 as a component within a project run IDF v5.1, but failed with:

CMake Error at C:/Users/Hamza/esp/esp-idf/tools/cmake/component.cmake:381 (__component_get_property):
  __component_get_property Function invoked with incorrect arguments for
  function named: __component_get_property
Call Stack (most recent call first):
  components/mbedtls/CMakeLists.txt:225 (idf_component_get_property)

So:

• Is it possible to run mbedtls 2.28.3 to IDF v5.1?
• What tricks needed to override this issue?

Given that this is not a production code, it's just a try to narrow down the issue, therefore workarounds are permitted.

Full context: https://esp32.com/viewtopic.php?f=13&t=37946&p=126800#p126800

[AdityaHPatwardhan]

Hi @HamzaHajeir,
Thanks for the issue.
mbedtls-3.X is a major upgrade over v2.x and it introduced lot of breaking changes.
So while moving to mbedtls-3.x in IDF-v5.X we had to do a lot of changes and hence decided that we would not keep the support for mbedtls-2.X.
Currently I dont think it can be supported since only pulling the component would not work. Multiple files in IDF will have now conflict with the APIs from mbedtls-2.X as they are changed as per mbedtls-3.X.

[HamzaHajeir]

I see @AdityaHPatwardhan ,

But to understand how deep are the changes, does even WiFi security codes depend on mbedtls?

What I'm thinking is to just compile the least minimal project. If that's possible, we could further check any other hurdles.

What do you think?

[AdityaHPatwardhan]

Hi @HamzaHajeir Please see this commit for the changes that were done for upgrading to mbedtls-3.1.
Yes, Wifi security code depends heavily on mbedTLS and there are lot of changes there as well.

[AdityaHPatwardhan]

Hi @HamzaHajeir I am closing this issue, feel free to re-open it if required.

[HamzaHajeir]

Hi @AdityaHPatwardhan,

Glad to have your support.

Tried to revert these merge commits, but it seems it's not sufficient yet.
Yet resolving issues, hit with an error within the file (components/wpa_supplicant/esp_supplicant/src/crypto/tls_mbedtls.c), which is caused rootly by a completely excessive directory happens to exist (components/wpa_supplicant/esp_supplicant/src/crypto/) while in release/v4.4 it's not present.

The commits you've pinpointed suggests that this directory was already existed.

[AdityaHPatwardhan]

Hi @HamzaHajeir
Most likely this was a result of refactoring for v5.0 in wpa_supplicant or maybe later.
I think wpa_supplicant/src was renamed to wpa_supplicant/esp_supplicant/src

[HamzaHajeir]

I see, I found it here: https://github.com/espressif/esp-idf/tree/release/v4.4/components/wpa_supplicant/src/crypto

but there's also some file structure issues. Did the refactory happen to be present in certain commits? or git reset was utilized instead?

[HamzaHajeir]

@AdityaHPatwardhan, I've tried to revert it completely to the version present in v4.4, but it seems entrenched to other components, as esp_rom.

Once I pass the issue of compiling mbedtls v2 within IDF v5.0, I'd ensure limiting the probabilities to the minimum.

The alternative would be just to compare a working full house of v4.4 (Mbedtls v2) to a non-working full house of v5.0 (Mbedtls v3).

What do you think?

[AdityaHPatwardhan]

Hi @HamzaHajeir,
It looks difficult to get mbedtls-3.x working with IDIFv4.4. IDF-V5.0 and mbedtls-3.X are both breaking versions of the respective SDK and have a huge number of changes.

The alternative would be just to compare a working full house of v4.4 (Mbedtls v2) to a non-working full house of v5.0 (Mbedtls v3).

Yes, probably. You can try to pin point what exactly is not working with mbedTLS v3.X and then we can see what is the issue here.

A faster way to compare would be to see what has changed in mbedTLS 3.X regarding the function that has the issue.