OpenWrt 23.05.2 - Service Release

23.05.2 upgrade succeeded on an Archer C7 v2
Log is clean as ****, yay!

Thank you so much for the reply and for the info!

I'm glad to hear that the support for it is excellent and having the same WiFi is definitely a plus for seamless roaming.

Also, that is a very good suggestion to have a hot standby setup. Thank you for that.

I use an EdgeRouter X with the mt7621 and had very good experience with it, and also a Xiaomi AX3200 with mt7622.

The mt7622 also seems to work great with OpenWrt and might be a viable option as well, as a somewhat faster chipset. However, with Hardware Offload, it doesn't make any difference.

1 Like

Yep, I missed the RT3200 (MT7622) EU shore boat so I went with the RT1800, else I would have got the RT3200, but as you said it wouldn't have made any difference as I still wouldn't have used QoS.

It'd have better WiFi but I only have 2x2 clients and not so many, so still no difference. While the RT1800 USB 3 (vs. USB 2 on the RT3200) is useful for the SSD connected to it.

Sorry mods for the off topic, anyway the thread has quieted down since release.

1 Like

x86, works well with exhausting overloads
massive adguard (~2mil. items list)
massive crowdsec (about 1.4TB rules)
hardcore irqbalance
custom ruled sqm for 40-60 users
1+Gbit/s 24/7 file sharing/editing/working with samba
with 0 restarts since release, 0 issues! (some warnings ofc, but no heavy issues)

thanks for all the developers, such a great project, and such a great release!

1 Like

Unattended upgrade failed on TP-Link Archer C6 v3 from 22.03.5 due to wolftls.
Why mbedtls replaced wolftls?

Collected errors:
 * opkg_install_cmd: Cannot install package luci-i18n-ddns-en.
 * opkg_install_cmd: Cannot install package luci-i18n-watchcat-en.
 * check_data_file_clashes: Package libustream-mbedtls20201210 wants to install file /builder/build_dir/target-mipsel_24kc_musl/root-ramips/lib/libustream-ssl.so
	But that file is already provided by package  * libustream-wolfssl20201210
 * opkg_install_cmd: Cannot install package luci-ssl.
make[2]: *** [Makefile:189: package_install] Error 255
make[1]: *** [Makefile:154: _call_manifest] Error 2
make: *** [Makefile:274: manifest] Error 2

https://forum.openwrt.org/t/openwrt-23-05-0-first-stable-release/174239?u=eginnc

2 Likes

"TLS 1.3 Support: Users should be aware that mbedtls 2.28 no longer supports TLS 1.3."
...and user can change it. BUT, this way acu cannot deliver automatic upgrade.
Can we replace wolftls in 22.03.5 with mbedtls and execute acu with success or install 23.05.2 and then restore our config?

This is the best approach between major version upgrades.

1 Like

My umdns problem did not appear to appeal to anyone here :grinning:

I pushed my investigation further. I tried resetting my configuration, in case it was something from my config causing this bug.

From a clean OpenWrt 23.05.2, with only IP configuration after first startup, and installation of only umdns and its dependencies from opkg, I can still reproduce the bug on my Xiaomi Mi Router 3G. So I think my configuration is out of suspicion.

I also have a Buffalo WZR-300HP, which is not an mt7621 device like my other two routers (target ath79/generic). Did the same test on it... umdns works perfectly fine, I cannot reproduce this bug on it. Which makes me think that this bug could be specific to target ramips/mt7621

I filed a bug with the information I gathered: https://github.com/openwrt/openwrt/issues/14120

Yes I kept settings, all upgrades i did before the latest, it worked just fine with "keep settings". I am going to buy another router and will test it without keep settings.

Sometimes keep settings will work. Sometimes it does not. The developers change the default configuration files from time to time - especially from one major release to another.

For this reason, it is a good idea to make a backup of your configuration and not keep settings when upgrading from one major release version to another (e.g., 22.x.x to 23.x.x). Then manually restore the desired configuration, using your backup as a guide (unless your backup does not apply, e.g., with a major change like swconfig to DSA). Do not just restore the backup, as that would defeat the purpose.

2 Likes

Just upgraded from 22.03.3 -> 22.03.5 -> 23.05.2 on my OptiPlex 7050 running x64 EFI. The first point upgrade executed 100% uneventfully but I had to opkg uninstall an old wolfssl package first (don't remember the name) before auc would work. Otherwise, everything else seems to have carried over without issues.

Upgraded from 22.03, then I found my 2.5G net card is set to HALF Duplex and cannot be changed, after a ton of research, I think it is a BUG of 23.05, please help to fix it on the next build, please refer to:

Thanks in advance.

What do you mean? It comes up right here:

https://firmware-selector.openwrt.org/?version=23.05.2&target=ipq40xx%2Fgeneric&id=linksys_ea8300

1 Like

Seems I miss read that there was an upgrade to the current software.
The thread that indicated that can no longer be found on my end.
Case closed.

1 Like

Probably the 22.03.6 thread, vs this 23.05.2 thread. I thought the same for a moment before I double checked and realised...

Since i installed 23.05.2 on my r7800 the irqbalance package is broken. I have the following errors in the system log:

Thu Dec  7 01:15:21 2023 daemon.warn /usr/sbin/irqbalance: Cannot change IRQ 44 affinity: Invalid argument
Thu Dec  7 01:15:21 2023 daemon.warn /usr/sbin/irqbalance: Cannot change IRQ 54 affinity: Invalid argument
Thu Dec  7 01:15:21 2023 daemon.warn /usr/sbin/irqbalance: Cannot change IRQ 46 affinity: Invalid argument
Thu Dec  7 01:15:21 2023 daemon.warn /usr/sbin/irqbalance: Cannot change IRQ 53 affinity: Invalid argument
Thu Dec  7 01:15:21 2023 daemon.warn /usr/sbin/irqbalance: Cannot change IRQ 48 affinity: Invalid argument
Thu Dec  7 01:15:21 2023 daemon.warn /usr/sbin/irqbalance: Cannot change IRQ 49 affinity: Invalid argument
Thu Dec  7 01:15:21 2023 daemon.warn /usr/sbin/irqbalance: Cannot change IRQ 50 affinity: Invalid argument
Thu Dec  7 01:15:31 2023 daemon.warn /usr/sbin/irqbalance: Cannot change IRQ 44 affinity: Invalid argument
Thu Dec  7 01:15:31 2023 daemon.warn /usr/sbin/irqbalance: Cannot change IRQ 54 affinity: Invalid argument
Thu Dec  7 01:15:31 2023 daemon.warn /usr/sbin/irqbalance: Cannot change IRQ 46 affinity: Invalid argument

Do sombody else has the problem?

Maybe the irq channels changed?

cat /proc/interrupts

Updated my Cudy WR1300 from 22.03.5 to 23.05.2, keeping my settings. No issues.

Not (likely) related to 23.05.2 by itself, but to the irqbalance 1.9.3 version bump that changed the handling/reporting of some errors by irqbalance.
I tried to fix it with https://github.com/openwrt/packages/pull/22851
More discussion in Irqbalance throwing errors on some routers after latest build following git pull

1 Like