OpenWrt 23.05.2 - Service Release


The OpenWrt community is proud to announce the newest stable release of the OpenWrt 23.05 stable series. It improves device support and brings a few bug fixes.

Download firmware images using the OpenWrt Firmware Selector:

Download firmware images directly from our download servers:

Main changes between OpenWrt 23.05.0 and OpenWrt 23.05.2

23.05.1 was tagged, but not officially released because we found a severe bug between tagging and announcing the release.

Device support

  • Support for the following devices was added:
    * bcm53xx: ASUS RT-AC3100
    * mediatek: CMCC RAX3000M
    * mediatek: MT7981 RFB
    * ramips: ComFast CF-E390AX
    * ramips: ComFast CF-EW72 V2
    * ramips: MeiG SLT866 4G CPE
    * realtek: HPE 1920-8g-poe+ (65W)
  • apm821xx: Netgear WNDR4700: Fix broken sysupgrade, factory images
  • armsr: Preserve configuration during sysupgrade
  • ath79: Compex wpj563: Enable 2nd USB controller
  • ath79: TP-Link Archer C7 v2: Fix wifi shutdown and "irq 23: nobody cared" error
  • bcm53xx: Make Linux use correct switch ports again
  • bcm53xx: Linksys EA9200: nvram and 02_network fixes
  • ipq40xx: Switch to performance governor by default
  • lantiq: xrx200: Build target again
  • mediatek: Xiaomi Redmi Router AX6000: Fix Ethernet in U-Boot
  • realtek: HPE 1920-8g-poe: Rename to match hardware
  • ramips: HiWiFi HC5861: Fix Gigabit Ethernet port
  • ramips: ZyXEL NR7101: Fix bricking typo

Various fixes and improvements

  • Fix assignment of default MAC addresses on some targets
  • build: Hide kmod-zram config unless enabled
  • build: Fix lto build
  • build: Fix glibc build
  • build: Fix pkg-config detection when inside of a nix-shell
  • build: Add CycloneDX SBOM JSON support
  • hostapd: Do not trim trailing whitespace, except for newline
  • hostapd: Fix OWE association with mbedtls
  • hostapd: Fix broken WPS on broadcom-wl and ath11k
  • hostapd: Fix broken noscan option
  • wifi: Fix applying mesh parameters when wpa_supplicant is in use
  • iptables: backport patch fixing bug with string module
  • mbedtls: Activate secp521r1 curve by default
  • px5g-mbedtls: Fix permission of private key
  • px5g-wolfssl: Fix permission of private key
  • netifd: Fixed race condition in default gateway configuration

Core components update

  • Update mbedtls from 2.28.4 to 2.28.5
  • Update openssl from 3.0.11 to 3.0.12
  • Update wolfssl from 5.6.3 to 5.6.4
  • Update Linux from 5.15.134 to 5.15.137
  • Update ipq-wifi from 2023-06-03 to 2023-11-10
  • Update uqmi from 2022-05-04 to 2022-10-20
  • Update umdns from 2023-01-16 to 2023-10-19
  • Update urngd from 2023-07-25 to 2023-11-01
  • Update ucode from 2023-06-06 to 2023-11-07
  • Update firewall4 from 2023-03-23 to 2023-09-01
  • Update odhcpd from 2023-06-24 to 2023-10-24
  • Update netifd from 2023-10-20 to 2023-11-10

Upgrading to 23.05.2

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

  • Sysupgrade from 21.02 to 23.05 is not officially supported.
  • ipq40xx EA6350v3, EA8300, MR8300 and WHW01 require tweak to the U-Boot environment on update from 22.03 to 23.05. Refer to the Device wiki or the instruction on sysupgrade on how to do this change. Config needs to be reset on sysupgrade.

