search

Aircoookie / WLED

Control WS2812B and many more types of digital RGB LEDs with an ESP8266 or ESP32 over WiFi!
https://kno.wled.ge
MIT License
14.55k stars 3.11k forks source link

Support WPA3 on Wifi #3040

Open schildbach opened 1 year ago

schildbach commented 1 year ago

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 commented 1 year ago

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

schildbach commented 1 year ago

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

schildbach commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

Jason2866 commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

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

Jason2866 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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:

Is that right?

Jason2866 commented 1 year ago

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.