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.

 

[jk7gr]

Dear @Martinski moving from 1.0.7 to 1.2.3 and immediately I faced a strange issue related to DNS hostname resolution. The old YazDHCP was using .hostname file to return the name of a static IP that someone was defining. E.g. IP address of a TPLink network switch which has a static ip or on a Macvlan container. The new version is only using .staticlist so the name resolution works fine for those devices that are contacting DHCP but not on those not contacting it. To prove the point I added from the backup the .hostnames and also added manually in dnsmasq.conf the deleted line and everything started working fine again. Is there any permanent solution planned for this strange issue? Maybe something obvious I am missing?

 

[jksmurf]

Hi @Martinski

I had a couple of questions (but it now seems apparent, see below, these observations are down to limitations of Asus GNP).

I recently reset a Router and on setting up GNP Networks Guest and IoT, did not realise they were set by the GNP setup as LAN IP 192.168.52.1 / VLAN ID 52 and LAN IP 192.168.53.1 / VLAN ID 53 respectively; I actually wanted to set these to VLAN ID 62 and 63 to avoid a conflict over VPN (reason is not important here).

I then installed YazDHCP and added the DHCPs as 62 and 63 subnet, then saw the error; so keeping YazDHCP intact I changed the GNP settings to VLAN 62 and VLAN 63.

However when I went in to YazDHCP via SSH and selected 1. Process /jffs/addons/YazDHCP.d/DHCP_clients I saw:

Please wait...
DHCP IP address reservation list for Guest Network [br52] remains unchanged
DHCP IP address reservation list for Guest Network [br53] remains unchanged
DHCP IP address reservation list for main LAN [br0] remains unchanged
Restarting dnsmasq for new DHCP settings to take effect.

and also when I looked at the dir structure /jffs/addons/YazDHCP.d I saw that there were two files .staticlist_br52 and .staticlist_br53 i.e. these had not changed when I corrected GNP, even though the contents of the files were correct, containing the .62 and .63 subnets for DHCPs. I am sure it all works fine (it seems to) but being a wee bit OCD about this, I wanted to change the br52 and br53 references and path names so they all match i.e. to br62 and br63.

My error here (or so I thought), due to being making the GNP VLAN ID change AFTER I installed YazDHCP.

So my original question was, will I break anything if I amend this manually? This now does not need to be answered, for reasons why, see below.
For the record, I thought I could just amend these:

• Rename .staticlist_br52 to .staticlist_br62
• Rename .staticlist_br53 to .staticlist_br63
• Ensure any lines in dnsmasq-x.conf.add now refer to br62, br63 e.g. dhcp-hostsfile=/jffs/addons/YazDHCP.d/.staticlist_br62 #YazDHCP_staticlist_br62#
• dhcp-hostsfile=/jffs/addons/YazDHCP.d/.staticlist_br52 #YazDHCP_staticlist_br52#
• Ensure any lines in firewall-start (jffs/scripts/) refer to the correct br62 or br63 and not br52 or br3 e.g. iptables -I FORWARD -i br62 -s 192.168.62.238 -d 192.168.47.0/24 -j ACCEPT

Alternatively I thought I could just export the assignments, uninstall YazDHCP, and reinstall YazDHCP, re-import (need to check if icons come back) and it should align itself to the correct brxx numbering in GNP setup. Again, this now does not need to be answered, for reasons why, see below

[EDIT 1] So I uninstalled YazDHCP and ran:

brctl show

and it seems like I still have bro, br52 and br53, created by GNP; so changing the settings manually would not have worked, nor uninstalling YazDHCP and reinstalling.

I tried deleting the Guest Networks next. If selecting presets it keeps br52 and br53 as it creates those first, and then retains them even when you change the VLAN IDs and subnet, that will be pretty ugly. Maybe then only a customised network will allow the naming I am after.

[EDIT 2] So it looks like a limitation of Asus GNP.

Even creating a Custom guest network does not create (nor let you define) your own brxx value (or one that aligns with the VLAN ID), it seems to be automatic, sequential from br52 onwards and fixed.

Cosmetic I guess but means you just have to remember, when putting IPTABLES forwards (as above) in firewall-start, to use br52, br53 sequentially and not whatever VLAN ID e.,g. 62, 63 that you have given it.

OK, move along here, nothing to see...

 

[Martinski]

Dear @Martinski moving from 1.0.7 to 1.2.3 and immediately I faced a strange issue related to DNS hostname resolution. The old YazDHCP was using .hostname file to return the name of a static IP that someone was defining. E.g. IP address of a TPLink network switch which has a static ip or on a Macvlan container. The new version is only using .staticlist so the name resolution works fine for those devices that are contacting DHCP but not on those not contacting it. To prove the point I added from the backup the .hostnames and also added manually in dnsmasq.conf the deleted line and everything started working fine again. Is there any permanent solution planned for this strange issue? Maybe something obvious I am missing?

Good point and great catch. I'll take a look.

 

[Martinski]

[EDIT 2] So it looks like a limitation of Asus GNP.

Even creating a Custom guest network does not create (nor let you define) your own brxx value (or one that aligns with the VLAN ID), it seems to be automatic, sequential from br52 onwards and fixed.

Yeah, currently, the virtual bridge interface ID (e.g. brXY) allocated by the F/W to a Guest Network Pro profile is completely independent of the VLAN ID the user assigns to the GNP. So don't mess with those bridge interface IDs!!

 

[Martinski]

Dear @Martinski moving from 1.0.7 to 1.2.3 and immediately I faced a strange issue related to DNS hostname resolution. The old YazDHCP was using .hostname file to return the name of a static IP that someone was defining. E.g. IP address of a TPLink network switch which has a static ip or on a Macvlan container. The new version is only using .staticlist so the name resolution works fine for those devices that are contacting DHCP but not on those not contacting it. To prove the point I added from the backup the .hostnames and also added manually in dnsmasq.conf the deleted line and everything started working fine again. Is there any permanent solution planned for this strange issue? Maybe something obvious I am missing?

I found the source of the problem preventing the creation and handling of the "hostnames" file.
The modified code is currently found only in the latest 'develop' branch version v1.2.4_25111400 (now available).

If you'd like to test and verify the fix, switch from your installed production version to the latest 'develop' branch using the following commands:

/jffs/scripts/YazDHCP develop
/jffs/scripts/YazDHCP forceupdate

After you have installed the latest 'develop' branch version, select option 1 from the CLI menu to process all DHCP client files again. Let me know if this addresses your scenario.

To switch back to the latest production release v1.2.3 version:

/jffs/scripts/YazDHCP stable

 

[jk7gr]

I found the source of the problem preventing the creation and handling of the "hostnames" file.
The modified code is currently found only in the latest 'develop' branch version v1.2.4_25111400 (now available).

View attachment 68909

If you'd like to test and verify the fix, switch from your installed production version to the latest 'develop' branch using the following commands:

/jffs/scripts/YazDHCP develop
/jffs/scripts/YazDHCP forceupdate

After you have installed the latest 'develop' branch version, select option 1 from the CLI menu to process all DHCP client files again. Let me know if this addresses your scenario.

View attachment 68910

To switch back to the latest production release v1.2.3 version:

/jffs/scripts/YazDHCP stable

yes, it works! Thanks mate!