OpenWrt 21.02.3 Third service release


The OpenWrt community is proud to announce the third service release of OpenWrt 21.02. It fixes security issues, improves device support, and brings a few bug fixes.

We recently moved our bugs to GitHub, please report issues over there (after checking that nobody else posted the same issue before).

Download firmware images via the Firmware Selector or directly from our download servers:

Main changes from OpenWrt 21.02.2:

Security fixes

  • wolfssl: Fix multiple security problems (CVE-2022-25638, CVE-2022-25640)
  • openssl: Fix security problem (CVE-2022-0778)
  • zlib: Backport security fix for a reproducible crash in compressor

Device support

  • Support for the following devices was added:
    • Yuncore XD3200
    • Yuncore A930
    • MikroTik RouterBOARD mAPL-2nD (mAP lite)
  • ramips: Make memory detection more reliable
  • ramips: Fix reboot for remaining 32 MB boards
  • x86: Add pata_sis driver
  • ipTIME mt7620 devices: Fix flash detection
  • Turris Omnia: Improve detection of u-boot environment with U-boot 2021.09
  • Ubiquiti UniFi: Fix label MAC address
  • mvebu: udpu: Fix initramfs booting
  • a20-olinuxino-lime2: Fix Ethernet link detection on
  • TP-Link TL-WR1043ND v4: Fix TPLINK_HWREV field
  • OCEDO Raccoon: Fix link for long cables
  • Ubiquiti UniFi AP Outdoor+: Fix label MAC address
  • TP-Link WPA8630Pv2: Move to ath79-tiny target
  • Improve support for some GPON SFP modules

Various fixes and improvements

  • Fix SSL certificate validation with some sites especially sites using Let’s Encrypt certificates
  • hostapd fixes and improvemnts:
    • fix radius problem due to invalid attributes
    • Expose more data over ubus
  • base-files: Call “sync” after initial setup
  • imagebuilder: Fix broken image generation with external targets

Core components

  • Update Linux kernel from 5.4.179 to 5.4.188
  • Update openssl from 1.1.1m to 1.1.1n
  • Update cypress-firmware from 5.4.18-2020_0402 to 5.4.18-2021_0812
  • Update mac80211 from 5.10.85 to 5.10.110
  • Update wolfssl from 5.1.1 to 5.2.0

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 21.02.2, refer to

To download the 21.02.3 images, navigate to:

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

Have fun!

The OpenWrt Community

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


Thanks for the release.

Here, stable so far:

  • Linksys EA8500: main router
    BanIP, adblock, dhcp, wireguard + vpn-policy, ntp, Unbound DoT (2nd)
  • Asus GT-AC5300: Unbound DoT (1st), adblock

looks like it doesn't have this version yet. I noticed where was some delay for them in last version too, how long it takes for them to get newest version?

1 Like

Until the service admin manually adds the new version number, that could be in the next 5 minutes or may take until the ~weekend.


In the wiki for my router and still the old versions linked.

If you search under 21.02.3 in releases, you'll find...

There is no "auto-update" process for documentation when a release is announced.


One year and flow offloading not work... Stick to swconfig and old releases, but thanks.


Hi all.
Successfully installed 21.02.3 on

  • Netgear WNR3700v2 (ath79 generic)
  • Netgear R6220 (mt7621)

I have / manage other devices, but I will rather install 22.03 rc1.
There is a lot of activity these days, with three versions release in a week !

Thanks to the dev team and any contributors.

On my WRT3200ACM, I tried using 21.02.3 with the exact same wireless config that has been rock solid on 21.02.2.

However, I have had constant wireless connectivity issues on 21.02.3 that I had no choice but to switch back to 21.02.2 on the other partition.

For now, I will wait for more feedback from other mwlwifi users before trying to upgrade again.

1 Like

It would be useful if these announcements flagged which changes are actually only available in the new base firmware and which are available as (i.e. opkg) updates and can be applied on top of a previous base firmware.

For example, if the three:

  • wolfssl: Fix multiple security problems (CVE-2022-25638, CVE-2022-25640)
  • openssl: Fix security problem (CVE-2022-0778)
  • zlib: Backport security fix for a reproducible crash in compressor

were all released as opkg updates for 21.02.2, then the urgency of a full firmware upgrade to 21.02.3 is less so and that would be useful to know.


wifi works great on raspberry pi 4b. I used the 64bit 21.02.3 image.

There have been some ramips issue discussions recently

Does anyone know, if some of these issues are already adressed in SR3?

Thank you. I upgraded a GL-MV1000 and a RB750Gr3. They seem to work OK (with WireGuard, adBlock, BanIP, vnStat, VPN Policy Routing).
But the IPV4 Traceroute under Network, Diagnostics, returns the following error message on the GL-MV1000 :

Error: XHR request timed out

I havent tested that on the Mikrotik yet.

Edit : it seems that this traceroute problem comes from the ProtonVPN WireGuard VPN that I have just recently started to use. Ping works but traceroute does not until the destination is finaly reached and answers.

I used image builder for Gl.Inet AR750 and 300N to include OpenVPN with this 21.02.3 version and deployed it on two test routers. I didn't find any problems, they both came right back up and reconnected their VPN connections.

I am using this snapshot OpenWrt SNAPSHOT, r19481-a5ac8ad0ba and its working fine on DIR-2660-A1 but 21.02.3 not sure.

Upgraded WAC104, no issues.
Upgraded WRT1900ACSv1, didn't come back from restart, activity LEDs out (not including LAN port LEDs). Power cycle fixed it.


Thank you very much to all devs and the community for 21.02.3
21.02.3 works fine on my device.
OpenWrt ist a great project! Thanks!

I did lots of upgrades, it took me about 8min. In the past the process was a few hours!

1 Like

Noticed this initially in 21.02.2, and is still happening in 21.02.3 on an Archer C7 v2 using either the CT or CT-smallbuffers drivers.

The single guest network on 5 GHz locks up on reboot.

Nothing else is active on 5 GHz.

Syslog shows the following error -

daemon.warn dnsmasq-dhcp[3573]: DHCP packet received on wlan0-1 which has no address

wlan0-1 being the guest wifi.

The network interface shows -

DEVICE_CLAIM_FAILED error where the IPv4 CIDR IP address should be.

Interestingly, I was able to track it down to channel and channel width.

The issue occurs if channel 149 or 153 is used with 40 MHz channel width.

It may occur on other channels as well.

Changing it to 20 MHz (on 149 and 153) resolved it.

Running wifi up when the channel width is set to 40 also resolves it...until the next reboot.


Thanks for the heads up.
Will use 19.07.10 with C7 for now.

1 Like