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.
(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.
It does actually default to "off" in 21.02 ("no redirection"), but your own old settings (copied from the previous 19.07 version) defaulted to "redirect to https if SSL capability exists" in /etc/config/uhttpd.
Did your WAN work out of the box? Mine didn't. The network device eth0 was greyed out. Once I edited network device eth0 to Accept local (Accept packets with local source addresses), eth0 became non-greyed and WAN got an ip-address from DHCP server.
These should have been there before as well. A qdisc can either be built-into a kernel or live in a loadable kernel module. OpenWrt does not have a reliable autoloading system for kernel modules, so sqm tries to load a few modules essential for its functionality, but some, e.g. fq_codel, are built into OpenWrt's kernel, so the loading fails and you get an error message. verify_qdisc() will later check whether a qdisc is actually working to deal with potentially built-in modules.
Upstream sqm unconditionally silences these errors, but that will also hide real errors of users trying to load modules that are not built-in and not found as modules. Not sure how often that triggers, but especially for novices that would be somewhat hard to debug without an error message.
Linksys MR8300 v1.1
Installation succesfull from stock firmware UI, despite being a pain to find the right URL
wifi0 (qca 9886) not working. It is enabled, but can't be found by client devices. It is a documented issue which is also on the EA8300 apparently.
My version is 1.1, maybe some tiny differences from version 1.0 ?
I have tried CT and standard ath10k firmware, changing country region and changing power, nothing seems to work. If someone is willing to help I can experiment.
That is not what the release notes said. And if it is duplicating a v19.07 setting why does it work differently to v19.07, so the same browsers regard v21.02 as insecure.
In 19.07 the HTTPS enabling libraries were not installed by default, so you did not connect with HTTPS unless you installed the needed SSL libraries (and the required libustream wrapper). Thus you did not receive the certificate warning, although the redirection option was set as enabled.
For 21.02 the SSL + libustream libraries are installed by default so there is HTTPS capability. And if you sysupgrade with settings from 19.07, your old dormant setting from 19.07 with the "redirect to https" enabled becomes effective. And thus you get a warning.
But for a new 21.02 installation (or a sysupgrade without settings), the HTTPS redirection is set as disabled, so there is no warning (if you just connect with http).
So I renamed /etc/config/network and /etc/config/system to network.old and system.old and flashed retaining the configuration.
This worked as expected. I had to re-create my guest network and attach my guest wireless to it. Then I setup the VLANs for the wired network.
Is it well known with the DSA devices the WAN MAC address changes when upgrading from previous versions? This is problematic with ISPs like Ziply Fiber where after two leases you can't get another until the lease time for a previous lease expires (four hours in this case).
I think the better solution would have been to initially have HTTPS off, whatever the previous set-up had been, and tell users how to set it up. Doing nothing in v19.07 looked like nothing was switched on, and the default for v21.02 should have been the same behaviour, with a clear explanation.
I'm not in a rush to reboot my system to install v21.02, because that shows up as a possible line fault to my ISP, and they drop the connection speed. It's nothing to do with any software or hardware here. And all I have found on openwrt.org about HTTPS misbehaviour is pretty old, often blaming new browser versions.
I hope somebody can explain how to get HTTPS running.