Issue with DNS or something else?

[vandriver]

Hello everyone, hope you are all well.

I was wondering if anyone could help with an issue I am currently facing and struggling to understand.

Without giving too much detail, basically I don't seem to be able to ping certain devices on my home lan via their hostname this afternoon.

This morning it was working fine, pinged and few different hostnames that are connected to different accesspoints/wifi addresses (no guest networks) and all responded.

Oddly, the devices that are connected to my main routers wifi are all still responding to pings, its just the devices that are connected to the access points that are currently not responding. Some devices on those access points are responding to host name pings. I have all these devices set up via host names on home assistant and it too says the devices are offline.

I can ping the ips of any devices on any routers or access points and it will respond, so they are online, just not responding to hostname pings.

Hostnames, are all on dnsmasq.config.add along with their macs and ip's.

On the access points, if I change the setting Connect to DNS Server automatically from yes to no, I can then ping those devices hostnames again but the network is very slow that setting is on no. I think it is yes by default anyway?

Main router has latest merlin, all access points have asus firmware, all are ac86u, I have amtm, diversion, backup mon running on main router and have trebble checked all my settings and dns servers etc and cross referenced many threads before asking here.

 

[ColinTaylor]

Without giving too much detail, basically I don't seem to be able to ping certain devices on my home lan via their hostname this afternoon.

What is the exact error message returned by the ping command?

 

[vandriver]

What is the exact error message returned by the ping command?

I just popped out, I will post the exact error in about in hour. If your still around then would really appreciate any help. Cheers

 

[ColinTaylor]

I just popped out, I will post the exact error in about in hour. If your still around then would really appreciate any help. Cheers

It would also be useful to verify DNS is working correctly by running nslookup for the non-working hostnames.

 

[vandriver]

It would also be useful to verify DNS is working correctly by running nslookup for the non-working hostnames.

I had the same issue as in my first post a few days ago, I ran nslookup then and the host names were resolving to my wan DNS isp. I found when I changed a setting in the access points the host names started resolving to the lan dns, but the network was very slow so I undid the setting change but then had to reboot the routers for something else and ended up the hostnames were working again and resolving to Lan DNS

But, I'm not sure if that's the case today. I will run ping and nslookup of a few of the problem devices when I get back and post some screenshots.

 

[vandriver]

non-working hostname. access point in bedroom.

ping bedroombulb1.home.lan
Ping request could not find host bedroombulb1.home.lan. Please check the name and try again.

ping 192.168.1.232
Pinging 192.168.1.232 with 32 bytes of data:
Reply from 192.168.1.232: bytes=32 time=381ms TTL=255
Reply from 192.168.1.232: bytes=32 time=97ms TTL=255
Reply from 192.168.1.232: bytes=32 time=101ms TTL=255
Reply from 192.168.1.232: bytes=32 time=108ms TTL=255

Ping statistics for 192.168.1.232:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 97ms, Maximum = 381ms, Average = 171ms


nslookup bedroombulb1.home.lan
Server: RT-AC86U-1348.home.lan
Address: 192.168.1.1
*** RT-AC86U-1348.home.lan can't find bedroombulb1.home.lan: Non-existent domain

 

[vandriver]

non-working hostname. access point in bedroom.

ping bedroomtelly.home.lan
Ping request could not find host bedroomtelly.home.lan. Please check the name and try again.

ping 192.168.1.113
Pinging 192.168.1.113 with 32 bytes of data:
Reply from 192.168.1.113: bytes=32 time=14ms TTL=255
Reply from 192.168.1.113: bytes=32 time=2ms TTL=255
Reply from 192.168.1.113: bytes=32 time=2ms TTL=255
Reply from 192.168.1.113: bytes=32 time=2ms TTL=255

Ping statistics for 192.168.1.113:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 2ms, Maximum = 14ms, Average = 5ms

nslookup bedroomtelly.home.lan
Server: RT-AC86U-1348.home.lan
Address: 192.168.1.1
*** RT-AC86U-1348.home.lan can't find bedroomtelly.home.lan: Non-existent domain

 

[vandriver]

working hostname. main router.

