DHCP issues with Merlin and Yaz

[pgershon]

Strange issue where devices that have DHCP reservations suddenly started getting IP addresses in a different subnet. Main subnet is 192.168.1.x. DHCP pool to assign addresses 192.168.1.121 to 192.168.1.170. Most addresses above and below are assigned to devices. House is large with many Asus routers, but once central GT-AX6000 that does the DHCP for the whole network. I recently updated the firmware on the GT-AX6000 to 3006.102.6 and I believe that is when the issue developed. Devices that connect to the other routers in the house still function properly, but devices that connect directly to the GT-AX6000 are getting addresses 192.168.52.x despite the fact that their MAC addresses are reserved in the 192.168.1.x rhelm. Not all devices are getting the 192.168.52.x assignment, but it seems to be 5 +/- devices affected. I am not sure why this is happening nor what to do about it. Any ideas?

 

[jksmurf]

Two questions:

Where are you seeing this reported? Network map is notoriously flaky.

Secondly, have you checked whether the devices getting the incorrect IP are using (configured for, without remembering an old SSID) the SSID you want them to join?

Bonus question; Yaz … what? YazDHCP? (I use it, it’s great for Main and GNP).

 

[bennor]

House is large with many Asus routers, but once central GT-AX6000 that does the DHCP for the whole network.

I assume by "Yaz" you mean YazDHCP. If so make sure to update to the latest version of YazDHCP (v1.2.5).
Double check that another DHCP server is not active on the network since you indicated you have "many Asus routers".
Be more specific about which devices are getting the incorrect IP address. Those on the main LAN or those on Guest Network Pro profiles or both.
Make sure each client doesn't have it's randomize MAC address option enabled. When that option is enabled it may allow the client to bypass the YazDHCP manually configured IP address.
List out all the routers (main, AP, and AiMesh, extender, etc) on your network. Include their firmware as well.
When did this issue start happening? Did anything change on the local network right before this issue presented itself? Did you update the main router's firmware? Did you add a new router or network device to the local network?
If the issue is with clients connecting to WiFi, double check that the WiFi client is connecting to the correct WiFi band and or WiFi AiMesh/AP node. With some WiFi devices one needs to erase any prior saved WiFi profiles to prevent the client from connecting to a different WiFi network. This may include going into the device's online account to remove saved or backed up WiFi connection profiles.

 

[pgershon]

Thank you for the responses. I will put together a list of answers to your network-topogogy and equipment questions shortly, but in the meantime, could you direct me to the easiest link for updating YazDHCP? Thanks. From a quick review of google search, it might very well be that the merging firmware update without the YazDHCP update broke my system.

 

[pgershon]

So here are the answers to your questions:

1) There are no other DHCP servers on my network. Just one from my GT-AX6000 running 192.168.1.1.
2) Confirmed all other routers have DHCP turned off. All routers have AIMesh off. Routers are as follows:
a) 3 RT-AX92U units (192.168.1.2, 192.168.1.3, 192.168.1.14) all running 3004.388.10_2-gnuton1
b) 1 RT-AC87U unit (192.168.1.5) running 3.0.0.4.382_52545
c) TP Link AX1800 Wi-Fi 6 Router (192.168.1.7) (firmware 2.1.9 Build 20250424 rel.71412(5553))
d) TP Link TL-WA901N firmwa3.16.9
e) TP LINK Omada controller (192.168.1.9) controlling 4 EAP units
i) EAP 610 (192.168.1.4) firmware 1.4.4
ii) EAP 650 (192.168.1.17) firmware 1.2.5
iii) EAP 225 (192.168.1.8) firmware 5.1.11
iv) EAP 670 (192.168.1.16) firmware 1.1.1
3) There are no guest networks on my system. I have one main network through 192.168.1.x. Each of the individual routers above can be accessed by devices connecting to wifi (or in some cases hardwired) but DHCP is assigned exclusively through the GT-AX6000. WiFi networks on each router may be a common name (Gershon_Hamptons for 5GHz, Gershon_Slow for 2.4 GHz) or a name specific to that router (Gershon_Slow_TV, for example, is specific to the GT-AX6000 at 2.4 GHz). The reason for the different WiFi names is to allow precise assignment of device to closest router.
4) Many of my devices are TP Link KASA light switches and dimmers. These all operate in the 2.4 GHz bank and are 100% wireless and do not permit manual IP assignment so I rely on my router to assign IPs. The many KASA switches that connect through routers 2a-2e are getting their DHCP assignments fine. My problem is specific to Kasa devices that connect directly to the GT-AX6000. Most devices even connected over 2.4 GHz to the GT-AX6000 are getting IP assignments in the 192.168.1.x range and following the DHCP assignment by MAC address. But 7 KASA devices (and the list has been growing) are now getting assigned 192.168.52.x IP addresses (and ignoring the MAC based assignments,
5) These devices are functional on my network, but have the wrong IP address and subnet. My KASA app can turn the switches on and off, but my Indigo controller which looks for specific IPs in the 192.168.1.x range is not seeing any of them.
6) MAC addresses are not being randomized
7) I noticed the issue when I updated firmware on the GT-AX6000 about 2-3 weeks ago.
8) My working theory has been that the DHCP server is running out of IP addresses in the pool in the 192.168.1.x range and then assigning in the 192.168.52.x instead. And that once a device gets into the 192.168.52.x range, it ignores the DHCP reservations. But there should be many more IP addresses available. I do not have that many devices from 192.168.1.211 to 192.168.1.170. But devices no longer on my network (and I am talking about years removed) may be keeping the old IP assignments.
9) No new routers have been added recently

