Inconsistencies and broken behavior with client status and DHCP leases - AX86UP 388.6_2

[Aziron5]

Hi

It doesn't seem like connected LAN clients are speedily displayed and up-to-date, it requires rebooting the router.

It's a RT-AX86U Pro with Merlin's 3004.388.6_2 - All clients are wired ethernet, no wireless, currently no manual static LAN assignments (MAC IP binding). I do have YazDHCP installed but completely unconfigured.

• Major differences between Network Map->Client Status/List page/Dialog and System Log->DHCP Leases ... each one can have something missing.
• Some connected devices don't show up in DHCP Leases
• Some connected devices only show up in DHCP Leases
• Usually, DHCP Leases shows less items than the Client Status page
• Client List dialog incorrectly many devices as "static", without MAC & IP binding and them being configured for auto DHCP by the server, they don't specify a fixed IP.
• Clicking on the MAC Address for more info on the DHCP Leases page incorrectly shows "Logged In User: YES" for an older obsolete lease (I sometimes frequently switch between which computer I login to the WebGUI)
• Refreshing DHCP Leases has no effect
• Refreshing Client Status/List usually has no effect
• ... I might update to add more points as I see them

 

[ColinTaylor]

Most of what you're describing are issues with the Network Map which have been widely discussed for years. As was mentioned in reply to your other post this is mostly closed source code so only Asus can fix it as the problem comes from the stock firmware.

The DHCP leases list is usually correct but having an intermediate switch between the router and the client can sometimes cause inconsistencies.

 

[Aziron5]

Right, I've been looking around the forums for a few months and noticed the discussion of closed-source nature of some components and the limitations, but I didn't know this also extended to the Network Map and the basic status stuff.

Thanks for the explanation and perhaps just perhaps Asus might listen to these concerns being expressed once again.

 

[L&LD]

For Asus to listen, the issue must be reported (to them). They don't monitor these forums.

 

[bennor]

I do have YazDHCP installed but completely unconfigured.

Did the same issues you are asking about happen without YazDHCP installed? Or perhaps as a troubleshooting step, remove YazDHCP and see if the issues persists.

Not sure when it started but on my RT-AX86U Pro also running YazDHCP (and YazFi) I've noticed recently (as in the other day) that two devices (both manual IP address reserved Raspberry Pi's running Pi-Hole and Unbound), while they show up in the Network Map, do not show up in the System Log > DHCP Leases section. They are also not listed in the /var/lib/misc/dnsmasq.leases file either. And, the Network Map incorrectly lists their names as "Raspberry Pi Foundation" rather than their manually reserved IP Hostname's. Meanwhile it appears all other Network Map LAN devices are correctly using their manual IP address reserved Hostnames. Shrugs. For now the two missing PI's resolve their Hostnames and IP addresses correctly so not exactly sure when this issue started and what the cause is. Leaving it alone for now since everything else is working fine for many months.

 

[glens]

If the devices have their addresses "hard-coded" in, they won't be seeking a DHCP lease. Is this perhaps the case?

 

[bennor]

If the devices have their addresses "hard-coded" in, they won't be seeking a DHCP lease. Is this perhaps the case?

In my case I've checked the two Raspberry Pi's and it doesn't appear the IP address is Static (hard coded) on the device itself. Will get around to doing some more testing at some point on those two PI's. Edit: Its possible they're hard coded somehow even though I don't recall ever creating a static IP when setting them up. Will have to take another look at the Pi-Hole settings to see if that is impacting things.\

Update: Did some checking and it turns out in my case, my two Pi-Hole Raspberry Pi's do have static IP addresses set in the /etc/dhcpcd.conf file. It appears Pi-Hole forces it this way. Further investigation appears to indicate that trying to use the fallback IP address profile option of Dhcpcd doesn't work properly with Pi-Hole. The fallback profile would normally allow the client device to use the IP address issued by the DHCP server/router, and "fall back" to a fixed fallback IP configured in the dhcpcd.conf file if the router/DHCP server couldn't be reached. Pi-Hole throws errors for some reason when trying to use the Dhcpcd fallback IP address profile option. Oh well, stuck with fixed static IP's on the Pi's themselves for now due to Pi-Hole. Was able to at least use the Dhcpcd hostname option to set the Raspberry Pi's names to something other than "Raspberry Pi Foundation" so a proper name is now shown on the Asus router's Network Map. Example: hostname Pi3BPlus

 

[Aziron5]

Did the same issues you are asking about happen without YazDHCP installed? Or perhaps as a troubleshooting step, remove YazDHCP and see if the issues persists.