ping diningroomlamp.home.lan
Pinging diningroomlamp.home.lan [192.168.1.179] with 32 bytes of data:
Reply from 192.168.1.179: bytes=32 time=183ms TTL=255
Reply from 192.168.1.179: bytes=32 time=2ms TTL=255
Reply from 192.168.1.179: bytes=32 time=110ms TTL=255
Reply from 192.168.1.179: bytes=32 time=11ms TTL=255

Ping statistics for 192.168.1.179:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 2ms, Maximum = 183ms, Average = 76ms

ping 192.168.1.179
Pinging 192.168.1.179 with 32 bytes of data:
Reply from 192.168.1.179: bytes=32 time=3ms TTL=255
Reply from 192.168.1.179: bytes=32 time=81ms TTL=255
Reply from 192.168.1.179: bytes=32 time=2ms TTL=255
Reply from 192.168.1.179: bytes=32 time=100ms TTL=255

Ping statistics for 192.168.1.179:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 2ms, Maximum = 100ms, Average = 46ms

nslookup diningroomlamp.home.lan
Server: RT-AC86U-1348.home.lan
Address: 192.168.1.1
Name: diningroomlamp.home.lan
Address: 192.168.1.179

 

[vandriver]

working hostname. main router.

ping diningroomplaybar.home.lan

Pinging diningroomplaybar.home.lan [192.168.1.233] with 32 bytes of data:
Reply from 192.168.1.233: bytes=32 time=216ms TTL=255
Reply from 192.168.1.233: bytes=32 time=9ms TTL=255
Reply from 192.168.1.233: bytes=32 time=3ms TTL=255
Reply from 192.168.1.233: bytes=32 time=2ms TTL=255

Ping statistics for 192.168.1.233:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 2ms, Maximum = 216ms, Average = 57ms

ping 192.168.1.233

Pinging 192.168.1.233 with 32 bytes of data:
Reply from 192.168.1.233: bytes=32 time=2ms TTL=255
Reply from 192.168.1.233: bytes=32 time=3ms TTL=255
Reply from 192.168.1.233: bytes=32 time=2ms TTL=255
Reply from 192.168.1.233: bytes=32 time=2ms TTL=255

Ping statistics for 192.168.1.233:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 2ms, Maximum = 3ms, Average = 2ms


nslookup diningroomplaybar.home.lan
Server: RT-AC86U-1348.home.lan
Address: 192.168.1.1

Name: diningroomplaybar.home.lan
Address: 192.168.1.233

 

[ColinTaylor]

My first guess would be that these non-resolvable devices are DHCP clients and rebooting them will fix the name resolution issue.

 

[vandriver]

Sorry I should probably have mentioned there is nearly 100 devices went into this state this afternoon and im trying desperately not to reboot them and instead find the cause of why they got like this.

You got me thinking.

Yesterday I had the full network online, all looked well, no errors, so set the lease time on the router to 90 days.

Today, I had to reboot the router, but during the reboot only a handful of devices where online at that time, and now when I look on the routers lease page none of the problem devices are on the lease list, only the devices that are currently working with nslookup that are in the lease list.

Does the router not remember what lease times where issued to each device after a reboot and then continue with that time left when the device reconnects to the network again at a later date?
Its as if the router restarts the lease time when the router is rebooted, but only issues a lease time to the devices that are online, and any device that is currently off and had a 90 day lease time is not issued a new lease and doesnt respond to nslookup for 90 days?

To test that I just set the least time on main router to 120 seconds, rebooted the access point in the room that had various problem devices and now look they are responding to nslookup again:

ping bedroomtelly.home.lan

Pinging bedroomtelly.home.lan [192.168.1.113] with 32 bytes of data:
Reply from 192.168.1.113: bytes=32 time=9ms TTL=255
Reply from 192.168.1.113: bytes=32 time=7ms TTL=255
Reply from 192.168.1.113: bytes=32 time=7ms TTL=255
Reply from 192.168.1.113: bytes=32 time=2ms TTL=255

Ping statistics for 192.168.1.113:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 2ms, Maximum = 9ms, Average = 6ms

nslookup bedroomtelly.home.lan
Server: RT-AC86U-1348.home.lan
Address: 192.168.1.1

Name: bedroomtelly.home.lan
Address: 192.168.1.113

 

[ColinTaylor]

