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
Depending on your needs wpad-basic-openssl or wpad-mesh-openssl would be options, too.
Also, luci-ssl-openssl might need to be selected in order to completely get rid of wolfssl (my suspicion - didn't test yet).
However, I can confirm your finding in general.
1 Like
Tell me, does Upnp work in this release?
I'm experiencing the same problem. We should assume it will be addressed and resolved in next rc or final build right? 22.03.0-rc5 is running great for me but I can no longer execute imagebuilder.
I've enabled upnp (just for testing) since rc5 came out on my WRT32X, 21 day uptime so far. Upnp page reports, "There are no active redirects." Can't tell if it's working and nothing uses it, or it's not working.