It allows you to create different builds for subtargets by including / excluding packages from respective images. You can use that facility still, but will have to exclude the problematic package by adding a string to the package list in make menuconfig with a - (hypen) in front of the name, rather than just the name, which would include a package
1 Like
I also use an ar71 device the Archer C7 v4 seems to work for me. Although the craziest thing happened it "used" to work just fine using Openwrt 18 on my TP-Link WDR3600 as a client to my Archer running Openwrt 19. But After I upgraded my Openwrt 18 to 19 on my WDR 3600 device it suddenly "stopped" connecting. Even after setting it back to version 18 it STILL would no longer connect. Which is crazy.
EDIT: Fixed my connectivity problems by resetting the WDR 3600 running Openwrt 18 to factory and setting it up normally.
I'm thinking the technology is probably still too new to just "set it and forget it" and requires slight tweaks to work.
Don't pull your hairs out man. unless you're the one trying to fix this issue then good luck to you. 
After I set it up I realized none of my stations can connect to it, even if I set it to WPA2-PSK/WPA3-SAE mixed mode... Well, it's worth a shot I guess.
Did you make sure to set 802.11w Management Frame Protection to Optional? I think that's a requirement for WPA3 and not necessary for WPA2 so it should work with WPA Mixed Mode. At least that's how I have mine setup and I am allowed to connect using both "WPA2 and WPA3".
1 Like
WPA3 as a standard mandates the use of 802.11w as required, but you can experiment with that setting under SAE (optional or disabled), both of which should work (especially 802.11w is a problem for many older network chipsets/ devices) but aren't compliant to the WPA3 standard. For WPA2PSK/ WPA3SAE mixed mode, 802.11w can only (reasonably) be set to optional.
3 Likes
Just wanted to thank the developers and contributors that worked to get WPA3 incorporated into OpenWrt. I am building off trunk using hostapd-wolfssl, and my Android Q device connects just fine with the AP set to WPA3 only.
3 Likes
May I know which device you are using? I can’t get WPA3 working in MT76, at least my iOS 13.1.2 iPad says no.
My AP is a PC Engines APU2 (x86) with a Compex WLE600VX (QCA9882) card in it. The client device is a Pixel 3 phone running Android Q stock firmware.
My company-issued cell phone is an iPhone SE running iOS 13.1.2 and, like your iPad, cannot connect to my WPA3-only AP, despite Apple literature saying iOS 13 supports WPA3. Interestingly, in settings it shows support for WPA3-Enterprise but not WPA3-Personal. This is not an admin/company policy restriction on the phone, since it is running stock iOS with no additional apps whatsoever.
1 Like
I upgrade Windows to 1903 and installed the newest Intel Wireless driver last night, WPA3-Personal works fine in both 5G and 2.4G. It seems iOS13 has compatibility problem with WPA3. MT76 is not the problem.
I have the same problem with different OpenWRT devices (running snapshot) and Apple-Clients.
I did a packet capturing, the Apple client sends an 802.11 associate package to the OpenWrt device including SAE cipher and the specific PMKID.
The reply from OpenWrt is:
Status code: Invalid pairwise master key identifier (PMKID) (0x0035)
So the PMKID calculation on the Apple client seems different to the OpenWrt device, but i don't why...
How is this possible? If wpa3 works on other device and the pmkid is calculated at the same way... The the problem is with apple?
I'm not sure, because WPA3 works with Apple clients and LANCOM devices for example (i tried it myself).
So maybe it's a configuration issue or we need an additional hostapd option?
1 Like
Could be that they transfer pmkid in a different way and hostapd doesn't support it? Or openwrt doesn't support it.
confirmed. only wpa3-eap seems to be supported by ios 13.1.2 (no psk)
While settings in MacOS Catalina says "personal WPA3", connecting doesn't work either.
iOS 12 connected fine to a mixed access point (WPA2/WPA3) but iOS 13 doesn't. I think Apple have tried to implement WPA3 but got something wrong which prevents it from falling back to WPA2. See https://www.reddit.com/r/ios/comments/df7mop/ios_13_wont_connect_to_wpa3_networks/.
I'm running an OpenWrt snapshot on my router in sae-mixed mode, and a MacBook running MacOS Catalina and some iOS devices running iOS 13 are all able to successfully connect. The MacBook reports that it is connecting via WPA3 Personal, but I can't find any info from the iOS devices as to which WPA version they're using. All the devices were updated with the network credentials already in place - I haven't tested trying to connect a fresh Catalina/iOS 13 device.
This is a shot in the dark, but the only change from the default in my wifi interface configuration (apart from setting the ssid, key, and encryption mode) is that I enable PMKSA caching (via the 'auth_cache' uci setting). Considering the error message regarding an invalid PMKID, this might be worth a try?
That's supposed to only be relevant for enterprise type encryption... But worth a try I guess.
I'll confirm that option auth_cache '1' does fix Apple devices connecting.
I wonder why? I still think it sounds like an error in the implementation from Apple?
Does anyone closer to the source have a comment?
Also i think this option disables the cache, not enables it? Looking at hostapd conf it looks like it is enabled by default.
1 Like
I read below from repo of openwrt ,it is used to fix a secure problem
# You don't really want to enable this unless you are doing # some corner case testing or are using OpenWrt as a work around # for some systematic issues. config_get_bool auth_cache "$vif" auth_cache 0 config_get rsn_preauth "$vif" rsn_preauth [ "$auth_cache" -gt 0 ] || [[ "$rsn_preauth" = 1 ]] || append "$var" "disable_pmksa_caching=1" "$N" [ "$auth_cache" -gt 0 ] || [[ "$rsn_preauth" = 1 ]] || append "$var" "okc=0" "$N"