Just like RC4, this version has issues with Linksys WRT1900ACS v2. Clients loose connection to internet while connected to wifi. Can be fixed (temporarily) if you disconnect and reconnect wifi.
roughly how long does it take, before the clients loose Wifi again?
1 Like
Varies, but minutes. Doesn't seem like a lease renewal issue.
in LuCi advanced wifi settings of each radio there are 2 options:
Disable Inactivity Polling, default off
Disassociate On Low Acknowledgement, default on
Maybe try inverting these separately for a quick test, to see if it makes any difference.
You could also try current master image as well for a comparison - at least Wrt32x and Wrt3200 had ongoing issues and users claim the master works a lot better.
1 Like
Congrats to everyone involved in the development of this new stable version. It makes the already best even better.
What are the differences between rc4 and stable?
Read above, a few messages ago...
2 Likes
Would you consider opening an issue upstream? If there are regressions, they should know about it.
Unlikely, the run time cost of SQM is caused by the qdisc that are exercised, while most changes affect how SQM configures and starts these qdiscs... So not impossible, but rather unexpected. I would wonder more about the receive side scaling setting. What does:
for file in /sys/class/net/*
do
echo $file RX rps_cpus
cat $file"/queues/rx-0/rps_cpus"
echo $file TX xps_cpus
cat $file"/queues/tx-0/xps_cpus"
done
show?
Nope, that is IMHO solid release engineering, if a bug can be safely worked-around, but progress on fixing it has stalled it seems better to get the release out instead of waiting longer for Godot... Yes, unfortunate for users that use that functionality, and hopefully a fix can be found. But the alternative of delaying the release even further seems far worse. This is of course just my subjective opinion, others might disagree.
Well, the alternative is everybody "skipping"/not getting this release and actually testing it under real life conditions on a varied set of devices and configurations. IMHO the final steps of release maturation require a decent deployment, which for an opensource project like OpenWrt more or less means cutting a release to recruit sufficient many "testers". (Ideally everything with a release just works perfectly, but bugs happen)
9 Likes
There is already some described fix for offloading. If you want to speed up fix just test it yourself @Router and give feedback:
http://lists.openwrt.org/pipermail/openwrt-devel/2021-August/036223.html
4 Likes
Odd, none of the changes between https://github.com/tohojo/sqm-scripts/commit/bb064ad6065dcfb4966662bfab15b9fcdbb48e5f (1.5.0) and https://github.com/tohojo/sqm-scripts/commit/5d7e7977e14e147d5bcfa8a5f01636c7ab230fa4 (1.5.1) really should make any difference at run time...
Could you post the output of tc -s qdisc for both versions by any chance and if you are at it also the output of
SQM_DEBUG=1 SQM_VERBOSITY_MAX=8 /etc/init.d/sqm stop ; SQM_DEBUG=1 SQM_VERBOSITY_MAX=8 /etc/init.d/sqm start
That might help figuring out what is happening here.
1 Like
In programmers' language, versions are named
- alpha : early programming, a few features, highly unstable
- beta : features are implemented, a lot of bugs remaining, unstable
- RC release candidate : should work as designed, tracking for the latest bugs, almost stable
- stable : final version, everything should works fine, no bugs (at least not known)
RC4 is supposed to have a few bugs remaining, and these have been solved in the stable.
Meow! 
1 Like
Upgraded 5 Meraki MR-24's, keeping settings. One had been running 21.02.0-rc2 since June, the others were still on 19.07.07. Touched LUCI Network->Interfaces page on these latter 4 to trigger auto-migration of bridge and ifname configurations.
Everything working perfectly after a day. Many thanks devs!
I have a very bad situation with 21.02.0 on ASUS RT-AC57U. Something is wrong with the network connection. Delays and speeds are insanely bad. I barely can open any website, speedtest struggles to even start, and opkg update can't sync packages because of connection corruption / timeout.
Hardware is not overloaded or so, CPU usage is nearly zero and RAM has almost 100 MB free. No clues in the logs.
I've tried to tweak all the possible settings, hopped back and forth to 19.07.8 (with full reset) several times to be sure that this is firmware issue. And yeah, the result is: 19.07.8 works excellent, 21.02.0 is unusable.
Can only suggest that maybe the DSA works wrong on this hardware? No other ideas.
Edit: I found the issue. The only suspicious setting I was forced to use: MAC override.
Override is needed for auth to my ISP. I just tested through the other router and yes: it causes all this trouble. Without override the connection works perfect. But with this option set connection became unsuable.
So this is kinda a bug report now. 
2 Likes
I managed it by using the ubuntu keyserver
$ gpg --keyserver keyserver.ubuntu.com --recv-keys 88CA59E88F681580
gpg: key 88CA59E88F681580: "OpenWrt Build System (PGP key for 21.02 release builds) <pgpsign-21.02@openwrt.org>"
1 Like
That would only make sense for project actually having release cycle in place (every month or year instead of "when it's ready").
Look at it this way. I'm a C7 V2 user who needs flow offloading and IPv6. There's really two possible outcomes.
- Release is postponed until the fix is in, result: I have to wait until they fix the bug
- Release goes out with known issue for flow offloading, result: I have to wait until they fix the bug
For those affected it's the same result either way, except in option 2 at least those who don't need the feature can use the new release.
7 Likes
Mmmh, one way of looking at that. Then again OpenWrt aimed at 1-2 releases per year, and we are at least at 1.5 years since the last release already.... So 'when it is ready' is not OpenWrt's actual goal, it just happens to look like that....