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

[bennor]

This is a very good question. I always thought it was the GNP profile but as it is wired amd does not logon to any SSID, maybe it was always on the main. This would still not explain why it isn’t simply taking the assigned address though?

If you configured the Guest Network Pro profile for Use same subnet as main network then it might not create a VLAN/SDN entry on the LAN > VLAN page where you typically assign an Ethernet port to a VLAN. You will need to review the LAN > VLAN page to see how you have configured things, if any, for the Ethernet port containing the Home Assistant device(s).

.... at least 3 devices (the HA server and two others on the HA network) do not take up the manually assigned address they used to, prior to the YazDHCP install.
.....
Although I don’t think it’s an HA issue causing it as I think I had a few other devices get assigned IPs via DHCP.

If it is only the HA devices that are not pulling the correct manual IP reservation one can easily assume there is an issue with how the HA device(s) are setup on the network and or how they are configured that might be preventing the device from properly pulling the correct manual IP reservation when YazDHCP is installed. How are those HA devices connected to the local network? Through the HA server which is connected to the router's main LAN? Or by individual WiFi connection to router or by a mix of WiFi and Ethernet? Do they use a combination of IPv4 and IPv6 addresses? Are they all going through the Guest Network Pro IoT profile? If they are, as a troubleshooting step, connect all the devices to the main network (not through Guest Network Pro) and see if they all pull the correct IP address.

Post edited.

 

[jksmurf]

If you configured the Guest Network Pro profile for Use same subnet as main network then it might not create a VLAN/SDN entry on the LAN > VLAN page where you typically assign an Ethernet port to a VLAN. You will need to review the LAN > VLAN page to see how you have configured things, if any, for the Ethernet port containing the Home Assistant device(s).

I did not assign an Ethernet port in the VLAN Page.

The topology (constrained by layout, Modem Location, folks preference for router location) is Primary Router > 8 Port Unmanaged Switch > 6 Ethernet Cables (3 currently used) > two AX6 Nodes, one RT-AX58U Node. The RT-AX58U Node has the HA server and two Xiaomi mii Smart Gateway 2 devices attached to the Ethernet port.

Those 3 wired devices shifted to dynamic DHCP. I think some other wireless (on the IoT network) device like a micro display for HA also changed IP address (I’ve changed it back now so it keeps running, so I’d need to redo YazDHCP to double check what else is getting DHCP). In my Merlin, but non-YazDHCP LAN/DHCP page I just had all my assignments to a 192.168.47.x address, regardless of which VLAN they were attached to, primary or guest. This seemed to work and the devices all got the correct IP, even after a router or device reboot. This was stable and has worked for a year.

So lets focus on the wired devices for now.

On reflection, the HA Server and the two Xiaomi devices must have been on primary LAN.

Given the above, I am still struggling to fathom how installing YazDHCP caused the 3 wired devices to suddenly get a dynamically assigned address, even after several router reboots. What I did not do, cardinal sin, is reboot the 3 devices after installing YazDHCP. I can do this remotely (actually had to, when I uninstalled YazDHCP) but I am very remote from the network atm. I’ll be them in a couple of weeks.

If it is only the HA devices that are not pulling the correct manual IP reservation one can easily assume there is an issue with how the HA device(s) are setup on the network and or how they are configured that might be preventing the device from properly pulling the correct manual IP reservation when YazDHCP is installed. How are those HA devices connected to the local network?

See topology above. No static address assigned on these, just the manual assignments.

Through the HA server which is connected to the router's main LAN? Or by individual WiFi connection to router or by a mix of WiFi and Ethernet? Do they use a combination of IPv4 and IPv6 addresses? Are they all going through the Guest Network Pro IoT profile?

No, not through the GNP Proifle. You’re asking excellent questions as usual and it has made me think a bit more about what I should expect to see.

If they are, as a troubleshooting step, connect all the devices to the main network (not through Guest Network Pro) and see if they all pull the correct IP address.

