I've made several upgrade attempts from 23.05.05 to 24.10.0 and have experienced network and DNS failures from downstream clients, making 24.10.0 unusable. I have observed while troubleshooting that unbound (which I use in conjunction with dnsmasq) is not present in the Luci Startup list.
Unbound is running and the init script is present.
Unbound is also failing to send IPv4 client queries onward for resolution. IPv6 seems to work fine. Rolling back to 23.05.05. IPv4 clients inquiries from the OpenWRT host itself work fine.
Tcpdump revealed that Unbound was returned NXDOMAIN after a brief delay for any IPv4 client query.
I'm having similar issues with 24.10.0
For some reason unbound isn't present in the Luci Startup list for me either.
But there is an init script at /etc/init.d/unbound, and there is a shortcut to it at /etc/rc.d/S19unbound. And unbound is started after booting and works correctly for me. But there is no unbound listed in Luci->System->Startup. Very odd.
Maybe an ubus issue, please post the output of:
ubus call rc list
# ubus call rc list
{
"adguardhome": {
"start": 19,
"stop": 89,
"enabled": true,
"running": true
},
"banip": {
"start": 95,
"enabled": true,
"running": true
},
"boot": {
"start": 10,
"stop": 90,
"enabled": true
},
"collectd": {
"start": 80,
"stop": 10,
"enabled": true,
"running": true
},
"cron": {
"start": 50,
"enabled": true,
"running": true
},
"ddns": {
"start": 95,
"stop": 10,
"enabled": true
},
"dnsmasq": {
"start": 19,
"enabled": true,
"running": true
},
"done": {
"start": 95,
"enabled": true
},
"dropbear": {
"start": 19,
"stop": 50,
"enabled": true,
"running": true
},
"etherwake": {
"start": 60,
"enabled": true
},
"firewall": {
"start": 19,
"enabled": true,
"running": false
},
"fstab": {
"start": 11,
"enabled": true
},
"gpio_switch": {
"start": 94,
"stop": 10,
"enabled": true,
"running": false
},
"led": {
"start": 96,
"enabled": true
},
"log": {
"start": 12,
"stop": 89,
"enabled": true,
"running": true
},
"luci_statistics": {
"start": 79,
"stop": 11,
"enabled": true,
"running": false
},
"network": {
"start": 20,
"stop": 90,
"enabled": true,
"running": true
},
"packet_steering": {
"start": 25,
"enabled": true,
"running": false
},
"rpcd": {
"start": 12,
"enabled": true,
"running": true
},
"sqm": {
"start": 50,
"enabled": true,
"running": false
},
"sysctl": {
"start": 11,
"enabled": true
},
"sysfixtime": {
"start": 0,
"stop": 90,
"enabled": true
},
"sysntpd": {
"start": 98,
"enabled": true,
"running": true
},
"system": {
"start": 10,
"enabled": true,
"running": false
},
"ucitrack": {
"start": 80,
"enabled": true,
"running": false
},
"uhttpd": {
"start": 50,
"enabled": true,
"running": true
},
"umount": {
"stop": 90,
"enabled": false
},
"unbound": {
"enabled": false
},
"urandom_seed": {
"start": 99,
"enabled": true,
"running": false
},
"urngd": {
"start": 0,
"enabled": true,
"running": true
},
"vnstat": {
"start": 60,
"stop": 50,
"enabled": true,
"running": true
},
"wpad": {
"start": 19,
"stop": 21,
"enabled": true,
"running": true
},
"zabbix_agentd": {
"start": 60,
"enabled": true,
"running": true
}
}
# ls /etc/rc.d
K10collectd K90sysfixtime S19dropbear S79luci_statistics
K10ddns K90umount S19firewall S80collectd
K10gpio_switch S00sysfixtime S19unbound S80ucitrack
K11luci_statistics S00urngd S19wpad S94gpio_switch
K21wpad S10boot S20network S95banip
K50dropbear S10system S25packet_steering S95ddns
K50unbound S11fstab S50cron S95done
K50vnstat S11sysctl S50sqm S96led
K89adguardhome S12log S50uhttpd S98sysntpd
K89log S12rpcd S60etherwake S99urandom_seed
K90boot S19adguardhome S60vnstat
K90network S19dnsmasq S60zabbix_agentd
Weirdly it doesn't seem to pick up K50unbound or S19unbound. As I said, unbound is started automatically and running perfectly fine.
Thanks, than it's a regression in the new rc ubus method. LuCI in 23.x used another ubus method:
ubus call luci getInitList
... and this will probably bring back the correct values - even for unbound. Best is to open a bug.
Could the ubus regression somehow affect IPv4 client resolution for unbound?
Nope, thats unrelated.
What IPv4 issues? If you open a ticket you should fill out the issue template, describe your problem and tests in detail and finally tag at least the package maintainer.
BTW, ubus related tickets should be opened in the main repo.
The issue is that downstream IPv4 receive NXDOMAIN for whatever they try to resolve, even though unbound can otherwise resolve the query if made from the openwrt host. IPv6 clients works fine.
Did you solve this downstream ipv4 queries? I can also confirm it happens in my setup.
I have abandoned 24.10.0 until such time as I hear about a resolution. I have not seen any discussion about a resolution in the bug thread.
Which bug thread?
Although it isn't showing up in the list. It's still running in the background though right? Does it show up as a process? I'm using smartdns, it doesn't show up in the Luci startup page but it is still running.
Likely related to the ubus issue mentioned above.
A clue about dnsmasq to make it partially work: