OpenWrt 23.05.0 - First stable release

Quick Question:
I have a Linksys WRT1900AC v1 and stayed on OpenWrt 21.02.7 because of some of the things i was reading about the 22.03 releases and the linksys wrt models (if my memory is correct). Should I jump from 21.02 to 22.03 to 23.05 preserving settings? Or should i upgrade 21.02.7 to 23.05 skipping the middle hop and not preserve settings, then rebuild my configs and installed packages?

I would just jump all the way, as an intermediate jump to 22.03 would just double the pain. You're going to be doing a lot of fiddling in either case, so might as well just go to latest and do it once.


I updated my Archer C7 V2 from 22.03.5 to 23.05.0.
I had to fix the LED assignments. (WAN LED ist still missing since V20.xx)
The MAC adress of the 5 Ghz Radio has changed.
Finally my guest wlan have had trouble, many pages are not reachable, and i dont know why.
After 2 hour searching the problem, a went back to 22.03.5.

I also saw changes in MAC addresses on one of my three RT3200s after upgrading. Why that?

One should not call this release "stable", as MT7621 has massive problems with WiFi and there are other issues, too with different chipsets...

Just my 0,02€

OpenWrt stable will get Linux kernel 6.1 in maybe one year, when 24.xx will branch off from master.

I think 23.05 branch will stay on 5.15.

ath79 target is not on 6.1 as default for now, please see the commits:

23.05.0 is stable since this branch has been in release candidate testing phase for over four months. 23.05.0-RC1 is from early June 2023.

The MT7915 AX upload performance bug for Apple devices was fixed during this time. This took over one year. My R7800 got another big performance issue with kernel 5.15 fixed, too. Just to name two stability improvements during RC phase I saw.

OpenWrt stable releases are stable compared to development master. Not stable as there will be no code changes in the stable branch or stable as all supported devices are completely bug free and always work flawless in any configuration or use case.


At least, there should be actually a warning pinned for MT7621 users not to upgrade

1 Like

WAN LED ist still missing in Archer C7 V2.

Please show the top three GitHub MT7621 issues that are open for 23.05 since the release candidate phase. I did not read about that much dissatisfaction during the four month release candidate phase.


I am not familiar with the Git stuff, sorry...
Search in this thread here for MediaTek or MT7621. No working wireless.
So I will not upgrade my Cudy 'til this is fixed...

You wrote that there are big problems so that MT7621 users should not upgrade to 23.05.0 at this time and there should be a warning not to do so.

Please show at least the most urgent show stopper threads in this forum about these issues.


Thanks for the upgrade. On Linksys WRT3200ACM it worked without problem.

The new version is still not available via Attended Sysupgrade for the AR150 and AR300 devices.

For example, see OpenWrt 23.05.0 - First stable release - #30 by agelwarg or
Wifi dead on Xiaomi MIR4A Gigabit?

Two persons doing a major version upgrade have problems. Nothing was analyzed, no root cause was found.

At first it needs to be determined what these two reports of problems are about. Is it the specific configuration or something else? Does the problem persist with a clean install without keeping existing settings?

I see no reason for your proposition to stop MT7621 upgrades to 23.05 in general at this time.

The solution is not to stop upgrades. The solution is to work on the issues. If you are affected: contribute to analysis and make proposals to a solution.

This is open source software. We are not paying customers, we are members of a community project. Encouraging others not to upgrade until issues are fixed by someone else does not help.


+1 on this. Lots of people (including me) run MT7621 devices on 23.05 with fully functioning wireless no problem. Just upgraded 3 Zyxel WSM20s (MT7621AT/MT7915) successfully. Don't be scared by anecdotal evidence disseminated by someone who just read a few posts by others.


The next one...

Wallbanger, are you just trolling at this point, shall I ignore you?

Do you own a MT7621 device, as a lot of these posts you are linking are from people upgrading, OpenWrt has transitioned its default cryptographic library from wolfssl to mbedtls which will affect wireless configurations if users have not read the notes available on the OP.

You are not adding anything worthwhile to this topic, you have not created your own topic advising your findings, please do so or please stop scaring people.


Mine works fine. So this is not a common problem. I advise you to go back to v21 and see if it works. It's possible for LEDs to die, even though they are relatively tough components with long MTBF.

If you bemoan the absence of a WAN LED to choose from in the LED config, that's another issue.

it has the following LED definitions in master, same as in v21.

		ucidef_add_switch "switch0" \
			"0@eth1" "2:lan" "3:lan" "4:lan" "5:lan" "6@eth0" "1:wan"

It has the following in DTS in master, same as in v21.

&mdio0 {
	status = "okay";

	phy0: ethernet-phy@0 {
		reg = <0>;

		qca,ar8327-initvals = <
			0x04 0x00080080 /* PORT0 PAD MODE CTRL */
			0x0c 0x07600000 /* PORT6 PAD MODE CTRL */
			0x50 0xc737c737 /* LED_CTRL0 */
			0x54 0x00000000 /* LED_CTRL1 */
			0x58 0x00000000 /* LED_CTRL2 */
			0x5c 0x0030c300 /* LED_CTRL3 */
			0x7c 0x0000007e /* PORT0_STATUS */
			0x94 0x0000007e /* PORT6 STATUS */

In neither version is the WAN LED defined.

Regarding the MAC change, v21 DTS for the Archer qca9558_tplink_archer-c.dtsi family has:

&eth0 {
	status = "okay";

	mtd-mac-address = <&uboot 0x1fc00>;
	mtd-mac-address-increment = <1>;
	phy-handle = <&phy0>;
	pll-data = <0x56000000 0x00000101 0x00001616>;


&eth1 {
	status = "okay";

	mtd-mac-address = <&uboot 0x1fc00>;
	pll-data = <0x03000101 0x00000101 0x00001616>;


&wmac {
	status = "okay";

	mtd-cal-data = <&art 0x1000>;
	mtd-mac-address = <&uboot 0x1fc00>;

In v23, qca9558_tplink_archer-c7-v2.dts gets an addition of &pcie1 in commit 297bceeecf29e9bfedba0b26c9d0a2cefeda2add.

&eth0 {
	nvmem-cells = <&macaddr_uboot_1fc00>;
	nvmem-cell-names = "mac-address";
	mac-address-increment = <1>;

&eth1 {
	nvmem-cells = <&macaddr_uboot_1fc00>;
	nvmem-cell-names = "mac-address";

&pcie1 {
	status = "okay";

	wifi@0,0 {
		compatible = "qcom,ath10k";
		reg = <0 0 0 0 0>;

		mac-address-increment = <(-1)>; //<-- decrement
		nvmem-cells = <&macaddr_uboot_1fc00>, <&calibration_art_5000>;
		nvmem-cell-names = "mac-address", "calibration";

&wmac {
	nvmem-cells = <&macaddr_uboot_1fc00>, <&calibration_art_1000>;
	nvmem-cell-names = "mac-address", "calibration";

Deal with it.

As @bedouin67 I was able to succesfully upgrade 3 Zyxel WSM20s with fully working wifi, but my AC85P has stopped working. As mentioned in my post the Zyxels were running snapshots, while the AC85P was on stable prior to upgrading. So at first glance it would seem upgrading from stable could potentially be an issue. I can provide any necessary detail and run any diagnostic I can throw at it if someone knows how to diagnose the issue.