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:
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.
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.
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?
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 https://buildbot.staging.openwrt.org/images/#/builders .
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?
$ 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 .profiles.mk
-rw-r--r--. 1 d d 0 Nov 15 17:20 .profiles.mk
$ make .profiles.mk
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/.profiles.mk'.
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:
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.
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.
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.
edit
Just noticed a particular route isn't created with 23.05.2:
Destination Gateway Genmask Flags Metric Ref Use Iface
default * 128.0.0.0 U 0 0 0 wg0
23.05.0 working route
Destination Gateway Genmask Flags Metric Ref Use Iface
default * 128.0.0.0 U 0 0 0 wg0
128.0.0.0 * 128.0.0.0 U 0 0 0 wg0
edit2
It seems if I set the wireguard allowed_ips to 0.0.0.0/0 the issue is resolved.
If I reintroduce my default wireguard allowed_ips of 0.0.0.0/1 & 128.0.0.0/1 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:
STDERR:
Generate local signing keys...
Generate local certificate...
Package list missing or not up-to-date, generating it.
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
auc/0.3.2-1
Server: https://sysupgrade.openwrt.org
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 https://sysupgrade.openwrt.org/store/134fd74a087f2c5c1c56d19035ebdd26/openwrt-23.05.2-066d079c67e9-x86-64-generic-ext4-combined-efi.img.gz
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.
I have a route configured for 172.24.128.128/26 but what is reflected on the actual routing table (via luci and cli) is 172.24.128.0/26. 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.
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.
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 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.
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.
and therefore some time was wasted in troubleshooting it.