Unfortunately that step would need to wait 3 weeks.

Post edited.

Fundamentally though, despite me having a Guest Network, YazDHCP does not recognize one exists, presumably as being in the same subnet as the main, it would have no way of knowing whether the device on 192.168.47.x in the Assigned list belongs to a Primary br0 or Guest_IoT network br??? I.e. it doesn’t care about the SSID, so it can’t differentiate?

 

[bennor]

What I did not do, cardinal sin, is reboot the 3 devices after installing YazDHCP. I can do this remotely (actually had to, when I uninstalled YazDHCP) but I am very remote from the network atm. I’ll be them in a couple of weeks.

A reboot or power cycle of the affected devices would be good. But if that cannot be done, maybe (or maybe not) they'll pull the corrected IP address when the DHCP lease time runs out and the clients renew their DHCP leases. Assuming of course the lease time wasn't set to some high value like weeks or months. Default lease time I think is 86400, which is 24 hours.

Really stupid question time but you did hit the Apply button on the DHCP Server page just to make sure to apply the YazDHCP settings after you installed YazDHCP and or many any changes on that page, right?

 

[jksmurf]

A reboot or power cycle of the affected devices would be good.

Thanks @bennor for following up on this, I feel a bit embarrassed to take up so much of your time. Yes, that can be done remotely and I might give it a go to check it out some more.

But if that cannot be done, maybe (or maybe not) they'll pull the corrected IP address when the DHCP lease time runs out and the clients renew their DHCP leases. Assuming of course the lease time wasn't set to some high value like weeks or months. Default lease time I think is 86400, which is 24 hours.

OK. Yes, not changed lease times.

Really stupid question time but you did hit the Apply button on the DHCP Server page just to make sure to apply the YazDHCP settings after you installed YazDHCP and or many any changes on that page, right?

Never a stupid question and the answer is I don’t think I did. The reason is that I did not change, i.e. no adds or omits, the 40-odd long device list, so it didn’t even enter my mind as to whether I’d need to. Will try on the next round of trials.

 

[jksmurf]

Really stupid question time but you did hit the Apply button on the DHCP Server page just to make sure to apply the YazDHCP settings after you installed YazDHCP and or many any changes on that page, right?

Oh my goodness, hand up here and apologies for the wild goose chase. That worked, simple as it was. Thank you . I even rebooted the router to double check; and then the HA server. All good.

When I installed YazDHCP it just installed and said you’re done, and given that I didn’t change any assignments at all, I really thought, great, I’m done, it all works. I never in a million years thought to hit "Apply", you only do that if you change something like a setting (which as I noted a few posts ago I couldn’t as it is greyed out), or an assignment entry.

Maybe @Martinski could add a line to the script, to cater for dummies like me, which does a virtual “Apply” immediately after installation so the current list is …applied. Or maybe just add a note to the instructions, “hey just click apply immediately after installation regardless of whether you changed anything or not”; or maybe just don’t cater for dummies at all... … but thank you once again @bennor, much appreciated.

@Martinski, not sure if you would like to supplement the text under item 4 of your GitHub instructions to clarify same subnet as primary GNP VLANs, i.e modify “If at least one suitable Guest Network is found enabled/active…” to “If at least one suitable Guest Network (excluding GNs on the same subnet as Primary) is found enabled/active...” or similar wording ?

 

[Martinski]

...
i.e. it seems that YazDHCP does not recognise Guest Network(s) on the Main Subnet as having a Guest Network Interface?

From the very beginning, when I describe the goal and intent of the new feature, I have clearly and explicitly stated that the target is Guest Networks whose subnet range is separate (i.e. different) from the main LAN subnet. In fact, the very first sentence of the documentation in the Release Notes, which are now on GitHub, clearly says:

Having established that *requirement* upfront in the first sentence, when the rest of the documentation refers to "Guest Networks," it's implied that those GNs must meet the stated requirement: their subnet is separate/different from the main LAN subnet; and those are the only "suitable" GNs that YazDHCP works with.

