OpenWrt 22.03.0-rc5 fifth release candidate

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.

MR8300.
Just tried a channel analysis with radio0 (qca9886) and it is working normally. Last time I tried, this interface was setup as a mesh. I have turned it to an AP now. So my previous message is not relevant.

Has anyone else noticed the following?

I have the following issue on DLink dir-1960 (mt7621), currently setup as IPv4 double NAT router behind a cable router, when browsing the web via iOS Safari:

issue:

  • every ~ 5 to 15 minutes, a web page would stall while loading
  • killing the browser or manually reloading the page several times would eventually fix it for another ~ 5-15 minutes and then this cycle repeats.
    I have not tested other browsers or LAN connections.

By coincidence, I saw a working fix in the RT3200 Topic (May thx to @not_the_nrc, he came up with the fix and has pointed out that there was a code commit, which started it, for more details follow the link):

Anyway, to fix the issue simply via config, in /etc/sysctl.conf add:
net.netfilter.nf_conntrack_tcp_no_window_check=1

Interesting side effect: for unknown reasons, web page loading via WiFi now feels snappier to me in many cases.

Also note: I have absolutely no clue, what the reason of the problem is, or what this config setting does or why it seems to fix the issue.

1 Like

Neither do I!

https://groups.google.com/a/chromium.org/g/chromium-os-reviews/c/NYFCKGvNh2s/m/R4ZI7OkYB3sJ

Is software or hardware offloading enabled in the firewall settings? Is the sysctl still needed if you disable all forms of offload?

thanks for the clue: Hardware offloading was indeed enabled.
Quick test so far: When turning off HW offloading, syctrl fix seems not needed.

Is it better, to stay away from HW offloading? Is it still experimental for mt762x?

I don't know if it is experimental for your device, but so far, based on your input, I don't see a reason to stay away for it. The workaround with sysctl is valid and logical. Indeed, when TCP packet forwarding/NAT is handled by the hardware, the kernel is no longer aware of their sequence numbers. Therefore, if it needs to pick up the stream where the hardware left it off, it only has an outdated idea about the valid range of sequence numbers to accept. The sysctl tells it to accept all possible sequence numbers.

4 Likes

I have a Redmi 2100 with MT7621 +RC5, HW flow offload enabled, did not notice any web browsing issues so far, both wired and wireless.
HW offload is indeed faulty on RC1, I have ipv6 packet loss, same with 21.02, but on RC4 it seems to be fixed.
Btw, network topology is different, I have a bridged ISP modem, so only one layer NAT.

is the latest snapshot based on RC5?

Nope. Snapshots available through Downloads and Firmware Selector are based on the Git main branch. There are also snapshots build from the 22.03 branch though.

To get an imagebuilder build working, I found I had to set these in PACKAGES in addition to my normal set of packages:

 wpad-openssl
 libustream-openssl
 -wpad-basic-wolfssl
 -libustream-wolfssl