OpenWrt 21.02.0 - First Stable Release

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.

Should be some adaptable bits to be found in the DSA tutorial.

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.

3 Likes

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.

1 Like

Linksys MR8300 v1.1
Installation succesfull from stock firmware UI, despite being a pain to find the right URL :frowning:
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.

I have a PPPoE connection and had no issues. Just had to configure the VLAN ID for the WAN and enter my credentials and it worked.

1 Like

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).

5 Likes

I found instructions indicating it might be possible to do a sort of upgrade: Linksys WRT3200ACM & 21.02.0-RC1 popup message - #7 by hnyman

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).

Good news, with this version my WAN speed is still good: https://www.speedtest.net/my-result/d/e50d8588-fa34-475f-b26f-7e6392d3e64d

Has newer happend to me yet, it is kind of hard to happen. The MAC is hardware coded.

Are you sure you don’t use some kind of MAC override?

It seems a MAC override was created during the upgrade. I have removed it.

1 Like

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.

Https is as standard OFF. It was only ON in Rc1.

The instruction for uhttpd is the same as it has always been.

Does offloading is working on
development snapshots?

reboot problem on hlk-7628n

root@OpenWrt:/# reboot
root@OpenWrt:/# [  202.398701] lan2: port 1(wlan0-1) entered disabled state
[  202.427143] device wlan0-1 left promiscuous mode
[  202.436366] lan2: port 1(wlan0-1) entered disabled state
[  202.500821] device wlan0 left promiscuous mode
[  202.509852] br-lan: port 2(wlan0) entered disabled state
[  204.876249] br-lan: port 1(eth0.1) entered disabled state
[  204.940155] device eth0.1 left promiscuous mode
[  204.949211] device eth0 left promiscuous mode
[  204.958016] br-lan: port 1(eth0.1) entered disabled state
[  211.069541] reboot: Restarting system


system stock at "reboot: Restarting system"

1 Like

please post your full kernel log so we can see the flash chip model