Note that the option to select Yes or No to the setting "Allow Guest Network Client Assignments" is also greyed out (Unavailable).

The reason was clearly stated in the Release Notes, which are now in GitHub:

When I installed YazDHCP it just installed and said you’re done, and given that I didn’t change any assignments at all, I really thought, great, I’m done, it all works. I never in a million years thought to hit "Apply", you only do that if you change something like a setting (which as I noted a few posts ago I couldn’t as it is greyed out), or an assignment entry.

It's not clear at all how exactly YazDHCP was installed and what exact steps were taken to migrate all the existing DHCP IP address reservations. Were they exported directly from NVRAM? Were they imported via a previously saved CSV file? Was there a user error made somewhere along the way? Without knowing the exact details, I don't know what happened that led to the scenario you described.

In any case, glad you finally got things working as intended.

Maybe @Martinski could add a line to the script, to cater for dummies like me, which does a virtual “Apply” immediately after installation so the current list is …applied. Or maybe just add a note to the instructions, “hey just click apply immediately after installation regardless of whether you changed anything or not”; or maybe just don’t cater for dummies at all... … but thank you once again @bennor, much appreciated.

Upon an initial installation, after any existing DHCP IP address reservations are migrated successfully from NVRAM, YazDHCP does make a call to a function that "applies" the new settings and then restarts dnsmasq. If no migration from NVRAM has taken place, it's the user responsibility to manually transfer or import any existing IP address reservations, and then either click on the "Apply" button from the WebUI, or run option 1 from the SSH CLI menu.

@Martinski, not sure if you would like to supplement the text under item 4 of your GitHub instructions to clarify same subnet as primary GNP VLANs, i.e modify “If at least one suitable Guest Network is found enabled/active…” to “If at least one suitable Guest Network (excluding GNs on the same subnet as Primary) is found enabled/active...” or similar wording ?

I've added a few sentences at the end of the "IMPORTANT NOTES" section regarding the "Apply" button. It's always been clear to me that clicking on the "Apply" button is a crucial final step since that's essentially the way to accept and confirm the settings currently being displayed on the WebUI, but apparently, it's not obviously clear to everyone.

HTH.

 

[jksmurf]

It's always been clear to me that clicking on the "Apply" button is a crucial final step since that's essentially the way to accept and confirm the settings currently being displayed on the WebUI, but apparently, it's not obviously clear for everyone.

I have no excuses; my apologies unreservedly for not reading the notes closely enough.

I thought it was possibly a bug, it threw me, but there’s nothing more to say here. Apologies for taking up your time and thanks once again for an amazing Addon which has become a staple in my two systems.

 

[Martinski]

Release Notes for YazDHCP v1.2.3 production version now available
[2025-Nov-07]

1) FIXED: Suppress unnecessary syslog messages under specific conditions.

[Thanks to @Stephen Harrington for finding/reporting the bug]​

2) IMPROVED: Better checking of Guest Networks when wireless radios are restarted.

3) IMPROVED: Modified code to clean up files after disabling a Guest Network.



The fork from @Jack Yaz's YazDHCP add-on is now hosted on the AMTM-OSR GitHub repo:

GitHub - AMTM-OSR/YazDHCP: Feature expansion of DHCP assignments using AsusWRT-Merlin's Addons API to read and write DHCP assignments, increasing the limit on the number of reservations.

Feature expansion of DHCP assignments using AsusWRT-Merlin's Addons API to read and write DHCP assignments, increasing the limit on the number of reservations. - AMTM-OSR/YazDHCP

github.com

 

[Martinski]

I have no excuses; my apologies unreservedly for not reading the notes closely enough.

I thought it was possibly a bug, it threw me, but there’s nothing more to say here. Apologies for taking up your time and thanks once again for an amazing Addon which has become a staple in my two systems.

No worries. It happens. Full credit to you for owning up to the mistake with no excuses. Now we move forward.