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

[Martinski]

Release Notes for YazDHCP v1.2.2 production version now available
[2025-Nov-03]

1) FIXED: Modified code to better detect and handle Guest Network interfaces created by YazFi when starting up during a system reboot.

2) FIXED: On the WebUI page, the list of backup files for the "Restore Icons" button was not being fetched correctly.

3) CLEANUP: Removed old Tomato JavaScript file references.



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

 

[bennor]

Reminder. If you were on YazDHCP develop you can return to YazDHCP stable by running the following command via SSH on the router.
/jffs/scripts/YazDHCP stable

 

[bennor]

Yes, except for YazFi, waiting for the system clock to sync is SOP for all of JackYaz's add-ons. This means that during startup, the script simply waits up to 10 minutes, and nothing happens until the code detects NTP has synced, as reflected by the corresponding NVRAM variable. In the case of YazDHCP, after the 10-minute wait, the script continues to execute. In other cases, like ntpMerlin, connmon, and spdMerlin, if NTP fails to sync, the script will terminate and exit without performing the expected startup sequence and initialization.

BTW, I have my old RT-AC86U connected as a router behind my primary RT-AX86U_PRO, and I don't experience long delays in NTP syncing when I reboot the AC86U. Then again, unless I'm testing for a specific reason, I rarely reboot it under normal conditions.

Thanks for the explanation. Hopefully will be of help to others who may experience the missing YazDHCP on LAN DHCP Server page while waiting for NTP to sync. Probably can be chalked up to the old RT-AC68U I was testing with showing its 10+ years of age and processor/RAM slowness as to why I was seeing it happen two or three times during testing after rebooting and quickly accessing the LAN DHCP Server page before NTP had a chance to sync.

I've seen many reports over the years of the dnsmasq process crashing with a fatal signal. AFAIK, the root cause has not yet been found.

Pretty much the only reason I mentioned that dnsmasq processor entry was due to it typically being immediately after YazDHCP was mention in the system log. Everything seems to work despite that dnsmasq/284: potentially unexpected fatal signal 11.

 

[Stephen Harrington]

@Martinski

I'm on latest Production version 1.2.2 on a RT-AX86U running latest Merlin 3004.388.10_2.
Long-time user of YazHCP since the early JackYaz days to expand my DHCP mappings.

Maybe not a new thing but I noticed today my logs are being "spammed" every 30 seconds with the following:

Nov  4 11:53:39 AsusRouter YazDHCP_[2106]: Wireless Radios are *NOT* enabled.
Nov  4 11:53:39 AsusRouter YazDHCP_[2106]: Guest Network Interfaces *NOT* found.
Nov  4 11:54:09 AsusRouter YazDHCP_[2106]: Wireless Radios are *NOT* enabled.
Nov  4 11:54:09 AsusRouter YazDHCP_[2106]: Guest Network Interfaces *NOT* found.
Nov  4 11:54:38 AsusRouter YazDHCP_[2106]: Wireless Radios are *NOT* enabled.
Nov  4 11:54:38 AsusRouter YazDHCP_[2106]: Guest Network Interfaces *NOT* found.
Nov  4 11:55:08 AsusRouter YazDHCP_[2106]: Wireless Radios are *NOT* enabled.
Nov  4 11:55:08 AsusRouter YazDHCP_[2106]: Guest Network Interfaces *NOT* found.
Nov  4 11:55:38 AsusRouter YazDHCP_[2106]: Wireless Radios are *NOT* enabled.
Nov  4 11:55:38 AsusRouter YazDHCP_[2106]: Guest Network Interfaces *NOT* found.

And yes, that's correct and "as intended" - all Wifi is turned off (I have separate access points) and by definition I guess it follows that I don't have any guest networks enabled either.



Any chance of an option to turn off the (spurious for me) logging for those of us running "simpler' setups please?

Cheers and thanks!

 

[Martinski]

I'm on latest Production version 1.2.2 on a RT-AX86U running latest Merlin 3004.388.10_2.
...
Maybe not a new thing but I noticed today my logs are being "spammed" every 30 seconds with the following:

