OpenWrt 21.02.0 - First Stable Release

Yea it was an absurd reply. 21.02 is an impressive release and DSA was a huge undertaking, but it's the right thing to do moving upstream I would say. I switched my WRT32X to master snapshots because of kernel 5.10, gcc 11, and most importantly wifi is more stable (21.02 seems to have an issue much less present in master). But it's a great release. My only disapointment is the LuCI theme, there should at least be a dark mode. Model a dark grey/blue color sceheme off tomato or even the oem wrt32x firmware with the same bootstrap interface would have been fine.

4 Likes

It's a device file and double redirect makes sense

1 Like

You are right. When I first set up OpenWRT I was using WPA2. Later on I enabled WP3/WPA2 mixed mode. So right now it is reverted to optional. This is why I'm not sure if it makes a difference. I've been using mixed mode for a while now, but I think I only have a handful of WPA3 capable devices, and I'm not sure which is being used by each device.

Fully agree with you that 802.11w config does not seem to make a difference, at least not with this series of WRT + current stable release. I started with disabled like you and now have moved to enabled on 5GHz, and optional on 2.4. Did not see any difference in stability, speed nor latency. Not that WPA3 really matters to me as there is maybe no difference in terms of security as I still have to live with the mixed mode until I change all legacy devices (which won't happen so soon).

Exactly. Not throwing away any old devices today.

When you switch back and forth between master and 21.02 did you have to throw away your configuration file? Not noticing significant WiFi problems with 21.02, but I don't long to rebuild my config just to see if it's more green on that side of the fence.

Yea I do, but it only takes me 10 min to reinstall the packages with opkg and fully reconfigure my wrt32x. I've done it many times have a little personal guide and settings written that I basically just copy and paste in and reboot. I always leave the OEM firmware on the second partition just in case.

1 Like

There is a huge issue.
CONFIG_TCP_MD5SIG is not activated anymore by default in the kernel, and this breaks a lot of packages like bird, frr and quagga which needs TCP MD5 support. So it has to be configured my using make kernel_menuconfig . In master branch it's still active. I think that's a major issue.

I try to upgrade my wrt1900acs from OpenWrt 19.07.8 but it failed.

I downloaded openwrt-21.02.0-mvebu-cortexa9-linksys_wrt1900acs-squashfs-sysupgrade.bin and when i tried to flash i got this message :
Warning

so i checked "Force upgrade" and nothing happened, no light were on, no reboot. I loss the connection with the router, so i reset and start/stop the switch and it came back to 19.07.8

So what i have to do ?

and uncheck keep settings

Edit: Yes, you will find many threads about how to deal with issue.

1 Like

This means i will loose all config ?

Very bad news, thank you, first time i saw this message since years ( 6 or so). I am sorry but i can't reconfig all my router, firewall etc...

Again,search the forum, it aint that bad, there are just a few config files that get in the way, with network being the only real show stopper causing the soft-brick.

2 Likes

Has anybody similar problem with openwrt (latest).
I have laptops, ipad and chromecast in same wireless network.
I have TP-link C7 v2 and i have noted 5GHZ network working only with lower channels.
But actual problem is. I have set 5G ch36, so it network working fine and all can use internet (ipad,laptop, chromecast).
Problem is, if laptop or ipad change 5Ghz network and chromecast is still 5Ghz, then Chromecast share not found in this machine.
If i change Ipad or laptop 2.4Ghz it can find chromecast, what still is 5Ghz.
I understand if dififferent network cause problems, but now problems cause same network.

edit:
Back to version 21.02.0 stable, all working well. Problems happen with newer version.

Hello, does Fritzbox 4040 support Distributed Switch Architecture (DSA) with this release or the old swconfig? Thank you!

The Fritzbox 4040 is based on the IPQ4018 SoC and still uses swconfig, not DSA.

Please note:

4 Likes

Is ASUS RT-N56U B1 supported? I see it in mt7621 target: https://downloads.openwrt.org/releases/21.02.0/targets/ramips/mt7621/openwrt-21.02.0-ramips-mt7621-asus_rt-n56u-b1-squashfs-sysupgrade.bin

Yes.

1 Like

upgraded today my second site's mqmaker witi-256m with a dirty hack (restoring backup - without network config) - only issue was luci (KO) but quickly found a fix on a google search https://techoverflow.net/2021/05/04/how-i-fixed-openwrt-luci-error-etc-config-luci-seems-to-be-corrupt-unable-to-find-section-main/
Only major downside is that openwrt comes by default wifi WIFI disabled - had to use imagebuilder with this workaround
Guys - we really need something like this ASAP - next release and backport to 21.02 !!!!

I have been noticing infrequent but intermittent failure (x3) of my WRT1900ACSv2 5Ghz networks (wlan0) internet connectivity after scheduled nocturnal reboot. This issue fixes itself after I manually reboot the router from the Luci settings (via 2.4ghz wlan1), but is affecting my long term stability. Reviewing the system log, I've noticed the following. Please let me know if anyone is experiencing these issues. Considering trying my luck with the master build, but I also wonder if someone has found a work-around.

  * daemon.err modprobe: failed to find a module named act_ipt
  * daemon.err collectd: rrdtool plugin: rrd_update_r failed: /tmp/rrd/OpenWrt/cpu-0/percent-softirq.rrd: opening '/tmp/rrd/OpenWrt/cpu-0/percent-softirq.rrd': No such file or directory
  * daemon.err collectd: rrdtool plugin: rrd_update_r failed: /tmp/rrd/OpenWrt/cpu-1/percent-interrupt.rrd: opening '/tmp/rrd/OpenWrt/cpu-1/percent-interrupt.rrd': No such file or directory
  * kern.err kernel: wlan0: failed to remove key (0, xx.xx.xx.xx.xx.xx) from hardware (-5)
  * kern.err kernel: wlan0-1: failed to remove key (0, xx.xx.xx.xx.xx.xx) from hardware (-5)

Until then, I'll implement watchcat on a wlan0 network and see if this can recover the stable state.