What's new

dnsmasq issue

mwhaples

New Around Here
Hello, I wasn't quite sure where to post this, its a Asus firmware issue but it could lead into selecting new equipment. I am having issues with dnsmasq on my Asus ZenWiFi BT10. Every week or two devices on my network start having connection issues, both wired and wireless. By connection issue I mean DNS lookups start failing, when connecting new devices IP addresses are not being assigned, etc. Additionally in the log at the time of the issue I will see messages like:
Code:
Feb 24 13:05:37 dnsmasq[5902]: failed to send packet: Bad file descriptor
I have contacted Asus support. Their suggestion was to try turning off most things, from IPv6 to AI Protect, adaptive QOS, etc or to try other firmware versions. The only thing I have not turned off which they suggested is IPv6, it should be a fairly core feature by now. turning things off isn't really a solution as I bought Asus stuff understanding it could do all these things and so if I must turn them off then I may as well have bought something else, may be cheaper. As for other firmwares, I am using the current one which was put out this month and before that the previous version. from a security point of view do I want to be using even older firmware?
I also have been through the reset the entire system and rebuild the config from scratch, no restoring from backups, but I still get the issue.
I would appreciate some advice on how to get a stable network. Here are some thoughts of mine:
  1. Anything else I can do to diagnose the issue? Its though feeling like a lost cause and would still need a fix working out, if at all possible. Is it time to move to other options.
  2. Have something else do DHCP on my network, may it be a wired router with the Asus stuff as wifi access points or use my home server to host a DHCP server.
  3. Replace the Asus stuff. Whilst in the past Asus stuff has served me well and when it works the current setup does the job well, this issue has really knocked my positive view of Asus routers. My concern here though being might I spend a lot of money and find the new stuff has equal issues.
I am probably favouring option 2, probably with a wired router for simplicity (can I be bothered to learn how to set up DHCP servers on Debian on my server). It may be the balance between quick and simple and keeping costs down, although I am not taken by the thought of yet another network box in the lounge.
 
I don't think this is anything to do with DHCP as such, that's just a symptom. From the error message I'd guess that there's been a problem with one of the router's network interfaces. Are you running a VPN client on the router?

Try looking further back in the logs for other error messages as I'd expect something happened prior to this message being generated.

If there's nothing obvious in the logs I'd definitely recommend disabling IPv6 as a test.
 
You can configure the router not to advertise itself as DNS server. Under LAN->DHCP Server you can turn off "Advertise router's IP in addition to user-specified DNS".
That should avoid a "mad client" messing up the router with many DNS requests. Some torrent clients are stupid enough by defaul trying to reverse the ip address of the peers into names. Router will just forward those request to whatever DNS servers you're using for WAN.

Another option: schedule a router reboot every week. It doesn't hurt and you can do that during the night when nobody cares. I'm doing this for I forgot how many years for several routers models I had.

Having different DNS server in the LAN would help you figure out if some clients are "mad" by having better logs than Asus has. But that adds another weak link and require a different device to be up 24x7. If you prefer this option, it can be easily done.
 
Thanks for your reply, it helped me understand may be what is going on and make sense of the logs. Here are a few more entries from the log, the entry immediately preceeding these was at 12:47 (over 15 minutes earlier).
Code:
Feb 24 13:05:37 ddns: ppp0 has not yet obtained an WAN IPv6 address.(10)
Feb 24 13:05:37 ddns: current ipv6_service: dhcp6 | old ipv6_service: dhcp6
Feb 24 13:05:37 ddns: IP address, server and hostname have not changed since the last update.
Feb 24 13:05:37 dnsmasq[5902]: failed to send packet: Bad file descriptor
So may be there is no IPv6 address on the wan port at the time of the error. The above entries seems to be a common sequence for three log examples I have.
The ddns service I am using is the Asus ddns.
I have no VPN clients on the router, only a VPN server being hosted and nobody should have been connected at the time.
I will test without IPv6 as it looks like may be it could be an issue here. However feedback on whether that fixes it will be slow as normally its over a week between observing these issues. It though still leaves the issue of what to do if it is and if I want IPv6.
 