Excellent catch!! Thank you for reporting it. I did find where the problem was, and I have now modified the code to stop the messages under most conditions. You will still get a few of them in the syslog during reboots, when loading the WebUI page, when loading the CLI menu, or when the WiFi gets restarted; that's because YazDHCP needs to re-initialize its internal structures and files, and double-check the current configuration to see whether any Guest Networks have become enabled or disabled.

There's a new 'develop' branch version v1.2.3_25110400 that includes the most recent changes:

Run the following command to switch to the 'develop' version:

/jffs/scripts/YazDHCP develop

If you need/want to go back to the production version:

/jffs/scripts/YazDHCP stable

Let me know if the latest code addresses the problem you reported.

 

[Martinski]

...
Pretty much the only reason I mentioned that dnsmasq processor entry was due to it typically being immediately after YazDHCP was mention in the system log. Everything seems to work despite that dnsmasq/284: potentially unexpected fatal signal 11.

Well, I've seen this before. Some people read the syslog and see a dnsmasq crash following a YazDHCP log entry, and they tend to assume, and often simply conclude, that the crash must have been caused by YazDHCP. But that's only jumping to conclusions and using false logic. Seeing 2 events happen one after the other is not conclusive evidence of causation; it simply suggests a possible correlation, and a potential area of investigation, but you will need further data to prove that the 1st event indeed caused the 2nd one.

Up to now, I have not seen any report that provides any actual evidence proving that some of dnsmasq crashes reported are indeed caused by YazDHCP. I'm not saying it's impossible, only that I have not seen actual proof to conclusively make that determination.

For example, in your particular case, the log shows a YazDHCP entry saying that it's "Waiting for NTP to sync..." which means it goes to sleep for 15 seconds before it checks again. Then dnsmasq crash log entry is within the next second.

How does YazDHCP going to sleep for the next 15 seconds cause dnsmasq to crash??

 

[Syl]

Alright, I messed up and I'm not so good at the terminal thing. I started to install YazDHCP and long story short, things got aborted during the installation and if I try to launch it via amtm I get this.

Is there any terminal command to remove YazDHCP so I can uninstall it and attempt to reinstall it? I've tried force updating it and force stopping it and it's not going anywhere. I suspect the answer to this is something blindingly obvious that I cannot figure out but I... can't figure it out.

 

[Martinski]

Is there any terminal command to remove YazDHCP so I can uninstall it and attempt to reinstall it? I've tried force updating it and force stopping it and it's not going anywhere.

Try the following commands on your router via an SSH terminal window:

1) Download the latest production/master release version:

curl  -LSs --retry 3 --retry-delay 5 --retry-connrefused \
https://raw.githubusercontent.com/AMTM-OSR/YazDHCP/master/YazDHCP.sh \
-o /jffs/scripts/YazDHCP.sh && chmod 755 /jffs/scripts/YazDHCP.sh

2) Now, uninstall whatever files there are to make sure you have a clean slate:

/jffs/scripts/YazDHCP.sh uninstall

3) Finally, re-install the add-on:

/jffs/scripts/YazDHCP.sh install
mv -f /jffs/scripts/YazDHCP.sh /jffs/scripts/YazDHCP

You should now have a good installation of the latest production release 1.2.2 version.
Sample screenshot:

 

[jksmurf]

2) Now, uninstall

I actually had a wee look at YazDHCP on GitHub to see if there was an uninstall switch I could point the poor user to, but couldn’t see one.

Probably for the best, the solution seems a lot more complex than I had envisaged.

 

[bennor]

I actually had a wee look at YazDHCP on GitHub to see if there was an uninstall switch I could point the poor user to, but couldn’t see one.

If you run the CLI YazDHCP help command (/jffs/scripts/YazDHCP help), there are a number of YazDHCP CLI commands available including uninstall.