Does the router not remember what lease times where issued to each device after a reboot and then continue with that time left when the device reconnects to the network again at a later date?

That was the case with the older routers like the RT-AC68U because the lease file is stored in RAM. On the newer routers it's persistent.

It's not normally an issue even for the older routers if the clients are directly connected to the router. Because rebooting the router causes those clients to reconnect, renew their lease, and re-populate DNS. That usually doesn't happen for devices indirectly connected via an access point or switch.

The "manually assigned" option in the router's GUI avoids this problem (if you specify the host names) because it also populates the etc/hosts file with the host names, so they're always resolvable.

 

[dave14305]

On the newer routers it's persistent.

How newer? Mine is still on tmpfs.

 

[ColinTaylor]

How newer? Mine is still on tmpfs.

Yes you're correct. It's still in tmpfs even on my RT-AX86U.

I was remembering this thread where the file moved from /tmp/var/lib/misc to /var/lib/misc. But that's still tmpfs, my bad.

 

[vandriver]

The "manually assigned" option in the router's GUI avoids this problem (if you specify the host names) because it also populates the etc/hosts file with the host names, so they're always resolvable.

I had all my devices manually assigned on the routers GUI, but I had an issue where I wanted to start using host names, so I added about 200 host names to the GUI, then ran into the host name character limit in the hardware. I then moved all the manually assigned devices to dnsmasq.config.add and removed them all from the GUI to get round the character limit. I guess I could shorten the hostname character and add them back to the GUI.

Am I understanding this? If I want all my devices to be resolvable after a router reboot, they need to be listed in the GUI because it also populates etc hosts file with the host names? But dnsmasq.config.add doesnt populate the etc/hosts file with the host names so the only way to get my devices to resolve is to set the lease time to 120 seconds and reboot all the access points after rebooting the router? Thanks

 

[dave14305]

Yes you're correct. It's still in tmpfs even on my RT-AX86U.

I was remembering this thread where the file moved from /tmp/var/lib/misc to /var/lib/misc. But that's still tmpfs, my bad.

I still want this. I’ll move my file under /jffs and modify dnsmasq.conf via postconf to point to the new location and create a soft link from the old location so the GUI doesn’t get confused, since it hardcodes the path for certain functions.

 

[ColinTaylor]

I still want this. I’ll move my file under /jffs and modify dnsmasq.conf via postconf to point to the new location and create a soft link from the old location so the GUI doesn’t get confused, since it hardcodes the path for certain functions.

Ha, I used to do that on my old N66U using John's fork.... just because I could.

Am I understanding this? If I want all my devices to be resolvable after a router reboot, they need to be listed in the GUI because it also populates etc hosts file with the host names? But dnsmasq.config.add doesnt populate the etc/hosts file with the host names so the only way to get my devices to resolve is to set the lease time to 120 seconds and reboot all the access points after rebooting the router? Thanks

That's correct. The problem with only using dhcp-host statements is that the host name you specify doesn't populate DNS until the client requests its lease. So you can either manually add corresponding etc/hosts names for every dhcp-host line, or let the GUI option do both of those things for you.

There might be an addon script that does this sort of thing.

 

[dave14305]

just because I could.

A noble cause, sir.

#!/bin/sh

CONFIG="$1"
. /usr/sbin/helper.sh

[ -d "/jffs/dhcp" ] || mkdir /jffs/dhcp
[ -f "/jffs/dhcp/dnsmasq.leases" ] || touch /jffs/dhcp/dnsmasq.leases
[ -L "/var/lib/misc/dnsmasq.leases" ] || ln -sf /jffs/dhcp/dnsmasq.leases /var/lib/misc/dnsmasq.leases
pc_append "dhcp-leasefile=/jffs/dhcp/dnsmasq.leases" "$CONFIG"

 

[vandriver]

That's correct. The problem with only using dhcp-host statements is that the host name you specify doesn't populate DNS until the client requests its lease. So you can either manually add corresponding etc/hosts names for every dhcp-host line, or let the GUI option do both of those things for you.

There might be an addon script that does this sort of thing.

Morning, sorry had to get some sleep last night, up at 6am.

Can I translate what you said there into user perspective, just so I fully understand what's going on in my network?

Where to start?.....

