OpenWrt 24.10.5 - Service Release

OH! I just had a big realization...

How old was your version of owut? Is that the memory leak in libuclient that caused behavior exactly like this (fix was in the 2025.10.24 version).

This is what it shows currently. I don’t know for sure what was it prior to OpenWrt upgrade,

root@OpenWrtVPN:~# owut --version
owut - OpenWrt Upgrade Tool 2025.12.01~4482dd09-r1 (/usr/bin/owut)
root@OpenWrtVPN:~#

Here is owut version from a not upgraded (24.10.4) router,

root@OpenWrt:~# owut --version
owut - OpenWrt Upgrade Tool 2025.10.24~07453922-r1 (/usr/bin/owut)
root@OpenWrt:~#

I have a weird situation with 24.10.5, when I add a 2nd dnsmasq section, the DHCP server config from all interfaces is wiped.
Vice versa, if I setup the DHCP server for an interface the dnsmasq entries are dropped and only the default remains.

Using a Zyxel T-56, with unbound and wireguard (wireguard not yet configured).

ubus call system board

{
	"kernel": “6.6.119”,
	"hostname": “OpenWrt”,
	"system": "ARMv8 Processor rev 4”,
	"model": "Zyxel EX5601-T0 ubootmod”,
	"board_name": "zyxel,ex5601-t0-ubootmod”,
	"rootfs_type": “squashfs”,
	"release": {
		"distribution": “OpenWrt”,
		"version": “24.10.5”,
		"revision": "r29087-d9c5716d1d”,
		"target": "mediatek/filogic”,
		"description": "OpenWrt 24.10.5 r29087-d9c5716d1d”,
		"builddate": “1766005702”
	}
}

cat /etc/config/network

config interface ‘loopback’

	option device ‘lo’
	option proto ‘static’
	option ipaddr ‘127.0.0.1’
	option netmask ‘255.0.0.0’


config globals ‘globals’

	option ula_prefix 'fd1b:6c6f:43d5::/48’
	option packet_steering ‘1’

config device

	option name 'br-lan’
	option type ‘bridge’
	option bridge_empty ‘1’
	list ports ‘lan1’
	list ports ‘lan2’
	list ports ‘lan3’
	list ports ‘lan4’

config interface ‘lan’

	option device 'br-lan’
	option proto ‘static’
	option ip6assign ’60’
	list ipaddr '192.168.2.1/24’

config interface ‘wwan’

	option proto ‘dhcp’

config device

	option name 'phy1-sta0’
	option ipv6 ‘0’

config interface ‘landing’

	option proto ‘static’
	option ipaddr ‘192.168.99.1’
	option netmask ‘255.255.255.0’
	option device 'br-landing’

config device

	option type ‘bridge’
	option name 'br-landing’
	option bridge_empty ‘1’
	option ipv6 ‘0’
	list ports ‘eth1’

cat /etc/config/dhcp

config dnsmasq

	option domainneeded ‘1’
	option localise_queries ‘1’
	option rebind_protection ‘1’
	option rebind_localhost ‘1’
	option domain ‘loopback.internal’
	option expandhosts ‘1’
	option cachesize ‘1000’
	option authoritative ‘1’
	option readethers ‘1’
	option leasefile '/tmp/dhcp.leases’
	option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto’
	option localservice ‘1’
	option ednspacket_max ‘1232’
	option port ‘0’

config dhcp ‘lan’

	option start ’10’
	option limit ‘150’
	option leasetime ‘1h’
	option dhcpv4 ‘server’
	option dhcpv6 ‘server’
	option ra ‘server’
	list ra_flags 'managed-config’
	list ra_flags 'other-config’
	option force ‘1’
	list dhcp_option ‘6,192.168.2.1’
	option authoritative ‘1’
	option rebind_protection ‘0’
	option localservice ‘0’
	option interface ‘lan’
	list notinterface ‘loopback’
	option port ‘0’

	list domain ‘internal’

config odhcpd ‘odhcpd’

	option maindhcp ‘0’
	option leasefile '/tmp/hosts/odhcpd’
	option leasetrigger '/usr/sbin/odhcpd-update’
	option loglevel ‘4’
	option piofolder '/tmp/odhcpd-piofolder’

config dhcp ‘landing’

	option start ’10’
	option limit ‘150’
	option leasetime ‘1h’
	option force ‘1’
	option authoritative ‘1’
	option rebind_protection ‘0’
	option localservice ‘0’
	list notinterface ‘loopback’
	option port ‘0’
	list dhcp_option ‘6,192.168.99.1’
	option interface ‘landing’

cat /etc/config/firewall

config defaults

	option input ‘REJECT’
	option output ‘ACCEPT’
	option forward ‘REJECT’
	option synflood_protect ‘1’