Available commands:
YazDHCP about - explains functionality
YazDHCP update - checks for updates
YazDHCP forceupdate - updates to latest version (force update)
YazDHCP startup force - runs startup actions such as mount WebUI tab
YazDHCP backupicons - backs up custom user icons from '/jffs/usericon/'
YazDHCP restoreicons - restores custom user icons to '/jffs/usericon/'
YazDHCP install - installs script
YazDHCP uninstall - uninstalls script
YazDHCP develop - switch to development branch version
YazDHCP stable - switch to stable/production branch version

 

[jksmurf]

If you run the CLI YazDHCP help command (/jffs/scripts/YazDHCP help), there are a number of YazDHCP CLI commands available including uninstall.

Available commands:
YazDHCP about - explains functionality
YazDHCP update - checks for updates
YazDHCP forceupdate - updates to latest version (force update)
YazDHCP startup force - runs startup actions such as mount WebUI tab
YazDHCP backupicons - backs up custom user icons from '/jffs/usericon/'
YazDHCP restoreicons - restores custom user icons to '/jffs/usericon/'
YazDHCP install - installs script
YazDHCP uninstall - uninstalls script
YazDHCP develop - switch to development branch version
YazDHCP stable - switch to stable/production branch version

Thank you, I wasn’t aware of that, very useful .

 

[Stephen Harrington]

Let me know if the latest code addresses the problem you reported.

Indeed it has @Martinski - thank you for quick response!

 

[jksmurf]

Hi @Martinski

I decided to update my remote network yesterday to YazDHCP but have come across a situation which may be user error or does not fit within the current YazDHCP design scope for my current setup, which defines my ONE IoT24_Guest network as being in the SAME subnet as primary (I will change this later so I also have Guest on 62 and IoT on 63, so this Main Subnet Guest Network is currently an interim phase, but one which I will likely continue with).

System:

Remote: Asus RT-AX86U-Pro (Router), RT-AX58U (Node), ZenWifi XD6 x 2 (Nodes) | AiMesh SC | Wired backhaul | Merlin 3006.102.5 | MerlinAU | TailMon | YazDHCP

Subnets (2#):

Main: 192.168.47.x
IoT24_Guest (Main Subnet, as shown on screencap): 192.168.47.x

Observation:

Before YazDHCP installation, all clients, Primary or IoT24_Guest took the manual assignment in the Merlin FW LAN/DHCP page (note that many Shellys I actually set with a static IP on the devices, so behave differently to non-static clients).

After YazDHCP (v 1.2.2) installation, I see the message below in the logs and whilst the Shellys are static as noted above and still get assigned the Static IPs, the rest of the clients now just get assigned a DHCP Address and do not get the Manual Assignment, even though the clients are on the GUEST Network defined in Guest Network Pro. The Wyse5070 (my HA Server) is one such example, see screenshot.

i.e. it seems that YazDHCP does not recognise Guest Network(s) on the Main Subnet as having a Guest Network Interface?
Note that the option to select Yes or No to the setting "Allow Guest Network Client Assignments" is also greyed out (Unavailable).

Nov  7 13:57:17 YazDHCP_[3115]: List of Guest Network Interfaces is EMPTY.
Nov  7 13:57:37 YazDHCP_[3115]: List of Guest Network Interfaces is EMPTY.
Nov  7 13:57:57 YazDHCP_[3115]: List of Guest Network Interfaces is EMPTY.
Nov  7 13:58:17 YazDHCP_[3115]: List of Guest Network Interfaces is EMPTY.
Nov  7 13:58:37 YazDHCP_[3115]: List of Guest Network Interfaces is EMPTY.
Nov  7 13:58:57 YazDHCP_[3115]: List of Guest Network Interfaces is EMPTY.

I have full logs if you need them. Let me know if I can test this for you any other way?

 

[Syl]

Try the following commands on your router via an SSH terminal window:

1) Download the latest production/master release version:

curl  -LSs --retry 3 --retry-delay 5 --retry-connrefused \
https://raw.githubusercontent.com/AMTM-OSR/YazDHCP/master/YazDHCP.sh \
-o /jffs/scripts/YazDHCP.sh && chmod 755 /jffs/scripts/YazDHCP.sh