If I use the routers GUI to manually assign ip's and hostnames, the router adds the host names to the etc/hosts file, so they're always resolvable. With this scenario, host names will permanently resolve across the network even if I reboot a router, reboot an access point, the device is offline/switched off to be switched on at a later date or if the device hard wired or connected via wifi?

If I manually assign ip's and hostnames to dnsmasq.config.add (without them manually being added to etc/hosts) and have no manual assignments in the GUI, then I have a very different network. With this scenario, the host names will no longer resolve across the network if any of the following actions happen:
I reboot the router, then only the devices that are switched on and connected to the network while the router is booting up will have host names that resolve. I'm finding if I switch a device on after the router has booted up, hostnames will not resolve for that device until its lease time ends. Additionally, even though that device is not showing in the current lease list after a router reboot, something somewhere has remembered that device had a 90 day lease so in effect the dns hostname for that device wont work unless I take these additional steps?
Change the lease time from 90 days to 120 seconds and reboot the main router to allow all devices on the networks 90 day lease to terminate and start again with a 120 second lease (I find this gets the lease table populated very quickly with most of my devices), then reboot the access points, which is a critical step or the devices hostnames connected to those access points still wont resolve.

Is that correct?

When I switch say a Wi-Fi plug on after the router has booted up, what part of the network, which device, is still remembering that Wi-Fi plug previously a 90 day lease before the router was rebooted but essentially puts that Wi-Fi plug it into limbo land where it's hostname wont resolve and it is not given a new lease because it wasn't simply on and connected to the router while the router rebooted. I feel you have already explained this but maybe I'm not understanding? I think its because the GUI adds entries to memory, while as just now I'm using scripts instead, but there appears to be some memory still at play here for the Wi-Fi plug that previously had a 90 day lease but now doesn't get a new one, its like the router didn't even know they where there?

Sorry just to add, I will look into adding the info permanently into etc/hosts or what scripts are available to make that work, thanks.

 

[ColinTaylor]

If I use the routers GUI to manually assign ip's and hostnames, the router adds the host names to the etc/hosts file, so they're always resolvable. With this scenario, host names will permanently resolve across the network even if I reboot a router, reboot an access point, the device is offline/switched off to be switched on at a later date or if the device hard wired or connected via wifi?

Correct.

If I manually assign ip's and hostnames to dnsmasq.config.add (without them manually being added to etc/hosts) and have no manual assignments in the GUI, then I have a very different network. With this scenario, the host names will no longer resolve across the network if any of the following actions happen:

I reboot the router, then only the devices that are switched on and connected to the network while the router is booting up will have host names that resolve. I'm finding if I switch a device on after the router has booted up, hostnames will not resolve for that device until its lease time ends. Additionally, even though that device is not showing in the current lease list after a router reboot, something somewhere has remembered that device had a 90 day lease so in effect the dns hostname for that device wont work unless I take these additional steps?
Change the lease time from 90 days to 120 seconds and reboot the main router to allow all devices on the networks 90 day lease to terminate and start again with a 120 second lease (I find this gets the lease table populated very quickly with most of my devices), then reboot the access points, which is a critical step or the devices hostnames connected to those access points still wont resolve.

Is that correct?

I have seen bizarre behaviour like this reported many times for IoT devices, especially ones that are not directly connected to the router. The router can't magically change the lease duration a client thinks it already has. Only the client can initiate the renewal of its lease. This is why rebooting any switches or access points is often necessary because it disconnects the client from the network forcing it to reconnect and obtain a new lease (and by implication also populate DNS).

When I switch say a Wi-Fi plug on after the router has booted up, what part of the network, which device, is still remembering that Wi-Fi plug previously a 90 day lease before the router was rebooted but essentially puts that Wi-Fi plug it into limbo land where it's hostname wont resolve and it is not given a new lease because it wasn't simply on and connected to the router while the router rebooted. I feel you have already explained this but maybe I'm not understanding? I think its because the GUI adds entries to memory, while as just now I'm using scripts instead, but there appears to be some memory still at play here for the Wi-Fi plug that previously had a 90 day lease but now doesn't get a new one, its like the router didn't even know they where there?

It is entirely down to the client to keep track of its lease time and renew it at the appropriate time. Until such time (after a router reboot) the router's DHCP server will be unaware of the client's existence.