It makes sense to me that I may need to update YazDHCP. I do need assistance finding version 1.2.5 as the most recent I see is 1.2.4. I could also use a refresher in how to update YazDHCP. It has been a few years for me.

Thanks

 

[Seth Harman]

I believe 192.168.1.52.x is, by default, the IP block assigned to the first instance of Guest Network Pro. Check in the Guest Network Pro tab on the AX6000 to see if somehow a wireless VLAN got turned on.

 

[bennor]

....but in the meantime, could you direct me to the easiest link for updating YazDHCP?

See the YazDHCP GUI or CLI where there is an option to check for an update. See attached. For specific questions about YazDHCP see the YazDHCP thread in the Addons subforum:

YazDHCP - YazDHCP v1.2.4 [2025-Nov-21] - Feature expansion of DHCP assignments (increasing limit on the number of DHCP reservations)

Release Notes for YazDHCP v1.0.8 production version now available [2025-May-29] The fork from @Jack Yaz's repository is now hosted on the AMTM-OSR GitHub repo: https://github.com/AMTM-OSR/YazDHCP 1) FIXED: Errors when loading the webGUI page on the 3006.102.x F/W version. 2) FIXED: Some...

www.snbforums.com

Generally, if a client ends up with an IP address in the 192.169.52.x range it means they are connected to a Guest Network Pro profile that was configured with the Guest Network Pro profile Use same subnet as main network enabled.

When the Guest Network Pro Use same subnet as main network is disabled it creates a separate IP address subnet for the clients connected to that profile. If you then configure that Guest Network Pro profile's VLAN to include a LAN port, any down stream LAN/WiFi clients connected to that LAN port may potentially also use that Guest Network Pro's IP subnet (usually 192.168.52.x, 192.168.53.x, etc.)

Note that certain Guest Network Pro/VLAN options may not flow down to routers that do not support the 3006.102.x firmware. Plenty of other threads where discussions about what works and doesn't with Guest Network Pro and VLAN on AiMesh or AP nodes or managed network switches. See the forum search feature for those discussions.

Attached four images show examples of where the YazDHCP check for update option is located, and examples of a Guest Network Pro profile (IoT) with Use same subnet as main network enabled/active (when initially creating the profile) and the separate IP subnet that is created when enabled.

Posted edited to fix enabled to disabled.

 

[pgershon]

I believe 192.168.1.52.x is, by default, the IP block assigned to the first instance of Guest Network Pro. Check in the Guest Network Pro tab on the AX6000 to see if somehow a wireless VLAN got turned on.

That was it. Looks like the Guest Network Pro got turned on when I updated firmware on router. Once I knew what to look for I switched it off pretty easily. And problem solved. Thanks very much.

 

[Seth Harman]

That was it. Looks like the Guest Network Pro got turned on when I updated firmware on router. Once I knew what to look for I switched it off pretty easily. And problem solved. Thanks very much.

My pleasure. That's very strange that it just turned itself on.

 

[Seth Harman]

Generally, if a client ends up with an IP address in the 192.169.52.x range it means they are connected to a Guest Network Pro profile that was configured with the Guest Network Pro profile Use same subnet as main network enabled.

When the Guest Network Pro Use same subnet as main network is enabled it creates a separate IP address subnet for the clients connected to that profile. If you then configure that Guest Network Pro profile's VLAN to include a LAN port, any down stream LAN/WiFi clients connected to that LAN port may potentially also use that Guest Network Pro's IP subnet (usually 192.168.52.x, 192.168.53.x, etc.)

"Use same subnet as main network" enabled would result in the clients being assigned IP addresses from the main network block, which in his case is 192.168.1.x.

 

[bennor]

"Use same subnet as main network" enabled would result in the clients being assigned IP addresses from the main network block, which in his case is 192.168.1.x.

Good catch, edited my post to correct my mistake. The Use same subnet as main network setting has turned out to be an issue for more than a few people since it was first introduced with the 3006.102.x firmware. Doesn't help that depending on which Guest Network Pro profile one choses to use that setting may either be disabled or enabled. From a post a while back indicating where the Use same subnet as main network option is and it's default value on a RT-AX86U Pro with Asus-Merlin 3006.102.5 firmware (see below). Its an easy option to miss in some cases because for some Profile settings its under the More Config section. Made worse that it could be disabled in it's default setting and one may not know it initially.

Guest Portal the option doesn't appear to be available.
Guest Network the option is under More Config (default: disabled).
Kid's Network the option is under More Config (default: disabled).
IoT Network the option is on initial profile dialog panel (default: enabled).
VPN Network the option is under More Config (default: disabled).
Customized Network the option is under More Config (default: disabled).