What's new

Why dnsmasq fails when internet is down?

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Laxarus

Regular Contributor
Hello guys,
I used to have a dsl bridged modem sitting in front of my ac5300.
Now, I had to replace that with another dsl modem but without bridging capabilities.
I connected the LAN1 of modem to WAN of router.
To avoid double NAT, I DMZ'ed my router from the modem side.
Everything except local name resolution is working as expected.

I am not sure if this is normal behavior that is why I want to ask:
When I reboot my new modem (Internet goes down), why does my local name resolution is failing during reboot?
The local domain should resolve itself on the router, it should not go upstream.

With my previous setup, I didn't have this problem. Previously, PPPoE authentication was done in router but now it is done in modem. The only thing that changed is the WAN connection Type from PPPoE to Automatic IP.
 
To avoid double NAT, I DMZ'ed my router from the modem side.
Putting your router in the DMZ doesn't usually remove double NAT, it just means that you don't have to forward individual ports manually.

If you look at your router's syslog you should be able to see what is happening with dnsmasq.
 
Make sure your domain name w/ the AC5300 doesn't conflict w/ that of the ISP modem+router. Also, it wouldn't be a bad idea to add the following to DNSMasq w/ a postconf script if you're in the habit of using unqualified domain names when referencing local hosts (e.g., mypc rather than mypc.lan).

Code:
domain-needed
 
Make sure your domain name w/ the AC5300 doesn't conflict w/ that of the ISP modem+router. Also, it wouldn't be a bad idea to add the following to DNSMasq w/ a postconf script if you're in the habit of using unqualified domain names when referencing local hosts (e.g., mypc rather than mypc.lan).

Code:
domain-needed
Hmm, there is no domain set for the modem. But I will try this domain trick to see how it goes.
There is some su

Putting your router in the DMZ doesn't usually remove double NAT, it just means that you don't have to forward individual ports manually.

If you look at your router's syslog you should be able to see what is happening with dnsmasq.

Well, DMZ solves the port forwarding problem.

I tested this further but I am getting some weird behavior.

When I reboot modem, there is a brief moment local DNS resolution fails.
If I remove modem completely by removing the WAN port cable from the router, there is no problem with the DNS.
If I remove DSL line cable from the modem, again there is no problem with the DNS.
It only fails during modem rebooting process.
This tells me that something sketchy is going on. During reboot of the modem, on the router side, on the Internet Connection GUI, it says "Your ISP’s DHCP does not function properly."
This is normal for the router cannot get WAN IP due to modem is rebooting so DHCP of the modem is offline. However, it is probably at this time that local DNS on the router fails. I am not completely sure but there is a big chance for it.

dnsmasq should not send local domain dns queries to upstream anyway so why is it failing here?

Another weird thing is:
Some devices on my LAN fail to get a valid IP address from the router's DHCP server after modem reboot, which is totally weird because they are on different sides.

So, DNS fails, and occasionally some devices fail to get local IP addresses. This tells me that something is leaking but I am not sure what
 
Okay, this issue more serious than it seems after trying different things.
I just cannot understand why a modem reboot on the WAN side of the router brings down the whole network. It is not just the DNS. DHCP server on the router also fails. Most of the devices get ip addresses like this
168.254.108.240
I just cannot figure out why. Previously, with my bridged dsl modem, there was not a problem like that.
The only change was modem connected to WAN of the router and the WAN method on the router.
WAN method changed from PPPoE to Automatic IP. That is it.
 
Well, I think I found the culprit.
Though, I still have no idea how to solve it.

Code:
Mar 29 21:35:26 kernel: br0: received packet on vlan1 with own address as source address
Mar 29 21:35:26 kernel: br0: received packet on vlan1 with own address as source address
Mar 29 21:35:26 kernel: br0: received packet on vlan1 with own address as source address
Mar 29 21:35:26 kernel: br0: received packet on vlan1 with own address as source address
Mar 29 21:35:26 kernel: br0: received packet on vlan1 with own address as source address
Mar 29 21:35:26 kernel: br0: received packet on vlan1 with own address as source address
Mar 29 21:35:26 kernel: br0: received packet on vlan1 with own address as source address
Mar 29 21:35:26 kernel: br0: received packet on vlan1 with own address as source address
Mar 29 21:35:26 kernel: br0: received packet on vlan1 with own address as source address

