OpenWrt 23.05.2 - Service Release

@odrt Thanks for your input.

Please be aware that running OpenWrt as a container is not a supported configuration, issues range from services just not working (kernel modules not loading) to gaping security holes (firewall not being able to rely on the expected kernel behaviour), prefer full system virtualization (e.g. kvm) instead.

Upgrade from 23.05.0 to 23.05.2 went smoothly on Linksys E8450 UBI. Thanks to all who contributed to this release.

On WDR4300 V1, the 23.05.0 the Wifischedule function never detected connected devices properly and just switched off. Where can i find whether this got fixed in the 23.05.2 Version? Or where, if not here, shall i report this?

Thank you, Tobi

TPLink C2600 sysupgrade from 23.05.0 to 23.05.2 went perfect with 'keep settings'. Thanks.

I tried it now via AUC and the message is the same. Lack of space, it seems. My system has 128GB


Linksys WRT3200ACM sysupgrade from 23.05.0 to 23.05.2 keeping settings went perfectly, no issues so far. Thanks all!


Upgraded an x86 generic device from 23.05.0 to 23.05.2 using auc. A minor issue: the file /etc/board.json was formed incorrectly; for some reason, only two out of five ports were included.

This issue didn't exist in 22.x releases and first appeared in 23.05.0.

I haven't upgraded to 23.05.2 yet, but according to the logs the builds here (starting Nov 16) should be pulling the new version already (and - update - I just spun up a new container, on first glance it seems fine).

Archer C7 v2:

Tue Nov 14 14:38:55 2023 daemon.notice netifd: radio0 (3032): WARNING: Variable 'data' does not exist or is not an array/object
Tue Nov 14 14:38:55 2023 daemon.notice netifd: radio1 (3033): WARNING: Variable 'data' does not exist or is not an array/object

Don't see where data comes from.


config wifi-device 'radio0'
	option type 'mac80211'
	option channel '6'
	option hwmode '11g'
	option htmode 'HT20'
	option country 'VG'
	option txpower '15'
	option beacon_int '3000'
	option path 'platform/ahb/18100000.wmac'
	option cell_density '0'

config wifi-device 'radio1'
	option type 'mac80211'
	option hwmode '11a'
	option country 'XX' #redact
	option channel '60'
	option htmode 'VHT40'
	option path 'pci0000:00/0000:00:00.0'
	option cell_density '0'

Those "out of space" messages are coming from the build server, not your local device. Not sure why your builds aren't working, maybe look at the "extra" packages you're collecting into the build and remove some of the larger ones? My build only contains a few extra packages like snort, sqm and the usual network tools (conntrack, ethtool, nmap...).

Hi Nick, yeah, it gets whacked whenever /etc/board.d/99-default_network gets run, so I hacked mine and added it to /etc/sysupgrade.conf. This ensures things get set up properly on reboot/sysupgrade.

I been thinking that for 'generic' systems, there should be a network config setting for the NIC mappings so 99-default_network could look them up via uci and set them accordingly...

$ tail -7 /etc/board.d/99-default_network
#ucidef_set_interface_lan 'eth0'
#[ -d /sys/class/net/eth1 ] && ucidef_set_interface_wan 'eth1'
ucidef_set_interfaces_lan_wan "eth1 eth2 eth3" "eth0"


exit 0

$ grep board /etc/sysupgrade.conf

Ok, I just hacked up a proof-of-concept, no real error checking on the lan or wan values, but it seems to work.

$ uci show network.ports
network.ports.lan='eth1' 'eth2' 'eth3'

$ cat /etc/board.d/99-default_network
# Copyright (C) 2013-2015

. /lib/functions/


json_is_a network object && exit 0

if uci -q get network.ports > /dev/null; then
        wan=$(uci get network.ports.wan)
        lan=$(uci get network.ports.lan)
        ucidef_set_interfaces_lan_wan "$lan" "$wan"
        ucidef_set_interface_lan 'eth0'
        [ -d /sys/class/net/eth1 ] && ucidef_set_interface_wan 'eth1'


exit 0


I'm not sure if anyone is having the same thing but I'm noticing also some 40, 80 wide channels are missing on the 5ghz my testing device EA6350v3 and the 5ghz in the luci had missing the 80 Mhz, but I was able to use the terminal and use :

uci set wireless.radio1.htmode='VHT80'
uci commit wireless

then I logged into LuCi and the 80 Mhz was able to use it.

im running OpenWrt 23.05.2 (r23630-842932a63d), maybe is the first time I'm noticing this, but this is my device I use for testing

Qnap w301, AX9000, AX3600, WAX206 and WSM20 upgraded from 23.05.0 wiith luci using image created with firmware selector. No Issues found, (batman, adguardhome, banip, minidDLNA). 802.11s mesh in 5GHz. Thank you.

Asus RT-N18U is still borked. But Archer C7 v5 works fine. I am using PPPOE with vlan id 35. Also I tried to change lan4 port to use as wan instead, still won't work.

1 Like

@bosukes Have you tested PPPoE speeds on C7 v5 (wired)?

Like in speedtest? It gives 100 mbits easily.

@bosukes Yeah, I see wired speedtest capped around 175 Mbps. Previous version 23.05.0 could do 200 Mbps. What's your max PPPoE download?

Four Meraki MR-24 access points upgraded from 23.05.0 to 23.05.2. Went perfectly--many thanks devs!

1 Like

thanks - successful sysupgrade on:

  • Archer A7 v5 (since there's some PPP discussion - load of 1.5-1.6 at 90Mbit/s (provider limit), but that includes wireless overhead also)
  • D-Link DAP X1860
  • x64 LXC
1 Like