OpenWrt 21.02.1 First service release

You should use factory image. I got the same error when I first upgraded my routers from 19.08 to 21.02. I upgraded my wr3200, wrt1900acs, and wrt1900ac using the factory image 21.02 with force upgrade and not keeping any settings. It worked fine after that.


@anomeome and @thuyn789 ,
Thank you. You both confirmed what i thought. The further I read, the more I confused myself.

WRT32...does 21.02.1 offer 10 degrees lower cpu temperature like in master branch? is the lower temperature achievable only with kernel 5.10?

Happy to report sysupgrade of c2600 from 19.07.8 => 21.02.1 (keeping settings) OK.
Great shout out :scream_cat: to all involved!

Only a few minor issues, some already discussed in other posts, namely:

  • Due to the network interface changes brought on with 21.02.x, I had to change all my scripts that contained: uci get network.wan.ifname to uci get network.wan.device

  • menu bar (LuCI) is aligned to the left, fix to centre align: opkg upgrade luci-theme-bootstrap

  • Openvpn (LuCI), when trying to edit an uploaded openvpn config file, getting error 'Insufficient permissions to read UCI configuration' fix: Insufficient permissions to read UCI configuration

  • System Load Average seems to report a higher figure compared to 19.07.8

  • 21.02.1 uses more space, I'm only left with 1.1MB now, compared with 2.8mb with 19.0x , I'll need to see where I can trim some packages!

1 Like