Known issues

  • lantiq/xrx200 target shows error messages in DSA switch configuration of the integrated GSWIP switch. (see:
  • OpenWrt 23.05.2 was signed with the wrong signing keys. The keys from OpenWrt snapshot were used for OpenWrt 23.05.2, OpenWrt 23.05.0 and the release candidates. A later OpenWrt 23.05 service release will use a different key.

See up to date information here:

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

To download the 23.05.2 images, navigate to:
Use OpenWrt Firmware Selector to download:

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 you very much, Devs and Testers and all others involved, can report, that Attendet Sysupgrade worked well updating 23.05.0 to 23.05.2 on X86. Cheers!

Is this something to be weary of as a potential conflict during upgrades to/from 23.05.2? Or would it apply moreso to users that are independently verifying signed images, and can be safely disregarded otherwise?

@hauke, @nbd and other devs

Thank you for your awesome work.

I have a concern regarding the netifd package in 23.05.2 release factory and sysupgrade images in .

From what I understand, 23.05.2 was tagged right after 23.05.1 release due to "netifd: Fixed race condition in default gateway configuration" ( The related netifd package bump commit (I think) is;a=commit;h=842932a63d8993150ff339f11f0cd0d5dc45e6cc which bumped the pkgrel from 1 to to 1.1.

However the Packages Buildbot hasn't yet compiled the netifd pkgrel 1.1 with that fix yet. As an example, I still see netifd pkgrel 1 file (NOT pkgrel 1.1) at (as the packages buildbot for aarch64_cortex-a53 hasn't rebuilt the pkgs yet, after the netifd bump commit).

I have observed that it takes roughly 2 to 3 days from a git commit to the corresponding shared pkgs updated in the repos. I am not sure if the patched netifd pkg (pkgrel 1.1 instead of pkgrel 1) is included in the default factory and sysupgrade images generated by the images buildbot .

Also if I use ImageBuilder and / or Attended Sysupgrade to build custom images, will the updated netifd pkg be included in the built images or will imagebuilder pull netifd pkgrel 1 from the repos?

1 Like

Just upgraded to 23.05.2 from 23.05.0 on Xiaomi AX3200 (Mediatek mt7622 and mt7915E) and everything seems to be running properly at the moment.

Using a sysupgrade via luci and retaining the current configuration. Manually installed htop and luci-app-sqm afterwards.

@ka2107 I've just checked the installed netifd and it seems to be version 2023-11-10-35facc83-1.1

Thank you so much to the developers and the community for making this update possible!


Root cause was some missing dependencies - new machine/install of Fedora.

Missing deps were:

Original post follows:

Tried to build an image with local imagebuilder, seems to be hitting the same problem from here, but the workaround doesn't help now:

$ make image PROFILE=buffalo_wzr-hp-ag300h PACKAGES="htop luci-ssl mtr tcpdump luci-app-opkg wpad-mbedtls -wpad-basic-mbedtls"
Profile "buffalo_wzr-hp-ag300h" does not exist!
Use "make info" to get a list of available profile names.
make[1]: *** [Makefile:238: _check_profile] Error 1
make: *** [Makefile:260: image] Error 2
$ make info
Current Target: "ath79/generic"
Current Architecture: "mips"
Current Revision: "r23630-842932a63d"
Default Packages: base-files ca-bundle dropbear fstools libc libgcc libustream-mbedtls logd mtd netifd opkg uci uclient-fetch urandom-seed urngd busybox procd procd-ujail procd-seccomp kmod-gpio-button-hotplug swconfig kmod-ath9k uboot-envtools wpad-basic-mbedtls dnsmasq firewall4 nftables kmod-nft-offload odhcp6c odhcpd-ipv6only ppp ppp-mod-pppoe
Available Profiles:

(no profiles output)

$ ls -l 
-rw-r--r--. 1 d d 0 Nov 15 17:20
$ make
make: Nothing to be done for '/home/d/openwrt/imagebuilder/23/23.05.2/ath79/openwrt-imagebuilder-23.05.2-ath79-generic.Linux-x86_64/'.

25.03.0 didn't have this problem.

As a followup to my post, I tried building custom images using ImageBuilder for Belkin RT3200 and TP-Link Archer A7 v5. While checking the build log I noticed that the ImageBuilder pulls the netifd package from the repos.

At the time of this post, the corresponding netifd pkg being pulled is:

Belkin RT3200 (Image Target: mediatek/mt7622; Package Arch: aarch64_cortex-a53)
(unpatched netifd pkg)

TP-Link Archer A7 v5 (Image: Target: ath79/generic; Package Arch: mips_24kc)
(patched netifd pkg)

I have updated the TP-Link Archer A7 v5 routers. I will hold off on updating my Belkin RT3200 and Dynalink DL-WRX36 routers (both use aarch64_cortex-a53 pkg arch) until the Packages Buildbot has rebuilt the packages.

1 Like

Netgear R7800 still has
Package: netifd
Version: 2023-11-10-35facc83-1

Addendum: netifd v1.1 available with opkg update

Upgraded my WRT1900ACS v1 and WAC104. No issues. In fact, an issue I was having with Ticketmaster thinking any and every system on my network was a bot has vanished. I checked before and after the upgrade retaining configurations. Thank you for whatever was done to fix my issue, I can now buy tickets and view them on Ticketmaster without having to switch my mobile phone to cellular data. :slight_smile:

1 Like

DL-WRX36 here....

used Attended Sysupgrade via luci and retaining the current configuration.

Website addresses are being resolved via command line, yet same web addresses not displaying web pages in browser, e.g. google & numerous other sites.

Normally run through a VPN, however displaying websites only worked when I added lan=>wan firewall zone forwarding.

Using 23.05.0 working with same config.

Just noticed a particular route isn't created with 23.05.2:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         *            U     0      0        0 wg0

23.05.0 working route

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         *            U     0      0        0 wg0       *            U     0      0        0 wg0

It seems if I set the wireguard allowed_ips to the issue is resolved.

If I reintroduce my default wireguard allowed_ips of & this continues to work OK until restarting wireguard, where it will again stop displaying certain webpages.

Looks like an issue with OpenWrt not using the additional peer allowed_ips, easily reproducable.

fix: upgrade to latest netifd 2023-11-10-35facc83-1.1

I just installed it on a TGR1900 Onhub, Three google wifi and an X86. Used Attended Sysupgrade. On onehub everything went well. The three google wifi without connectivity via Luci and also via SSH. They continue to work, including the mesh, but without access.
X86 failed to generate firmware due to the following error:

Generate local signing keys...
Generate local certificate...
Package list missing or not up-to-date, generating it.

Building package index...
Updated list of available packages in /builder/build_dir/target-x86_64_musl/root-x86/../../../../builder/dl/openwrt_core
Signature check passed.
Updated list of available packages in /builder/build_dir/target-x86_64_musl/root-x86/../../../../builder/dl/openwrt_base
Signature check passed.
Updated list of available packages in /builder/build_dir/target-x86_64_musl/root-x86/../../../../builder/dl/openwrt_luci
Signature check passed.
Updated list of available packages in /builder/build_dir/target-x86_64_musl/root-x86/../../../../builder/dl/openwrt_packages
Signature check passed.
Updated list of available packages in /builder/build_dir/target-x86_64_musl/root-x86/../../../../builder/dl/openwrt_routing
Signature check passed.
Updated list of available packages in /builder/build_dir/target-x86_64_musl/root-x86/../../../../builder/dl/openwrt_telephony
Signature check passed.
Downloading file:packages/Packages
Updated list of available packages in /builder/build_dir/target-x86_64_musl/root-x86/../../../../builder/dl/imagebuilder
Downloading file:packages/Packages.sig
Signature check passed.
Pseudo file "dev" exists in source filesystem "/builder/build_dir/target-x86_64_musl/root-x86/dev".
Ignoring, exclude it (-e/-ef) to override.
error: ext4_allocate_best_fit_partial: failed to allocate 1560 blocks, out of space?
make[3]: *** [/builder/include/ /builder/build_dir/target-x86_64_musl/linux-x86_64/root.ext4] Error 1
make[2]: *** [Makefile:208: build_image] Error 2
make[1]: *** [Makefile:146: _call_image] Error 2
make: *** [Makefile:262: image] Error 2

It's late here. Tomorrow I'll see what possibly happened and get back with feedback.

Well, that's odd. I just updated an ext4 x86 vm using auc and it worked fine. I don't think there's any difference between LuCI ASU and auc on the backend builds, so it seems like yours should work.

$ auc -y
Running:   23.05.0 r23497-6637af95aa on x86/64 (generic)
Available: 23.05.2 r23630-842932a63d
Requesting package lists...
 luci-app-statistics: git-23.306.39416-25a465f -> git-23.315.63824-5a81162
... all the packages ...
 kmod-sched-core: 5.15.134-1 -> 5.15.137-1
Requesting build..................
Downloading image from
Writing to 'openwrt-23.05.2-066d079c67e9-x86-64-generic-ext4-combined-efi.img.gz'
Wed Nov 15 17:52:30 PST 2023 upgrade: Image metadata not present
Wed Nov 15 17:52:30 PST 2023 upgrade: Reading partition table from bootdisk...
Wed Nov 15 17:52:30 PST 2023 upgrade: Extract boot sector from the image
Wed Nov 15 17:52:30 PST 2023 upgrade: Reading partition table from image...
invoking sysupgrade

The images buildbot builds the kernel and core packages with full toolchain right from the sources at main OpenWrt repo tag, so the netifd version committed before the tag is included. Packages buildbot has no role in release/images building.

The packages buildbot build downloadable opkg packages quite separately. (But then the imagebuilder/ auc / attendedsysupgrade / opkg user tools do use build artefacts from the packages buildbot, so the netifd shows up later in them.


There seems a problem on routing.

Update: Hid further text as it is fixed already.

I have a route configured for but what is reflected on the actual routing table (via luci and cli) is The last octet is not honored.

The same happens also in Wireguard peers.

It is working on 23.05.0 though.

For the meantime, my workaround is to adjust the subnet mask from /26 to /24 just to make all my existing routes work. I hope this gets fixed soon.


Viewed in Luci

Viewed in cli

Fix is in this commit.

TL-WR1043ND v3 sysupgrade from 23.05.0 to 23.05.2. PPPoE performance has degraded even further, from 200 Mbps to 175 Mbps (software flow offloading is enabled).
I assume this is caused by the firewall4 update from 2023-03-23 to 2023-09-01. It seems like every new firewall4 update slows down PPPoE even further.

If anyone wants to jump and tell me to buy another router and that this is normal - no, it's NOT normal, this is a bug, a regression or whatever one wants to call it. OpenWrt 21.x can do > 700 Mbps on this same device and even DD-WRT is way above 500 Mbps with a PPPoE connection to the ISP.

There are solutions to this bug/regression but unfortunately none is applied to new releases:

Has anyone managed to create or find LXC image for 23.05.2 (used in proxmox container). The images mentioned in the official docs are outdated.

Successfully used an attended sysupgrade on Netgear WAX202 (WDS repeater) and Linksys E8450 UBI (main router). On the main router, the IPSEC VPN did not start, but it is just a coincidence - the VPN server went down at the same time as I upgraded OpenWrt :confused: and therefore some time was wasted in troubleshooting it.

Zyxel NR7101 upgrade from 22.03.5 worked fine using auc -b 23.05 and accepting the recommended packet substitutions. Bonus: modemmanager in 23.05 is recent enough to support the dispatcher scripts necessary to enable automatic reconnection.

1 Like

Nobody said this is normal. You are obviously right in your observation and it’s an issue. I said that these QCA9558 devices with 10 years old 720 MHz MIPS32 single core SoC, only b/g/n WiFi and 8/64 configuration are at the end of their life cycle. Limited developer time is better invested into performance optimization for devices with more promising future.

I still think it’s not a good idea to disable frame checksum processing for increasing performance. This is not an optimization but a cut off basic features. Frames with invalid checksum should not be processed and error counters should be increased for analysis if broken frames are received.

If you like to work on improving the firewall4 nftables PPPoE performance for ath79 target you are free to do.