Support WPA3 on Wifi

[schildbach]

Is your feature request related to a problem? Please describe.
WLED 0.13.x on an ESP32 (Athom Addressable Strip Controller) connects to Wifi only via WPA2. With WPA2, several kind of attacks are possible that are not possible with WPA3.

Describe the solution you'd like
Support WPA3. The ESP32 SDK seems to be able to do this out of the box. Tasmota has enabled this too.

Describe alternatives you've considered
If WPA3 cannot be considered, supporting PMF (protected management frames) on WPA2 would provide a similar level of security.

[blazoncek]

Can you point to the documentation on this?
Especially for Arduino platform.

[schildbach]

https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/wifi-security.html

[schildbach]

https://www.arduino.cc/reference/en/libraries/wifi/ only mentions WPA2 and below. I hope this doesn't mean Arduino doesn't support WPA3.

[softhack007]

https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/wifi-security.html

The first mention of WPA3 security mode is in the ESP-IDF v4.3.x docs. So it might be that WPA3 is only possible when building with the newer platform framework - WLED is still on ESP-IDF 3.3.6 (platform = espressif32@3.5.0) while you might need platform = espressif32@ ^5.0.0 or later to have the WPA3 functionality included in the framework.

Currently we cannot simply "upgrade" the platform, due to crazy bugs and stability problems in ESP-IDF 4.x.y - WLED on esp32 would basicially become unusable and crash randomly. But OK, at least we could have WPA3 ;-)

When espressif would finally get their act together and start testing/fixing regressions on esp32, then -maybe- WPA3 could come in future WLED release ... Right now our chinese friends seem to be more focused on destruction of existing APIs - like deprecating the I2S driver completely - and replacing it with something even more cazy 🤣

[schildbach]

That's an interesting insight – thanks! Stability is certainly more important than WPA3.

[Jason2866]

@softhack007 Latest Arduino core 2.0.6 is stable. Tasmota does run rock solid with.
Code needs to be adopted to the changed APIs ;-)

[softhack007]

@softhack007 Latest Arduino core 2.0.6 is stable.

As much as I want to belief you ... I've tried the latest core 2.0.6 on a -C3 and -S2, and what i saw was worse than 2.0.4/2.0.5. "Classic ESP32" also crashes too often on latest cores, compared to rock-solid builds with platform version 3.5.0. Maybe we are not ready yet for new cores and newest ESP-IDF.

From my (limited) experiences, arduino-esp32 2.04/2.0.5 (and ESP-IDF 4.4.1 / 4.4.2) still seem to be the better choice when a new platform version is absolutely necessary.

[Jason2866]

Just can say Tasmota runs weeks without an reboot or WDT on ESP32, ESP32-S2, ESP32-S3 and the ESP32-C3. Yes, it needs changes in code, to get there.
Don't get me wrong, in no way i mean the next statement offending.
WLED is and was (until now) never rock solid on an ESP32.
Never managed to have an uptime over 2 months without an reboot or WDT.
With the old core I doubt you will manage this. The underlying IDF and Arduino code has too many bugs.
To be clear i love WLED and use it!!!

[blazoncek]

@Jason2866 could you help us with issues with LittleFS on regular ESP32 and PlatformIO core platform 3.5+?

[Jason2866]

The issue with LittleFS and the older cores is related to the not correct builded precompiled bootloaders. There is no real fix for. Only moving to actual core (2.0.5 and 2.0.6)
Or you have to backport the way the bootloader is builded introduced with core 2.0.5 to older cores. One of more reasons why i started to maintain our own fork and compile the Arduino libs our self. We used only one Flash mode (DOUT) in this time. Other modes will make havoc.
In short flash mode is not always correctly initialized (from the Bootloader) and data gets corrupted when flash is accessed from LittleFS. That's not LittleFS fault.
Probably you have a message like corrupted dir pair
The old cores have a wrong Platformio Python script in Arduino core regarding flash mode.
The next issue Platformio sets the flash mode wrong too for mode QIO.
Took some time to find. If you look you will find PRs from me in both repo.
Next level was to fix the issues with non working S3 and OPI flash. It is working now 100% too.

[Jason2866]

So long story short. To avoid flash corruptions (not restricted to LittleFS!) cores before 2.0.5 can only be used in mode DOUT

[blazoncek]

That is an eye opener. Thank you.
We experimented with QIO and DIO and flash speed of 80MHz due to occasional flickering while frequently accessing flash and/or PSRAM during effect calculations.

To summarize:

• update to most recent bootloader
• use DOUT flash mode
• user more recent PIO platform if it is still compatible with WLED components
• try alternative flashing with esptool

Is that right?

[Jason2866]

Yes, right direction.
EDIT Iirc we used our own builded bootloader too. The provided tried always to switch in mode QIO.
So in these days it can work to use bootloaders from core 2.0.5 for the older cores.
EDIT2: Mode QIO enhances speed not that much. Using 80Mhz is way better increasing speed.