There should not be any loop or ip conflict on the network because the modem ip is 192.168.0.1 whereas the router ip is 192.168.1.1.
Modem wifi is off and the only connection between them is a single LAN port to WAN port cable.
 
That is a common message that often just indicates that a client has roamed from one access point to another. What devices do you have plugged into your router's LAN ports?
 
I just cannot figure out how can a device behind WAN interfere with the DHCP server of the LAN devices and make them unable to get a proper ip.
 
This is making me crazy. Guys anyone have any idea regarding this behavior? Anyway to diagnose and pinpoint the issue?
 
Okay, I restarted the modem and started watching the logs.
Here:
Code:
Apr 11 23:18:10 ovpn-client1[5097]: Connection reset, restarting [0]
Apr 11 23:18:10 ovpn-client1[5097]: SIGUSR1[soft,connection-reset] received, process restarting
Apr 11 23:18:10 ovpn-client1[5097]: Restart pause, 5 second(s)
Apr 11 23:18:15 ovpn-client1[5097]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Apr 11 23:18:15 ovpn-client1[5097]: Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Apr 11 23:18:15 ovpn-client1[5097]: Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Apr 11 23:18:15 ovpn-client1[5097]: TCP/UDP: Preserving recently used remote address: [AF_INET]81.92.***.**:80
Apr 11 23:18:15 ovpn-client1[5097]: TCP/UDP: Preserving recently used remote address: [AF_INET]81.92.***.**:80
Apr 11 23:18:15 ovpn-client1[5097]: Socket Buffers: R=[87380->245760] S=[16384->245760]
Apr 11 23:18:15 ovpn-client1[5097]: Attempting to establish TCP connection with [AF_INET]81.92.***.**:80 [nonblock]
Apr 11 23:19:00 ovpn-client1[5097]: TCP: connect to [AF_INET]81.92.***.**:80 failed: Connection timed out
Apr 11 23:19:00 ovpn-client1[5097]: SIGUSR1[connection failed(soft),init_instance] received, process restarting
Apr 11 23:19:00 ovpn-client1[5097]: Restart pause, 5 second(s)
Apr 11 23:19:05 ovpn-client1[5097]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Apr 11 23:19:05 ovpn-client1[5097]: Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Apr 11 23:19:05 ovpn-client1[5097]: Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Apr 11 23:19:05 ovpn-client1[5097]: TCP/UDP: Preserving recently used remote address: [AF_INET]81.92.***.**:80
Apr 11 23:19:05 ovpn-client1[5097]: TCP/UDP: Preserving recently used remote address: [AF_INET]81.92.***.**:80
Apr 11 23:19:05 ovpn-client1[5097]: Socket Buffers: R=[87380->245760] S=[16384->245760]
Apr 11 23:19:05 ovpn-client1[5097]: Attempting to establish TCP connection with [AF_INET]81.92.***.**:80 [nonblock]
Apr 11 23:19:26 ovpn-client1[5097]: TCP: connect to [AF_INET]81.92.***.**:80 failed: No route to host
Apr 11 23:19:26 ovpn-client1[5097]: SIGUSR1[connection failed(soft),init_instance] received, process restarting
Apr 11 23:19:26 ovpn-client1[5097]: Restart pause, 5 second(s)
Apr 11 23:19:30 dropbear[10021]: Exit before auth from <192.168.1.45:48408>: Error reading: Connection timed out
Apr 11 23:19:31 ovpn-client1[5097]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Apr 11 23:19:31 ovpn-client1[5097]: Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Apr 11 23:19:31 ovpn-client1[5097]: Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Apr 11 23:19:31 ovpn-client1[5097]: TCP/UDP: Preserving recently used remote address: [AF_INET]81.92.***.**:80
Apr 11 23:19:31 ovpn-client1[5097]: TCP/UDP: Preserving recently used remote address: [AF_INET]81.92.***.**:80
Apr 11 23:19:31 ovpn-client1[5097]: Socket Buffers: R=[87380->245760] S=[16384->245760]
Apr 11 23:19:31 ovpn-client1[5097]: Attempting to establish TCP connection with [AF_INET]81.92.***.**:80 [nonblock]
Apr 11 23:19:54 syslog: wlceventd_proc_event(536): eth2: ReAssoc 98:01:A7:0F:**:**, status: Successful (0), rssi:0
Apr 11 23:19:55 syslog: wlceventd_proc_event(526): eth1: Auth 40:4D:7F:**:**:**, status: Successful (0), rssi:0
Apr 11 23:19:55 syslog: wlceventd_proc_event(536): eth1: ReAssoc 40:4D:7F:**:**:**, status: Successful (0), rssi:0
Apr 11 23:19:55 kernel: br0: received packet on vlan1 with own address as source address
Apr 11 23:19:57 syslog: wlceventd_proc_event(507): eth1: Disassoc 40:4D:7F:**:**:**, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Apr 11 23:19:57 syslog: wlceventd_proc_event(490): eth1: Deauth_ind 40:4D:7F:**:**:**, status: 0, reason: Class 2 frame received from nonauthenticated station (6), rssi:0
Apr 11 23:19:58 syslog: wlceventd_proc_event(526): eth2: Auth 00:CD:FE:**:**:**, status: Successful (0), rssi:0
Apr 11 23:19:58 syslog: wlceventd_proc_event(536): eth2: ReAssoc 00:CD:FE:**:**:**, status: Successful (0), rssi:0
Apr 11 23:20:02 syslog: wlceventd_proc_event(526): eth1: Auth 40:4D:7F:**:**:**, status: Successful (0), rssi:0
Apr 11 23:20:02 syslog: wlceventd_proc_event(555): eth1: Assoc 40:4D:7F:**:**:**, status: Successful (0), rssi:0
Apr 11 23:20:03 syslog: wlceventd_proc_event(507): eth1: Disassoc 40:4D:7F:**:**:**, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Apr 11 23:20:03 syslog: wlceventd_proc_event(490): eth1: Deauth_ind 40:4D:7F:**:**:**, status: 0, reason: Class 2 frame received from nonauthenticated station (6), rssi:0
Apr 11 23:20:04 syslog: wlceventd_proc_event(526): eth1: Auth 24:0A:C4:**:**:**, status: Successful (0), rssi:0
Apr 11 23:20:04 syslog: wlceventd_proc_event(555): eth1: Assoc 24:0A:C4:**:**:**, status: Successful (0), rssi:0
Apr 11 23:20:05 syslog: wlceventd_proc_event(526): eth1: Auth 40:4D:7F:**:**:**, status: Successful (0), rssi:0
Apr 11 23:20:05 syslog: wlceventd_proc_event(555): eth1: Assoc 40:4D:7F:**:**:**, status: Successful (0), rssi:0
Apr 11 23:20:06 syslog: wlceventd_proc_event(507): eth1: Disassoc 40:4D:7F:**:**:**, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Apr 11 23:20:06 syslog: wlceventd_proc_event(490): eth1: Deauth_ind 40:4D:7F:**:**:**, status: 0, reason: Class 2 frame received from nonauthenticated station (6), rssi:0
Apr 11 23:20:06 syslog: wlceventd_proc_event(490): eth1: Deauth_ind 40:4D:7F:**:**:**, status: 0, reason: Class 2 frame received from nonauthenticated station (6), rssi:0
Apr 11 23:20:07 syslog: wlceventd_proc_event(526): eth1: Auth 24:0A:C4:**:**:**, status: Successful (0), rssi:0
Apr 11 23:20:07 syslog: wlceventd_proc_event(555): eth1: Assoc 24:0A:C4:**:**:**, status: Successful (0), rssi:0
Apr 11 23:20:07 syslog: wlceventd_proc_event(526): eth1: Auth 9C:9C:1F:**:**:**, status: Successful (0), rssi:0
Apr 11 23:20:07 syslog: wlceventd_proc_event(555): eth1: Assoc 9C:9C:1F:**:**:**, status: Successful (0), rssi:0
Apr 11 23:20:08 syslog: wlceventd_proc_event(526): eth1: Auth F0:08:D1:**:**:**, status: Successful (0), rssi:0
Apr 11 23:20:08 syslog: wlceventd_proc_event(555): eth1: Assoc F0:08:D1:**:**:**, status: Successful (0), rssi:0
Apr 11 23:20:11 syslog: wlceventd_proc_event(526): eth2: Auth 94:B0:1F:**:**:**, status: Successful (0), rssi:0
Apr 11 23:20:11 syslog: wlceventd_proc_event(536): eth2: ReAssoc 94:B0:1F:**:**:**, status: Successful (0), rssi:0
Apr 11 23:20:37 syslog: wlceventd_proc_event(526): eth2: Auth B4:6B:FC:**:**:**, status: Successful (0), rssi:0
Apr 11 23:20:37 syslog: wlceventd_proc_event(555): eth2: Assoc B4:6B:FC:**:**:**, status: Successful (0), rssi:0
Apr 11 23:20:44 dropbear[10592]: Password auth succeeded for 'Admin' from 192.168.1.71:61762
Apr 11 23:21:00 roamast: [EXAP]Deauth old sta in 0 0: F0:08:D1:**:**:**
Apr 11 23:21:00 roamast: eth1: disconnect weak signal strength station [F0:08:D1:**:**:**]
Apr 11 23:21:00 roamast: eth1: remove client [F0:08:D1:**:**:**] from monitor list
Apr 11 23:21:01 roamast: [EXAP]Deauth old sta in 0 0: F0:08:D1:**:**:**
Apr 11 23:21:01 roamast: eth1: disconnect weak signal strength station [f0:08:d1:**:**:**]
Apr 11 23:21:01 roamast: eth1: remove client [f0:08:d1:**:**:**] from monitor list

