This is what I posted in my original post:
I have installed only “wpad-basic-mbedtls” as this comes by default in the firmware builder for MX4300.
This is what I posted in my original post:
I have installed only “wpad-basic-mbedtls” as this comes by default in the firmware builder for MX4300.
Sorry for overlooking that but the basic modules are missing some features. Use full module variants instead. You’re not limited by the flash size.
No problem. I know I can install one of the bigger ones but curious which one is better for a MESH setup. Too many features and package names makes it confusing. I guess I will install “wpad-mesh-openssl” and be done with it instead of fighting over it. lol
I guess I can replace “wpad-basic-mbedtls” with “wpad-mesh-openssl” when building the firmware, right?
Yes you can but in that case search for mbedtls to see what other packages use that and replace all the found packages that use it with ones that use OpenSSL libraries.
Or, if I install “wpad”, then it should include everything, right? Since we have a massive flash partition on MX4300, why not the complete “wpad” and it should include everything from mbedtls too, right?
I use wpad-basic-mbedtls and works fine, from another thread ( Documentation on 802.11r ) I added option reassociation_deadline '20000' and also helped some devices that didn’t work
FWIW, I install wpad-mbedtls instead of wpad-mbedtls-mesh. The mesh variant adds enough functionality for mesh, but is only slightly smaller in size than the full version, so I go ahead and install the full version.
For me, only wpad-basic-mbedtls works when I enable 802.11s as it has WPA3-SAE support. But, it doesn’t have 802.11k support. So, I tried various wpad-* (even the full wpad) and nothing works for WPA3-SAE even though they all claim to have WPA3-SAE support for 24.10.2. Finally, I tried this combo “hostapd-mbedtls wpa-supplicant” and works although it gives a warning like this:
I spent couple of hours on this and not sure why the other wpad-* variants don’t work for WPA3-SAE on 24.10.2. Any ideas folks?
Yes, it works for WPA3-SAE (802.11s) but it doesn’t have 802.11k support which is needed for wlan roaming to work properly. I’m using usteer for roaming and it needs 802.11k.
I’m using the latest (8/1) AgustinLorenzo “NSS-WiFi with Mesh” build, which include the wpad-openssl package. I have no problem using WPA3-SAE with radio2 for wireless backhaul.
I see from your screenshot that you’re working on radio0; I only use WPA2-PSK with radio0 because not all of my devices connecting to the 5GHz network support WPA3, and mixed mode is no more secure than just running WPA2 (and it confuses some devices).
Here are other changes I’ve made, in case people are interested.
Advanced Settings tab: set "DTIM Interval" to 3, disable "Disassociate On Low Acknowledgement"
WLAN Roaming tab: set "Reassociation Deadline" to 20000
No, that is on radio2, which is used for the wireless backhaul. I am not sure how you got that it’s on radio0?
For radio0 and radio1, I use WPA2-PSK and for radio2, it’s WPA3-SAE. Although it works with “hostapd-mbedtls wpa-supplicant”, luci warns as if it doesn’t have WPA3-SAE support.
But. it’s working without ENCRYPTION, as shown in the screenshot, and NOT sure how I can make 802.11k and 802.11v to work on 24.10.2 with any of the other wpad-* packages.
Thank you for discovering that and sharing. I have not tried that, so I would not have known.
Why not use SNAPSHOT, on which wpad-openssl works perfectly fine? At least, it does for me on r0-cc2a47e. I guess there could be something wrong with your setup that would prevent it from working.
Guess what, it’s working with wpad-mbedtls. Got rid of wpad-basic-mbedtls and started fresh on the main router (with my uci scripts) and proceeded to the nodes and all good now on 24.10.2. Not sure what happened before and maybe, some config messed up. WPA3-SAE is active on the mesh point now.
Now, after configuring “usteer” and “static-neighbor-reports” packages, I have this issue but it’s a known bug. For now, I set the hostapd log level to “ERROR” on the phy0-ap0 and phy1-ap0 interfaces and got rid of the useless logging as syslog is unreadable because of this issue.
Now, it’s all good until someone fixes hostapd code.
what was the fix? was this patch ever submitted?
Anyone get these messages in syslog? Any ideas how to fix it?
Google isn’t helping much to resolve this issue.
ue Aug 26 05:44:35 2025 daemon.err hostapd: nl80211: kernel reports: key addition failed
Tue Aug 26 09:40:02 2025 daemon.err hostapd: nl80211: kernel reports: key addition failed
Tue Aug 26 09:50:53 2025 daemon.err hostapd: nl80211: kernel reports: key addition failed
Tue Aug 26 09:51:28 2025 daemon.err hostapd: nl80211: kernel reports: key addition failed
Tue Aug 26 09:51:28 2025 daemon.err hostapd: nl80211: kernel reports: key addition failed
Tue Aug 26 09:51:28 2025 daemon.err hostapd: nl80211: kernel reports: key addition failed
Tue Aug 26 09:52:00 2025 daemon.err hostapd: nl80211: kernel reports: key addition failed
Tue Aug 26 10:09:24 2025 daemon.err hostapd: nl80211: kernel reports: key addition failed
Tue Aug 26 10:26:18 2025 daemon.err hostapd: nl80211: kernel reports: key addition failed
EDIT: Fast transition (ieee80211r) is the culprit but don’t want to disable it to get rid of these messages if someone can point me how to fix it.
Hello,
Just starting my journey in Openwrt.
Have a Linksys MX4200v1 tried non NSS openwrt, but yesterday found this forum and loaded Agustin Lorenzo latest 24.10.2 build.
It runs so much faster than the non NSS version - but it does not have USB support.
@dalant - does your dropbox posted version have USB support?