OpenWrt 21.02.0 - First Stable Release

dmesg shows some problem with mt76 driver:

I’m surprised that x86 isn’t in the list of support for DSA.

Advice for restoring backups from 19.07:

Note that DHCP settings in /etc/config/dhcp have changed for resolvfile.
New value in 21.02 and master is
option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'

There should be in /etc/config/dhcp:

config dnsmasq
...
        option leasefile '/tmp/dhcp.leases'
        option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'

There is a 19.07 --> 21.02 migration script, but that does not get run if you restore old settings from a backup. (e.g. moving from a ar71xx build to ath79 build, and then restoring 19.07 settings after the initial reboot with 21.02.)

3 Likes

That's because there's no x86 switches; those systems have X amount of separate NICs (e.g. APU2).

2 Likes

I'm using 802.1q to define VLANs for my APU2 board. Does this mean that I don't have to change a thing and the current syntax will continue to work?

Edit:
Sorry; I could have answered my own question: I do not need to update the syntax

Everything is fine on my RPI 4, but i see a high CPU usage with SQM that i didn't have before. It's the same config, but now one of the cores is used at 90% with 600 Mbps. I had an snapshot before and i didn't remember any core going abobe 25-30%.

is visible in both 21.02.0 and snapshots later than around r17300...
(aka both kernels ~ and probably most targets)

possibly; sqm-scripts: bump to v1.5.1

maybe try an older ipk from the rc4/3 repo..

Is there somewhere a list of fixes between rc4 and final?

Main OpenWrt:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=shortlog;h=refs/tags/v21.02.0

plus the fixes in packages/LuCI

4 Likes

Thank you so much!

I successfully went from 21.02 rc4 with:

  • 2x Fritz!Box 7320 (Ethernet ports are not used, just wireless repeater in WDS mode + three ESSIDs, one needed a power cycle after migration but then it worked without further interaction, the other migrated without manual interaction)
  • 4x TP-Link Archer C2600 (added commands /etc/rc.local to run at 1.2 GHz and disabled all idle-modes, no issues with migration)
  • 1x Fritz!Box 7360 (used as WDS repeater and three ESSIDs, no issues with migration)
  • 1x UniFi UAP-AC-LR (very solid, no issues)
  • 2x AeroHive AP 121 (One AeroHive AP 121 is still on 19.07.8 because it must be configured from scratch to migrate, the other is running good with 21.02).
  • 2x TP-Link TL-WR810n (No issues, USB is powered on :wink: )

Retired:

  • 3x TP-Link 1043nd were retired. RAM is now too low.
1 Like

Is this a joke? This wasn't a release blocker? Do people not realize how many users enable this? My Archer C7 V2 needs software flow offloading to be worth using on my home network. Guess I'll be skipping this release, along with many others, I suspect.

1 Like

Installed on a 2xR7800 (one router+AP, one is just AP) and on a e4200v2 (only used as switch) from 19.07.8.
Getting the DSA vlans configured on the e4200v2 was a bit of figuring out how. Mainly was not clear that the interface needs to be on a different device after making the vlan, but after i had that in, it all works fine.

Thanks devs! :+1:

One question though: What is the state of 802.11k&v on this release? If I enable does it actually transmit anything useful? Do i need DAWN? do i need anything else?

I'm installing 21.02.0 on miwifi mini, worked fine on RC3,but the router randomly restart on RC4 and Stable Release, how to solve this problem?

And that's what you should do if you need flow offloading, yes. I get your position. However, you should realize that this already has blocked the release for a while. The bug report is open since January and nobody found a solution yet. The question is, should this block the release for everybody else who a) doesn't need flow offloading or b) doesn't have/use IPv6 addresses indefinitely?

The decision was made that this issue should not block the release, but the goal is to resolve this with a point update such as 21.02.1. Depending on whether you are affected by this or not, I get that people are disappointed. But I don't think this decision was that unreasonable, let alone "a joke".

27 Likes

Thank you for this shiny new release. Never imagined even my old TL-WR1043ND_V1 would see wpa3 support. Also updated my C7V5 and NBG6617. On my NBG6617 (ipq40xx) I can't no longer get my WAN port to act as additional LAN port- I have to sacrifice one LAN port for VLAN7 tagged pppoe dial-in.
I know you will fix that later :slight_smile:

21.02.0 installed succesfully on Netgear R6220, wndr3700v2 and wndr3700v4 and x86/64 PC.
I have several devices of each, and several services (routers, AP, mesh, VPN), all work smoothly.
I'll have a linksys MR8300 to test in a few days.

Congrats and thanks to the dev team for the wonderfull work. :star_struck:

1 Like

How do I verify the 21.02 signature file? According to https://openwrt.org/docs/guide-quick-start/verify_firmware_checksum I need to do gpg --receive-keys 88CA59E88F681580 but I get gpg: error reading key: No public key, I tried gpg --keyserver keys.openpgp.org --receive-keys 88CA59E88F681580 but I get

gpg: key 88CA59E88F681580: no user ID
gpg: Total number processed: 1

If I then try gpg --status-fd 1 --with-fingerprint --verify sha256sums.asc sha256sums I get

[GNUPG:] NEWSIG
gpg: Signature made Чт 02 сен 2021 09:44:11 MSK
gpg:                using RSA key 667205E379BAF348863A5C6688CA59E88F681580
[GNUPG:] ERRSIG 88CA59E88F681580 1 10 00 1630565051 9
[GNUPG:] NO_PUBKEY 88CA59E88F681580
gpg: Can't check signature: No public key

in LuCi firmware menu, upload the sysupgrade file to the router. Before you confirm the actual flash upgrade process via mouse click, LuCi calculates and shows the signature.

2 Likes

Actually that only shows the signature of the file. It doesn’t verify it.

The OpenWRT trust management is based on the gpg signature of the sha256 file. Once that is verified you can use the sha256 data in that file to verify the actual firmware file.

3 Likes

Ok, I did it by just manually downloading this file https://git.openwrt.org/?p=keyring.git;a=blob_plain;f=gpg/88CA59E8.asc and then doing gpg --import ~/Downloads/gpg_88CA59E8.asc For some reason the key at keys.openpgp.org is different than the one at git.openwrt.org
Edit: After some digging, it looks like keys.openpgp.org strips down identity information from public keys if an email is not verified, and gpg doesn't allow importing such keys.

1 Like