2) Now, uninstall whatever files there are to make sure you have a clean slate:

/jffs/scripts/YazDHCP.sh uninstall

3) Finally, re-install the add-on:

/jffs/scripts/YazDHCP.sh install
mv -f /jffs/scripts/YazDHCP.sh /jffs/scripts/YazDHCP

You should now have a good installation of the latest production release 1.2.2 version.
Sample screenshot:

View attachment 68760

Thank you! This worked and it looks like everything is going smooth so far.

 

[bennor]

Subnets (2#):

Main: 192.168.47.x
IoT24_Guest (Main Subnet, as shown on screencap): 192.168.47.x

Observation:
i.e. it seems that YazDHCP does not recognise Guest Network(s) on the Main Subnet as having a Guest Network Interface?
Note that the option to select Yes or No to the setting "Allow Guest Network Client Assignments" is also greyed out (Unavailable).

If you enabled Use same subnet as main network when creating IoT24_Guest that likely explains why the Allow Guest Network Client Assignments is grayed out. Generally, when Use same subnet as main network is enabled is enabled when creating the Guest Network Pro profile the guest client IP addresses are pulled from the main network IP subnet range, and any manual IP reservations likewise will be pulled from the main DHCP Server page manual assignments list (when not using YazDHCP). Only when Use same subnet as main network is disabled does one set a different IP address subnet range for the Guest Network Pro profile.

 

[jksmurf]

If you enabled Use same subnet as main network when creating IoT24_Guest that likely explains why the Allow Guest Network Client Assignments is grayed out. Generally, when Use same subnet as main network is enabled is enabled when creating the Guest Network Pro profile the guest client IP addresses are pulled from the main network IP subnet range, and any manual IP reservations likewise will be pulled from the main DHCP Server page manual assignments list (when not using YazDHCP). Only when Use same subnet as main network is disabled does one set a different IP address subnet range for the Guest Network Pro profile.

I think I understand that, but the fact remains I do have a Guest Network defined, albeit with the same subnet, so would it not make sense to allow YazDHCP to manually assign those ones, somehow? Even if some sort of flag was needed to effect this.

 

[bennor]

I think I understand that, but the fact remains I do have a Guest Network defined, albeit with the same subnet, so would it not make sense to allow YazDHCP to manually assign those ones, somehow? Even if some sort of flag was needed to effect this.

Not sure I understand. When Use same subnet as main network is enabled for the Guest Network Pro profile, you should be able to manually assign that Guest Network Pro profile client's IP address as you would any other manual reservation in the Manually Assigned IP addresses in the DHCP scope section. As always if the client device has MAC randomization enabled that would need to be disabled. And one may need to leave the WiFi device disconnected for a period of time before reconnecting it to have it pull the new manual IP reservation.

PS: Just tested on a RT-AX86U Pro with YazDHCP. Created a new Guest Network Pro IoT Profile, set Use same subnet as main network to enable and a cellphone that already had a manual reservation set (using an IP address from the main LAN pool) to the main non Guest Network Pro WiFi 5Ghz network pulls in that saved manual IP reservation when connected to the newly created Guest Network Pro IoT profile.

 

[jksmurf]

Not sure I understand. When Use same subnet as main network is enabled for the Guest Network Pro profile, you should be able to manually assign that Guest Network Pro profile client's IP address as you would any other manual reservation in the Manually Assigned IP addresses in the DHCP scope section.

OK.... so are you saying I should be able to see devices that I previously assigned DHCPs under the LAN, DHCP tab (GUI memu) when I did not have YazDHCP installed, after the YazDHCP installation as well? i.e. no change?

If this is the case, then it does not seem to be (fully) working, as at least one device (and there are others that are NOT statically assigned on the device) is not getting the manual assignment. All I did was install YazDHCP and I went from a working set of manually assigned devices for that one subnet (but across two SSIDs) to it not working.

As always if the client device has MAC randomization enabled that would need to be disabled.

There is no MAC Randomisation for the devices example I note.

And one may need to leave the WiFi device disconnected for a period of time before reconnecting it to have it pull the new manual IP reservation.

OK. Actually the Wyse5070 HA Server is wired. A couple of other wired devices also lost their (previously) working manually-assigned IP Address, just due to the YazDHCP installation.
Is it perhaps user error? i.e. it does work and it is just a case of rebooting everything? HA Serve as well as router (or just issue a service restart_dnsmasq?

PS: Just tested on a RT-AX86U Pro with YazDHCP. Created a new Guest Network Pro IoT Profile, set Use same subnet as main network to enable and a cellphone that already had a manual reservation set (using an IP address from the main LAN pool) to the main non Guest Network Pro WiFi 5Ghz network pulls in that saved manual IP reservation when connected to the newly created Guest Network Pro IoT profile.

Hmm interesting and thank you for testing that, much appreciated. Maybe there is an issue with wired devices only?

 

[bennor]

OK.... so are you saying I should be able to see devices that I previously assigned DHCPs under the LAN, DHCP tab (GUI memu) when I did not have YazDHCP installed, after the YazDHCP installation as well? i.e. no change?

Yes. No change. Any device that had a main LAN IP address subnet manual reservation prior to YazDHCP being installed should have the same manual IP reservation AFTER YazDHCP is installed. If that is not happening something is wrong. Try rebooting any client device that isn't pulling their manual reservation after YazDHCP install.

OK. Actually the Wyse5070 HA Server is wired.

Is the wired HA server assigned to the Guest Network Pro IoT profile you mentioned previously? Or is the HA device connected to the main LAN?

It seems going back and re-reading your recent posts it seems you are indicating there are at least four issues you are experiencing, correct me if I'm wrong:

1. YazDHCP isn't color coding the Guest Network Pro profile client(s) when that profile is configured with Use same subnet as main network enabled.
2. You are getting YazDHCP_[3115]: List of Guest Network Interfaces is EMPTY. entries in the system log which is possibly related to the Use same subnet as main network enabled option because you have only one Guest Network Pro profile.
3. The Allow Guest Network Client Assignments option in YazDHCP is grayed out and not selectable. Again possibly due to the Use same subnet as main network enabled option because you have only one Guest Network Pro profile.
4. You have a Home Assistant (HA) device that is having problems (pulling the wrong IP address?).

For the HA IP address issue, seems more than a few people are having HA problems with Asus routers.

 

[jksmurf]

Yes. No change. Any device that had a main LAN IP address subnet manual reservation prior to YazDHCP being installed should have the same manual IP reservation AFTER YazDHCP is installed. If that is not happening something is wrong. Try rebooting any client device that isn't pulling their manual reservation after YazDHCP install.

Thank you, As far as I can tell, it is not happening. For the Shelly devices I am unable to tell, as they have static addresses set on the device. But these aside, 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.

Is the wired HA server assigned to the Guest Network Pro IoT profile you mentioned previously? Or is the HA device connected to the main LAN?

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?

It seems going back and re-reading your recent posts it seems you are indicating there are at least four issues you are experiencing, correct me if I'm wrong:

1. YazDHCP isn't color coding the Guest Network Pro profile client(s) when that profile is configured with Use same subnet as main network enabled.

Yes.

1. You are getting YazDHCP_[3115]: List of Guest Network Interfaces is EMPTY. entries in the system log which is possibly related to the Use same subnet as main network enabled option because you have only one Guest Network Pro profile.

Yes.

1. The Allow Guest Network Client Assignments option in YazDHCP is grayed out and not selectable. Again possibly due to the Use same subnet as main network enabled option because you have only one Guest Network Pro profile.

Yes.

1. You have a Home Assistant (HA) device that is having problems (pulling the wrong IP address?).

Correct.

For the HA IP address issue, seems more than a few people are having HA problems with Asus routers.

True. 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.