config zone

	option name ‘lan’
	option input ‘ACCEPT’
	option output ‘ACCEPT’
	option forward ‘ACCEPT’
	list network ‘lan’

config zone

	option name ‘wwan’
	option input ‘REJECT’
	option output ‘ACCEPT’
	option forward ‘REJECT’
	list network ‘wwan’
	option masq ‘1’

config forwarding

	option src ‘lan’
	option dest ‘wwan’

config zone

	option name ‘landing’
	option input ‘ACCEPT’
	option output ‘ACCEPT’
	option forward ‘ACCEPT’
	list network ‘landing’

config forwarding

	option src ‘landing’
	option dest ‘wwan’

I think I solved it…
When i went back to 24.10.4 (and later 24.10.3, because that was the initial version for my T-56) I still had the issue.
Looking at my other T-56, I saw that the names of the dnsmasq sections probably are the issue.
Interface and Firewall names can be the same, the dnsmasq section names must be unique.
Re-applying 24.10.5 now.

thanks owut, my WR1300 has now 24.10.5. No issues so far.

And thanx devs, of course

Well, both of those are new enough to have avoided the transparent crashing, but earlier ones certainly might show it. It was particularly an issue when the builds took a long time and owut was doing a lot of build status queries to the server, so if your builds took 4-5+ minutes, it was quite sure to happen.

1 Like

Installed a NanoPi R4s enterprise + 2* Ubiquiti AC LR without problems. Thanks for all devs! Merry Christmas!

NANOPI R1 ( no emmc ) FAILED upgrade from 24.10.4 to 24.10.5 using owut

owut check => ok
owut upgrade => all steps ok , last message was writing firmware ( no reboot msg )
after that no access , no eth0 , no wifi but heartbeat led is still working
forced reboot still not working same results.

What should i do now?

I had to rewrite the image 24.10.5 on my sdcard all is fine now , dont know what went wrong

Seems odd to get that far and then just fail. If you see it again let me know and we'll try to figure out what happened.

1 Like

I upgraded 4 Linksys E8450 (Belkin RT3200) devices through owut.

It was a smooth upgrade but I had to rollback on the gateway device because IPv4 from the internet back to client devices broke.

IPv4 traffic from client devices goes out through the E8450 gateway but nothing comes back from the router that connects it to the internet.

The internet LED lights up orange.

For the gateway itself everything is fine, it can connect to the internet through IPv4 and IPv6 without issues.

I turned to the excellent owut upgrade tool to downgrade back to 24.10.4 for now:

owut upgrade -V 24.10.4 --force

I wonder if anyone else experienced anything like this or knows what might cause this.

I upgraded a Belkin RT3200 about a week ago without any issue.

Is your time showing correct? Anything in the logs?

Upgraded two Cudy WR3000S v1 and one Linksys WRT1900AC v2 using owut without problems.

DAWN stopped working after the update.

I tried reinstalling, but it doesn't work.

I had zero issues with the upgrade to 24.10.5 from 24.10.4 via ASU. 1x GL-MT6000, 1x EX5601-T0, 2x DIR860L B1. Great work as always :+1:

SSH into the router and run ‘uci show dawn’, if you got a parse error, dawn crashed and it just looks like it’s working. Remove dawn from your software and re-install it, run ‘uci show dawn’ again, now it will show you the configuration stored in /etc/config/dawn, if you’re manually editing the configuration file and you happen to use fancy quotes for your options settings, you’ll get parse error, incorrect syntax will also get parse error, dawn will start and show it’s running, but actually crash. ‘ubus call dawn show_network’ should show you all the access points that have dawn installed and all the radios on those APs with clients that are connected, all of them, not just the one you’re running the command from.

Bummer, BananaPi R4 BE14 Wifi module with 6 dB tx limit (those sold with zeroed EEPROM power data) is still limited to 6 dB with 24.10.5, just tested it - it looks like we already have a fix for it for many months, but it does not flow into openwrt or upstream.

A user has only shared their own build with a fix in an issue report. Someone will need to volunteer to create a Pull Request of sufficient quality to be approved and committed by an OpenWrt developer - assuming the fix is not more appropriate to make in upstream linux - before there will be any fix in 24.10, 25.12 or main snapshot.

1 Like

Many users have tried to get a fix approved. I found several pull requests, all of which were eventually closed without being merged. The underlying issue seems to be that, since this is considered a “hardware bug,” no one wants to approve a software workaround. The manufacturer hasn’t addressed it either, so the issue has been stuck in limbo for over a year now.

1 Like

I’ve been using imagebuilder on a debian 13 system to build 24.10.{0..4} w/o issue, but 24.10.5 refuses to pass the python3-distutils check despite my having python3-setuptools installed and working on previous 24.10 versions. Does anyone know of a workaround for this?