OpenWrt 22.03.0-rc5 fifth release candidate

I haven't even been able to build an image...

Perhaps related to this?

1 Like

WPA3 and WPA3/WPA2 mixed work for WRT1900ACS for OpenWRT 21.02. I did not do anything extra.

But I can't get it working for OpenWRT 22.03 RC1-5.

Interesting, WPA3 has been thought to not work for quite some time on mvebu due to mwlwifi, as described on the wiki: [https://openwrt.org/toh/linksys/wrt_ac_series#wpa380211w_may_hang_kernel] although info is maybe out of date. I only ever enabled WPA2 on this for that reason. I'll run some tests of my own, if it does work I'll update the wiki accordingly.

Hello, I am trying to build an image for Askey RT4230W using the rc5 image builder (ipq806x target), but the image builder shows the following errors (in a nutshell, I can't include wpad-wolfssl and curl due to architecture mismatch issues). Thank you!

Collected errors:
 * pkg_hash_check_unresolved: cannot find dependency libwolfssl5.4.0.ee39414e for libcurl4
 * pkg_hash_fetch_best_installation_candidate: Packages for libcurl4 found, but incompatible with the architectures configured
 * satisfy_dependencies_for: Cannot satisfy the following dependencies for curl:
 *      libwolfssl5.4.0.ee39414e
 * opkg_install_cmd: Cannot install package curl.
 * pkg_hash_check_unresolved: cannot find dependency libwolfssl5.4.0.ee39414e for wpad-wolfssl
 * pkg_hash_fetch_best_installation_candidate: Packages for wpad-wolfssl found, but incompatible with the architectures configured
 * opkg_install_cmd: Cannot install package wpad-wolfssl.
 * pkg_hash_check_unresolved: cannot find dependency libwolfssl5.4.0.ee39414e for libustream-wolfssl20201210
 * pkg_hash_fetch_best_installation_candidate: Packages for libustream-wolfssl found, but incompatible with the architectures configured
 * opkg_install_cmd: Cannot install package libustream-wolfssl.
make[2]: *** [Makefile:169: package_install] Error 255
make[1]: *** [Makefile:124: _call_image] Error 2
make: *** [Makefile:242: image] Error 2

For WPA3, did you try disable "802.11w Management Frame Protection"? I found this was needed when using some Intel Centrino cards in Client mode with WPA3-SAE.

It seems that there has been a regression in wolfssl generally which is impacting its availability in the package repositories.

For the time being, there are substitutes:

  • wget may be acceptable instead of curl
  • wpad-openssl should be a complete stand-in for wpad-wolfssl
  • libustream-openssl should be a complete stand-in libustream-wolfssl
2 Likes

No, I didn't

Can you try set "802.11w Management Frame Protection" to "Disabled" and test if that works?

Everything works fine so far (9 days), looking forward to the release :slight_smile:

Installed on Archer c2600 as dumb access point incl

  • VLANs (ethernet and wifi)
    (- using igmp-proxy on the main router 21.02.3 x86-ext4 virtualized in proxmox as linux container)
  • and the following parameters for imagebuilder
    make image PROFILE="tplink_c2600" PACKAGES="-ppp -ppp-mod-pppoe -ip6tables -odhcp6c -kmod-ipv6 -kmod-ip6tables -odhcpd-ipv6only luci irqbalance -ath10k-firmware-qca99x0-ct ath10k-firmware-qca99x0-ct-htt nano" DISABLED_SERVICES="dnsmasq firewall"

Many thanks !

cheers blinton

When I set it to "Disabled", all devices couldn't connect to WIFI for version 21.02. When I set it to "Optional" or "Required". All devices has no issue to connect.

For version 22.03, none of the three options work.

1 Like

I think 802.11w is mandatory for WPA3.

WPA3, with 802.11w disabled, is not a supported configuration.

1 Like

Yes, the WPA3 specs confirm it such as this link:

https://www.wi-fi.org/discover-wi-fi/security

"Disallow association without negotiation of PMF"

My point earlier was that WPA3 shouldn't connect to mwlwifi without 802.11w unless it was somehow fixed. (I've always left WPA2 on my WRT32X and use WPA3 on a U6-Lite ap that's wired to it but a more central location, much faster wifi anyway).

It is not fixed. I did extensive testing with this on my WRT1900ACS with version 21. What happens is even though you have enabled WPA2/WPA3, all connections are WPA2. All sorts of mayhem happens when you have another AP where WPA2/WPA3 works (I have a WAC104) when your device tries to fast roam from the WRT1900ACS to the WAC104.

Hi, I just updated to this RC5.

On my Edgerouter-X I use wireguard on it to login at home. On this version wireguard works for about 10min. When I issue the ifdown and ifup command it works again for about 10min.

is this a known issue?

The bug Daemon.err hostapd: nl80211: kernel reports: key addition failed - is this a problem? - For Developers - OpenWrt Forum is present in 22.03-rc5.
On my Xiaomi Mi Router 4a Gigabit Edition I often see when runnnig 802.11r the error message

daemon.err hostapd: nl80211: kernel reports: key addition failed

I'm getting good results with rc5 on a Bananapi M1 with a smart switch to the cable modem. Bufferbloat Test by Waveform

How did you get dns over https to work, there is a package missing for download one of the libs?

Will the fix for libwolfssl 5.4 package be patched back to 22.03.0-rc5?

I have tried rc5 in x86_64 virtual box for testing it with docker such as in the tutorial Running PiHole on OpenWrt (x86/RPi) using Docker - Tutorial/Experiences. The problem persists from rc4, containers are not able to access the WAN. Even a basic run of a container such as docker run -it nicolaka/netshoot ping 8.8.8.8 (from here) to try access the WAN interface on openwrt fails with same error as before.

root@OpenWrt:~# docker run -it nicolaka/netshoot ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
From 172.17.0.1 icmp_seq=1 Destination Port Unreachable
From 172.17.0.1 icmp_seq=2 Destination Port Unreachable
From 172.17.0.1 icmp_seq=3 Destination Port Unreachable
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2081ms

On 21.02, the containers are able to access the internet, similarly on normal linux distributions such as Ubuntu 22.04. So far docker networking seems broken with the new 22.03 rc's.