Posting my results:
Netgear WNDR3800 19.07.7 upgraded to 21.02.1 preserving settings went smooth. This is only used for a switch and access point. After 10 min of testing, seems good so far.
Linksys WRT1900AC v1 upgrade went smooth. I did NOT preserve settings, and used the factory image to flash. So far the only 2 noticeable issues are a decrease in wifi speeds and wired internet speeds. I've only tested 2.4 on both the WNDR3800 and WRT1900AC, but the WNDR3800 is performing faster in wifi tests. I'm also not reaching my max internet speeds, avg just under 500Mbps, when i should be 800-900 normally (i haven't ruled out isp congestion yet). I'm just reporting my initial observations 20 min into updating. I'll try and research any wifi issues later.
@thuyn789 , you mentioned you updated the same model. Have you noticed a decrease in wifi performance or other speed issues?

My wrt1900acs and wrt1900ac did not have any wifi performance issue but I did notice some stability issues with wrt3200. Inspired by this (credit User34), I implemented some fixes below:

  • Installed irqbalance. Change 'enabled' from '0' to '1' in '/etc/config/irqbalance'.
  • Disabled 802.11w
  • Patched firmware-88w8864 mwlwifi specific high latencies by disabling tx_amsdu. Add in luci > startup > local startup (nano /etc/rc.local) the following commands:
echo "0" >> /sys/kernel/debug/ieee80211/phy0/mwlwifi/tx_amsdu
echo "0" >> /sys/kernel/debug/ieee80211/phy1/mwlwifi/tx_amsdu

This trick works for me. Idk if it will work for you.

1 Like

Thanks. I'll do some more testing and such before making "tweaks". I'll let things bake in for a little bit before changing. I'm also using fast roaming, so i need to make sure that's working also. But that will be a little bit later, it's super late in my timezone at the moment, and I should call it a night. Thanks for responding!

1 Like

Has MAC Address Override been removed from Interface->WAN->Advanced?

I'm pretty sure it was there before 21.02, but if it's now there I'm not seeing it.

I should note, regardless of UI, the pertinent line in my /etc/config/network (specifically, in the "config interface 'wan" block, option macaddr followed by the address) does still exist, but it's being ignored, which may be correct if it's been deprecated. I know it's being ignored by virtue of picking up a new external IP when I upgraded to this version of the firmware. That only happens when changing the MAC.

The spoofed MAC does show in Status->Overview (Network), which is interesting.

/etc/config/network was automatically converted upon entering Network->Interfaces, but I assume that's not related.

It absolutely worked in 19.07.8 and before. I don't know about the first version of 21.02, since I didn't try it.

Perhaps the "Devices" tab is what you are looking for?
(on the main Network->Interfaces screen, not inside the WAN configuration)

I am still using 21.02.0, but I guess 21.02.1 is similar.

On the contrary, I believe the Devices tab was introduced to handle the new network configuration syntax.

I suggest removing option macaddr from the config interface section to avoid confusion.
It should be added to config device instead.

@mpa Thanks.

Upon visiting the Devices tab, which I never noticed before, I found the MAC to already be there. So, I looked at /etc/config/network again and found that the conversion I mentioned yesterday (the one that happens when first visiting Interfaces in the UI) had not created a config device section for eth1 (the wan). This is despite the conversion making numerous other changes in accordance with the new syntax. Not sure why.

Since the old syntax is still supported, however, it wasn't needed. To avoid confusion though, I created that section you mentioned and moved my "option macaddr..." line into it. And to test that the system recognizes it, I went into the Devices tab and tried changing the MAC. It does indeed change it in that new section.

And my WAN IP changed again, proving that spoofing works.

I should point out that I had a new IP yesterday right away after flashing (and rebooting), several hours before I ever visited the part of the UI which triggers the conversion, so the syntax changes shouldn't have related to my initial problem, though I'm glad it's more thoroughly converted now.

What I guess happened is that despite having the same IP for at least a year, and rebooting the router weekly (if I was going to pick up a new IP, that's when it would happen), I was given a new IP after flashing by pure coincidence. It wasn't because of the MAC, which was the same as it ever was and truly in effect. It would have happened anyway if I'd rebooted that day (or perhaps on any day that week, since I hadn't rebooted since last weekend) even on the old firmware.

[TP-Link TL-WDR3600 v1] upgrade directly from 19.07 to 21.02.01 worked without any issues.

I have guest network, VLAN, DDNS, WakeonLan and wireguard. I just installed the packages again. Luci also prompted me to upgrade network configuration and picked up all my firewall rules to block machines based on the mac address. Other old configurations worked out of the box. I would have taken some time to understand the new way of doing networking but automatic switch over is an excellent idea.

< A Big Thank you > to the entire team for saving old routers from the trash heap and making them more useful. BTW No rush but the software offload will be a cherry on the top when you fix that bug. :wink:


Out of curiosity, did the conversion give you a section like this for your wan?

config device
	option name 'eth1'
	option macaddr '00:01:02:YY:YY:YY'

As mentioned above, the conversion only did the lan one for me, for whatever reason. Not that that broke anything due to backward compatibility.

So after some more testing on the WRT1900AC, I was able to increase my speed by enabling Software offloading. But i can't remember if i had this enabled pre upgrade. If I did, then that accounts for the speed difference I initially saw and reported above yesteray. Since i couldn't preserve settings, and I had to manually reconfigure everything, I'm not sure what I had this setting previously. I did take a backup before upgrade. Is there a spot i can look in the tar.gz backup? I looked at the firewall file located in /etc/config of the backup, but didn't see an offloading config option set. Do you recommend I post this question as a new topic? As for the wifi performance issue I observed previously, I think i had a flaw in my initial observations. I'm still going to test, and report back any other oddities i find. I do love OpenWrt!
What's also odd, is that none of the system resources seems to spike when doing speed tests. CPU appears to stay pretty low, memory, etc. It seems that 500MB is some type of artificially imposed bottleneck? I really don't think I had software offloading enabled previously, but i'd like to confirm that.

After some further reading and research, I must have had software offloading enabled previously. I read somewhere it was defaulted in one release, but I can't confirm that. I could have turned it on at some point and forgot about it. But with this model, it appears without offloading, it does peak around 500. With software offloading enabled, speeds are almost as good as before upgrading from 19.07. It's still running a little slower as far a peak download, when I used to avg 800ish, and now it's 600ish. For my case, it doesn't matter one way or the other. I just thought I'd mention the observation.

1 Like

I have following entries. I do not see eth1 device at all. BTW In old ways, I had a separate VLAN for guests. I do not see this anymore. This seems to be handled by the switch. WAN does have its own VLAN.

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'eth0.1'


config device 'wan_eth0_2_dev'
	option name 'eth0.2'
	option macaddr '00:01:02:YY:YY:YY'

Have good news about VR200 :smile:

I tested 21.02.0 before 21.02.1 there wasn't hope, but I give try then looks amazing :cowboy_hat_face:

Wi-Fi setting

Encryption: WPA2 PSK (CCMP) 
WMM Mode: On
and other settings are default.

Normally I took 4.5-7.0 Mbps different routers, but this time took ~10 Mbps
Thank you
I highly recommend push as stable release

I didn't run across any big problem on different components btw.

I'm seeing a lot of errors regarding incompatible kernel versions, like for bcp38, sqm, banip, and others:

The installed version of package kernel is not compatible, require 5.4.143-1-576e7117… while 5.4.154-1-576e7117… is installed.

Do I just need to wait for the packages to catch up? I'm kind of surprised since it's not like this was released yesterday. These seem to be related to kmod* packages (like kmod-sched-core and others).

Just wait a few days until the packages are ready.

Presumably the bots were done when this thread was posted. I would assume the issue is closer to home since there have been no other voices stating the same (as of yet).

FWIW, I upgraded a C7 (ath79) a day or two ago, and had no issue in getting bcp38 installed. Wonder if your target's package compiling is running slow for some reason.

I guess you could look at the dates. There used to be a link to a status page that had a huge panel of the compilation states of various builds, that one could gawk at. Not sure if that's available nowadays...

Edit, uh, yeah, sounds like the kernel is the wrong version, and the package wants an earlier one. So it's a 21.02.0 package? Any chance you got things pointing at the wrong directory to get packages from?

You (Jeff47) should mention what target platform you're on, so someone can check that the targets are getting properly updated.

Make sure you didn’t accidentally backed up the opkg repository configuration from the previous version.