Explore replacing libwpasupplicant.a with a pure Rust implementation

[bjoernQ]

This should be a non-default feature (i.e. defaulting to the precompiled libwpasupplicant.a)

It seems feasible to do this and might give some benefits (like better compile-time optimizations, compile time feature selection, better integration with esp-hal). It will most probably only offer a subset of functionality

Downsides might be that this code won't be battle-tested. However, we can have a look at the CVEs and see if anything potentially might apply. Due to reduced functionality and the use of Rust many of those probably won't apply

Resources

• https://github.com/kelvincheung/lw_supplicant
• https://github.com/espressif/esp-idf/tree/master/components/wpa_supplicant
• https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/src/connectivity/wlan/lib/rsn
• IEEE Std 802.11™-2020

[rftafas]

Hi,

Let me offer some 'ancient' information. Coming from a C-based implementation of on-chip Wi-Fi support to non-ESP-IDF OSes. In other words, enabling ESP32 on Zephyr and NuttX with Wi-Fi.

We found that a supplicant layer was not that greatly supported out there on microcontroller world. Furthermore, Espressif Supplicant solution was actually pretty good (size, performance) with the downside of having binaries. Then, since those projects don't like to deal with binaries within their kernel, we created wireless-drivers-3rdparty (later we ran into the problem that for everything we took from ESP-IDF, another repo was created. Then we consolidated everything we need from ESP-IDF in esp-hal-3rdparty and have deprecated the other).

We ended up deciding that we would settle for packing everything within the driver even after these OSes adopted some form of supplicant layer. Kind of like the ancient Wi-Fi cards did. Such decision is still valid today, even after these OSes adopted some form of supplicant layer. The main reason now is that decoupling the driver from the supplicant layer is not something fast or easy to do. Also... Binaries will always be there, so the Wi-Fi stack would always to be tainted anyway, this would add no feature (and potentially introduce bugs) and we had other things to focus on.

[MabezDev]

This won't be on our roadmap anytime soon, but we can always revisit this in the future.