You can configure the router not to advertise itself as DNS server. Under LAN->DHCP Server you can turn off "Advertise router's IP in addition to user-specified DNS".
That should avoid a "mad client" messing up the router with many DNS requests. Some torrent clients are stupid enough by defaul trying to reverse the ip address of the peers into names. Router will just forward those request to whatever DNS servers you're using for WAN.
That is a thought, but will it mean I will loose the ability to refer to devices on my LAN by hostname? Would prefer that over remembering the different IPs.
Another option: schedule a router reboot every week. It doesn't hurt and you can do that during the night when nobody cares. I'm doing this for I forgot how many years for several routers models I had.
I have heard that as a common fix to many Asus issues. Not sure it really sits well with me as a long term fix, particularly if the cause isn't known, the weakness still exists. However may be a good option to give me time to consider alternatives or waiting for a good time to change.
Having different DNS server in the LAN would help you figure out if some clients are "mad" by having better logs than Asus has. But that adds another weak link and require a different device to be up 24x7. If you prefer this option, it can be easily done.
I do have a 24/7 Debian home server, mostly hosting home-assistant and related stuff which probably could easily take on the task should I choose to do it. I guess it will take more effort than the simple web UI of routers and why I hesitate.
 
Further thought: Whatever is upsetting dnsmasq, may be no IPv6 address on the WAN interface, why should this take down dnsmasq entirely until a restart? Would be good if dnsmasq could recover itself.
 
Further thought: Whatever is upsetting dnsmasq, may be no IPv6 address on the WAN interface, why should this take down dnsmasq entirely until a restart? Would be good if dnsmasq could recover itself.
This looks like an IPv6 issue on the ISP's side to me. That might also explain why new clients can't get an IP (v6) address, because the IPv6 addresses are coming from your ISP whereas IPv4 addresses come from dnsmasq.

How do you recover when this problem occurs. Reboot the router or just wait?
 
This looks like an IPv6 issue on the ISP's side to me. That might also explain why new clients can't get an IP (v6) address, because the IPv6 addresses are coming from your ISP whereas IPv4 addresses come from dnsmasq.
To be clear, new clients don't even get an IPv4 address when this happens. I can manually assign a IPv4 address on the client and also manually set a DNS server and it can get internet access. So it seems like dnsmasq may be entirely dead.
How do you recover when this problem occurs. Reboot the router or just wait?
In the past I have waited for over an hour without improvement. When it happens now I just do a reboot of the router. It normally picks an inconvenient moment to do this, so I just want to get on with things and even the reboot is annoying.
 
So may be there is no IPv6 address on the wan port at the time of the error.
The WAN port itself doesn't get an IPv6. The public IPv6 is on br0. This is a long standing issue on the DDNS client that asus are not interested in fixing. I had to install the NO-IP DUC on my home server to update my IPv6 there.
 
Further thought: Whatever is upsetting dnsmasq, may be no IPv6 address on the WAN interface, why should this take down dnsmasq entirely until a restart? Would be good if dnsmasq could recover itself.
If dnsmasq is still trying to forward queries to any IPv6 upstream servers set in the resolv file, it should fail, but maybe too many failures sends dnsmasq into a tailspin. See what's in /tmp/resolv.dnsmasq next time this happens, while it's still broken.
 
@dave14305 I should have explained it a little clearer. The method you explain is correct. My point (poorly made) is that the asus DDNS service, triggered by the ppp0 change of state looks to ppp0 when it should be looking at br0 for the true IPv6. That also explains the "ppp0 has not yet obtained an WAN IPv6 address." error. The built-in DDNS client will not work when set to IPv6.
If you can get it working I'd like to see how.
 
Last edited:
That is a thought, but will it mean I will loose the ability to refer to devices on my LAN by hostname? Would prefer that over remembering the different IPs.

I have heard that as a common fix to many Asus issues. Not sure it really sits well with me as a long term fix, particularly if the cause isn't known, the weakness still exists. However may be a good option to give me time to consider alternatives or waiting for a good time to change.

I do have a 24/7 Debian home server, mostly hosting home-assistant and related stuff which probably could easily take on the task should I choose to do it. I guess it will take more effort than the simple web UI of routers and why I hesitate.
Partially yes.
Clients will send identifier with the DHCP request. And DNS server will not see that.
But for certain devices (like a storage or a server) you can assign static IPs in the DHCP server in Asus and register that name in the DNS server.
Not too complicated, but clearly name resolution won't keep working the same way.

Or reboot the router weekly ;). No device is perfect, even in enterprise space often a reboot is often considered in early stages of troubleshooting.
 
Similar threads

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Back
Top