The only thing that seems suspicious to me is:
Code:
Apr 11 23:19:55 kernel: br0: received packet on vlan1 with own address as source address
 
I don't see any DHCP messages at all in your log. Have you enabled the GUI option to suppress them, or have you changed the logging levels?
 
1618179627042.png

1618179651807.png

They are set like this.
 
For the sake of testing, could you assign a fixed (static) IP to the WAN port (the one DMZ-ed on the 1st router), then Mask and GW, but don't add any DNS yet, or at least don't point to 1st router, use a public DNS. You could later assign DNS1/2 to clients trough DHCP on the 2nd router. One possibility is that when Automatic IP is configured, 2nd router stucks because it still asks 192.168.0.1 DNS which, not being down (disconnected), doesn't trigger anything unknown (maybe a later time out, who knows). It might be a good thing to check with Network Monitoring from Administration menu (DNS query/IP ping to 1st router).
 
I would change them back to the defaults:

Default message log level = notice
Log only messages more urgent than = debug

Still don't know why there's no dnsmasq messages. Maybe it's simply because no client connected during that small segment of your log. There are no WAN related messages either. Do you have anything installed on the router that would be changing the behaviour of the syslog?
 
For the sake of testing, could you assign a fixed (static) IP to the WAN port (the one DMZ-ed on the 1st router), then Mask and GW, but don't add any DNS yet, or at least don't point to 1st router, use a public DNS. You could later assign DNS1/2 to clients trough DHCP on the 2nd router. One possibility is that when Automatic IP is configured, 2nd router stucks because it still asks 192.168.0.1 DNS which, not being down (disconnected), doesn't trigger anything unknown (maybe a later time out, who knows). It might be a good thing to check with Network Monitoring from Administration menu (DNS query/IP ping to 1st router).
I have changed the setup like this,
on the router:
1618182077181.png