This is the next step indeed, I'm doing it right now but it's asking me whether to restore NVRAM to the state before it was installed.

I'm in a dillema, the whole NVRAM or specific values to some specific params, with static leases? But I'm searching and reading up more on YazDHCP instructions as we speak ...

 

[Aziron5]

If the devices have their addresses "hard-coded" in, they won't be seeking a DHCP lease. Is this perhaps the case?

AndroidTV (Kaon Media KSTB6020) Boxes seem to get a different IP every now and then (I think I set my leases to 7 days) and in general Windows as well as Linux destkop OSes always come with Auto DHCP by default so I guess that's unlikely.
I did confirm now that I believe one printer is indeed set to a fixed IP, but still "DHCP mode".

 

[ColinTaylor]

the whole NVRAM or specific values to some specific params, with static leases?

It's talking about just the DHCP reservations under LAN - DHCP Server.

 

[Aziron5]

Uninstalled and rebooted ... not much on first glance, but one of the Win10 computers which initially shown it's proper hostname now shows up as "MSFT 5.0", so now there's two with the same hostname and nickname.

 

[bbunge]

Uninstalled and rebooted ... not much on first glance, but one of the Win10 computers which initially shown it's proper hostname now shows up as "MSFT 5.0", so now there's two with the same hostname and nickname.

Give it time. Wonky Network Map sometimes corrects itself when the DHCP addresses are renewed. Then again, sometimes not...

 

[glens]

... sometimes corrects itself when the DHCP addresses are renewed. Then again, sometimes not...

But NEVER /before/ renewal...

 

[Aziron5]

Yeah, I have two switches behind the router. One of them Stonet 8-port and a Linksys 5-port. I wouldn't be surprised if perhaps one of the switches produces more or is solely responsible for these side effects, I might do some more testing later by swapping or trying just one at a time.

But perhaps it's rather the blame of the whole infrastructure, firmware, software, protocols and standards, swiches shouldn't be "allowed" to produce such issues. The a perfect router with it's ARP/Netbios/mDNS etc., can only do so much, right?

 

[ColinTaylor]

Yeah, I have two switches behind the router. One of them Stonet 8-port and a Linksys 5-port. I wouldn't be surprised if perhaps one of the switches produces more or is solely responsible for these side effects, I might do some more testing later by swapping or trying just one at a time.

But perhaps it's rather the blame of the whole infrastructure, firmware, software, protocols and standards, swiches shouldn't be "allowed" to produce such issues. The a perfect router with it's ARP/Netbios/mDNS etc., can only do so much, right?

This is the issue I alluded to in post #2.

The accuracy of the router's Client List relies in part on the DHCP lease database. This is stored in RAM and therefore lost when the router is rebooted. This is not a problem for DHCP clients that are directly connected to the router*** as their connection will be physically disconnected forcing them to reacquire their lease. For devices connected to an intermediate switch the physical connection is not lost so the client has no reason to require its lease. The end result is that the router has no record of the client's previous DHCP information. But it knows via ARP that there's a device on the LAN with that MAC and IP address. It therefore has to assume that this is a static client until such a time as the client refreshes its lease.

*** EDIT: I have observed a behaviour in Windows 11 that I don't ever remember seeing in previous versions, or maybe it's just because my setup has changed. When rebooting the router the ethernet connection to my PC goes down and up as expected. However, if there is a delay in starting dnsmasq (e.g. because of custom scripts) Windows will quickly give up trying to "identify the network" and just carry on using the same network configuration it had before. The effect is the same as if it were connected to an intermediate switch.

 

[Ripshod]

This is the issue I alluded to in post #2.

The accuracy of the router's Client List relies in part on the DHCP lease database. This is stored in RAM and therefore lost when the router is rebooted. This is not a problem for DHCP clients that are directly connected to the router as their connection will be physically disconnected forcing them to reacquire their lease. For devices connected to an intermediate switch the physical connection is not lost so the client has no reason to require its lease. The end result is that the router has no record of the client's previous DHCP information. But it knows via ARP that there's a device on the LAN with that MAC and IP address. It therefore has to assume that this is a static client until such a time as the client refreshes its lease.

Brilliant. I've never read it explained so clearly.

 

[Aziron5]

Yet, I don't think I observed some of these issues with RT-AX68U despite having these switches there for a few months .... heh well, every single client had a MAC & IP manual assignment in that case.

 

[ColinTaylor]

heh well, every single client had a MAC & IP manual assignment in that case.

That would avoid the specific DHCP problem I described above. But I'm sure there are also many other issues with the Network Map.