I don't know why but now SQM is working fine on latest version. I didn't change anything on my build, just update/downgrade package to test.
Logs looks identical from v1.5.0-2 and v.1.5.1-1.
2 Likes
seeing this too... afaik has something to do with boot... switch over to layer_cake or something to debug properly for now ( and run it for a day between version switches when you switch versions... reboot )
Yeah, package management in luci has been flaky in 21.x
Sometimes it's there, sometimes... not. Just try again or use ssh. Maybe try a local mirror.
I think, that is a fair statement and I think it should be mentioned in the release notes that wrt3200 and wrt32x are devices that still have reasonable issues with 21.02 and should not (yet) upgrade to release 21.02.0.
The issues for these 2 mvebu devices are no surprise and have been around since the 21 rc* releases. This does not seem to apply for some of the other models of the same Linksys wrt series.
There are several threads in the install OpenWrt section discussing and debugging heavy issues for 3200 and 32x on 21.02 and it is not over yet.
The recent master releases seem to have fixed the bad issues for those particular 2 devices. But non- experienced users of wrt3200 and wrt32x should not upgrade to master images for everyday usage and probably rather stay on 19.07 for a while until a next fix release.
4 Likes
Could you send me your current /etc/config/network please (preferably from a router with a built in switch), I believe the solution is to replace ifname by ports (or rather add it, so the hotplug script stays backward compatible). But that is not a realistic root cause for the reported CPU overload.
1 Like
sorry mate... i've only got rpi4 and ipq806x (no dsa)
rpi4 config network device bits
config interface 'lan'
option device 'br-lan'
config interface 'wan'
option device 'eth1'
config device
option name 'br-lan'
option type 'bridge'
list ports 'eth0'
there also references in the dsa migration thread from rc2
Thanks, but it really looks that we need to add ports....
Do you really need radio 2? It's known to cause issues.
1 Like
Netgear R7800 - ipq806x : Update from 19.07.8 to 21.02.0 worked almost flawlessly with the following two exceptions:
(a) The 5 GHz band refuses to work with 160 GHz bandwidth and would switch on only with 80 MHz bandwidth enabled. (It worked fine with 160 MHz width in the 19.07.x builds).
(a) Samba had to be upgraded from samba36-server to samba4-server as the older package is not available with this build. It took a while, re-configuring all the peripherals connected to it, and would have been good to know beforehand.
Thank you to everyone who worked for this build.
Yes. Never had a problem with prior versions of OpenWrt/LEDE.
Still doesn't solve the other issues running 21.02.0 on WRT3200ACM
2 Likes
Thank you very much for the release of 21.02.0
Thanks to everyone who contributed.
My first with Openwrt 21.02.0 upgraded Device = Archer C7 V2 (Works perfect).
Next planed upgrade: RaspberryPi Zero
Greeting Robert
My Archer C7 v4 is running smooth as AP with the stable 21.02.
Thank you very much to everybody involved!
...supported by OpenWrt anyway. There are plenty of switches with x86 management CPUs out there. Random example: https://www.fs.com/de-en/products/107081.html
Lots of similar stuff out there. But they are usually running Cumulus or another switch specific OS. Would be fun to have OpenWrt there instead. Maybe a bit on the side the primary hardware targets. But so were the high port count Realtek switches until they suddenly were supported.
1 Like
Running great for me, thank you to everyone involved!
But that's cheating 
. It says the networking SoC is a Broadcom one. Now you know more than me about this, but it seems to me that an x86 management CPU is not the same as an x86 switch. The actual switch hardware is not x86...?
Flashed this to ER-X when IPv6 is enabled on devices internet is very slow or pages don't load completely. Software flow offload is off. Once disable on bridge interfaces speed came back. I disabled IPv6 on all devices to avoid any issues as my internet provider doesn't support it and it's disabled on all devices connected to my network, the ones that allow it.
Other than that everything is working well so far, only been a few hours so far.
1 Like
using SQM: not sure if there is an issue or not
(ignore log time, not connected to internet yet, I will do speedtest to see if traffic is shaped soon)
log shows error
Tue Aug 31 18:28:52 2021 user.notice SQM: Starting SQM script: simple.qos on eth0.2, in: 15000 Kbps, out: 15000 Kbps
Tue Aug 31 18:28:52 2021 daemon.err modprobe: failed to find a module named act_ipt
Tue Aug 31 18:28:52 2021 daemon.err modprobe: failed to find a module named sch_fq_codel
and then a few seconds later
Tue Aug 31 18:29:00 2021 user.notice SQM: simple.qos was started on eth0.2 successfully
I have never seen this before, until recently, but I don't know if its normal or not
have both sqm-scripts and sqm-scripts-extra installed
config is fq_codel with simple.qos
I installed 21.02.2 in my WRT 1900ACS with config wipe.
I followed my instructions I created for setting up past versions in the past but my wireless guest setup failed, none of the devices could communicate, or even get an IP. Is this because the new network (guest) is not associated with a device in DSA? (unspecified is listed as the device in the guest network setup)
I have reverted to 19.07.8
I could also use some help with the switch config conversion to DSA.
In addition, LuCI is now available over HTTPS in addition to HTTP. There is no automatic redirection to HTTPS on a fresh OpenWrt 21.02 installation; however, redirection will be enabled after upgrading from OpenWrt 19.07 to OpenWrt 21.02.
Well, that was fun. All my browsers refusing to connect to LuCI because it is classed as an insecure connection (all updated in the last week). There are work-rounds, but it blocks password managers from working.
Sure, you want people to use HTTPS for LuCI, but until you have something better than this as documentation, why does it default to "on"? It just looks like a broken release.