1618182235030.png

The first DNS is the local adguard home DNS.

On the modem, I have removed dhcp assignment:
1618182180974.png


Changing the router WAN method to static IP and removing DHCP manual assignment on the modem itself didn't help.
When it was automatic ip, it was still using the same DNS. So, it should not change anything. I will test more. But I suspect there is a DNS leak.
Below is my DHCP DNS settings so every client should get the Adguard as their default DNS server.

1618182919077.png


I have tested this with nslookup.
during reboot of the modem all nslookup queries fail.
However, it should not fail when you query a local domain.

This is the IP settings after modem reboot.
1618183741483.png

I have to reboot the router again after rebooting modem to recover network.

The only thing in the log is this output when it fails:
Code:
Apr 12 02:25:35 kernel: br0: received packet on vlan1 with own address as source address
Apr 12 02:25:35 kernel: br0: received packet on vlan1 with own address as source address
Apr 12 02:25:35 kernel: br0: received packet on vlan1 with own address as source address
Apr 12 02:25:35 kernel: br0: received packet on vlan1 with own address as source address
Apr 12 02:25:35 kernel: br0: received packet on vlan1 with own address as source address
Apr 12 02:25:35 kernel: br0: received packet on vlan1 with own address as source address
Apr 12 02:25:35 kernel: br0: received packet on vlan1 with own address as source address
Apr 12 02:25:35 kernel: br0: received packet on vlan1 with own address as source address
Apr 12 02:25:35 kernel: br0: received packet on vlan1 with own address as source address
Apr 12 02:25:35 kernel: br0: received packet on vlan1 with own address as source address

I am stuck here.
 

Latest threads

Sign Up For SNBForums Daily Digest

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