OpenWrt 21.02.0 - First Stable Release


The OpenWrt community is proud to announce the first stable release of the OpenWrt 21.02 stable version series. It incorporates over 5800 commits since branching the previous OpenWrt 19.07 release and has been under development for about one and a half year.

Highlights in OpenWrt 21.02.0

WPA3 support included by default

WPA3 was already supported in 19.07 but it was not provided by the default set of packages in OpenWrt images.

With 21.02, all packages necessary to provide WPA3 are installed by default in OpenWrt images. WPA3 is supported by most Wifi drivers in OpenWrt.

TLS and HTTPS support included by default

TLS support is now provided by default in OpenWrt images including the trusted CA certificates from Mozilla. It means that wget and opkg now support fetching resources over HTTPS out-of-the-box. The opkg download server is accessed through HTTPS by default. OpenWrt switched from mbedTLS to wolfSSL as the default SSL library. mbedTLS and OpenSSL are still available and can be installed manually.

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.

It is always possible to activate or deactivate the redirection to HTTPS like this:

uci set uhttpd.main.redirect_https=1   # 1 to enable redirect, 0 to disable redirect
uci commit uhttpd
service uhttpd reload

Initial DSA support

DSA stands for Distributed Switch Architecture and is the Linux standard to deal with configurable Ethernet switches.

OpenWrt 21.02 comes with initial support for DSA, which replaces the swconfig system that OpenWrt was using up until now. Not all targets have been ported: some devices still use swconfig while some devices already switched to DSA.

This is a significant change to how switch ports and VLANs are managed. As such, sysupgrade will not be able to convert existing swconfig configuration to DSA configuration (see “Upgrading” below).

See the OpenWrt DSA Networking documentation for details.

The following targets are using a switch managed with DSA in OpenWrt 21.02:

  • ath79 (only TP-Link TL-WR941ND)
  • bcm4908
  • gemini
  • kirkwood
  • mediatek (most boards)
  • mvebu
  • octeon
  • ramips (mt7621 subtarget only)
  • realtek

Increased minimum hardware requirements: 8 MB flash, 64 MB RAM

Due to new features being introduced and the general size increase of the Linux kernel, devices now need at least 8 MB of flash and 64 MB of RAM to run a default build of OpenWrt. More flash space is recommended for extensibility, see 8/64 warning:

It is still possible to build custom OpenWrt images (e.g. using the ImageBuilder) that may fit devices with 4 MB of flash or 32 MB of RAM. However, the level of functionality will be reduced and there is no guarantee to stability. See OpenWrt on 4/32 devices for more details and guidance.

New network configuration syntax and board.json change

There have been several changes to the network configuration syntax in /etc/config/network:

  • in config interface, option ifname has been renamed to device (since it refers to a device section)
  • in config device of type bridge, ifname has been renamed to ports
  • for new installs, the generated configuration now creates separate sections for layer 2 (config device) and layer 3 (config interface) configuration

The old syntax is still supported to facilitate transition, and there is no automated migration when upgrading.

However, the LuCI web interface detects old-style configuration and will propose to migrate it to the new syntax. This is necessary to be able to edit network configuration through LuCI.

New UCI syntax
The new configuration style looks like this:

config device
    option name 'br-lan'
    option type 'bridge'
    option macaddr '00:01:02:XX:XX:XX'
    list ports 'lan1'
    list ports 'lan2'
    list ports 'lan3'
    list ports 'lan4'

config interface 'lan'
    option device 'br-lan'
    option proto 'static'
    option ipaddr ''
    option netmask ''
    option ip6assign '60'

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

config interface 'wan'
    option device 'eth1'
    option proto 'dhcp'

config interface 'wan6'
    option device 'eth1'
    option proto 'dhcpv6'

This example uses DSA with lanX interface names. A non-DSA device would use more classical ethX interface names.
Changes to board.json

In addition, network fields in board.json have also been renamed from “ifname” to “device”. In addition, DSA bridges now expose their list of ports in a “ports” attribute.

If you rely on board.json, this change is not backwards compatible.

Example for a DSA bridge:

"network": {
        "lan": {
                "ports": [
                "protocol": "static"
        "wan": {
                "device": "wan",
                "protocol": "dhcp"

Example for a classical swconfig switch configuration:

"network": {
        "lan": {
                "device": "eth0",
                "protocol": "static"
        "wan": {
                "device": "eth1",
                "protocol": "dhcp"

New hardware targets

A new realtek target has been added, which is often found in managed switches. As a result, it is now possible to run OpenWrt on devices with a significant number of Ethernet ports. See supported devices for realtek.

In addition, new bcm4908 and rockchip targets have been added.

Support for many new boards was added to the existing targets.

Dropped hardware targets

The ar71xx target was deprecated in OpenWrt 19.07 and has been gradually replaced by ath79, see ar71xx-ath79 migration.

With OpenWrt 21.02, the ar71xx has now been removed and users must use ath79 instead. If you are still running with the ar71xx target, it is recommended to reinstall OpenWrt 21.02 from scratch. Users already on the ath79 target can use sysupgrade to upgrade to OpenWrt 21.02.

Other targets were also removed: cns3xxx, rb532 and samsung.

ASLR activated

Network exposed user space applications are linked as position-independent executable (PIE) to allow full Address Space Layout Randomization (ASLR) support. This makes it harder for attackers to exploit OpenWrt. See Hardening build options for more details.

Kernel with container support

Multiple Linux kernel compile options, needed for Linux Containers (LXC) and procd-ujail are activated by default for most targets. This allows to use LXC and ujail with the normal release builds.

SELinux support

It is possible to compile OpenWrt with SELinux support. This is currently not activated by default.

Core components update

Core components have the following versions in 21.02.0:

  • Updated toolchain:
    • musl libc 1.1.24
    • glibc 2.33
    • gcc 8.4.0
    • binutils 2.34
  • Updated Linux kernel
    • 5.4.143 for all targets
  • Network:
    • hostapd 2020-06-08, dnsmasq 2.85, dropbear 2020.81
    • cfg80211/mac80211 from kernel 5.10.42
    • wireguard backport from upstream Linux kernel
  • System userland:
    • busybox 1.33.1

In addition to the listed applications, many others were also updated.

Upgrading to 21.02.0

Sysupgrade can be used to upgrade a device from 19.07 to 21.02, and configuration will be preserved in most cases.

  • Sysupgrade from 18.06 to 21.02 is not supported.

  • There is no migration path for targets that switched from swconfig to DSA. In that case, sysupgrade will refuse to proceed with an appropriate error message:
    Image version mismatch. image 1.1 device 1.0 Please wipe config during upgrade (force required) or reinstall. Config cannot be migrated from swconfig to DSA Image check failed

  • The default root file system partition size changed for targets/devices relying on booting from mass storage (HDD, USB flash, SD card, etc.), so MBR will change and any additional partition will be deleted when sysupgrading.

Known issues

Full release notes and upgrade instructions are available at

In particular, make sure to read the regressions and known issues before upgrading:

For a detailed list of all changes since 19.07 was branched off, refer to:

To download the 21.02.0 images, navigate to:

To stay informed of new OpenWrt releases and security advisories, there
are new channels available:

As always, a big thank you goes to all our active package maintainers, testers, documenters, and supporters.

Have fun!

The OpenWrt Community


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/'

There should be in /etc/config/dhcp:

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

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


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


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?

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:;a=shortlog;h=refs/tags/v21.02.0

plus the fixes in packages/LuCI


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


  • 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".


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 I need to do gpg --receive-keys 88CA59E88F681580 but I get gpg: error reading key: No public key, I tried gpg --keyserver --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

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.