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

[bennor]

A reminder, if you were on the YazDHCP develop version and want to switch back to the YazDHCP stable version, running the following via SSH command line:

/jffs/scripts/YazDHCP stable

That will switch the script from develop to stable and the CLI should indicate Branch: master and not Branch: develop.

 

[predatorz]

Seem like DHCP assignment for Guests Network need to be manually enabled via CLI whenever router reboot.
Possible to make change permanent to survive router reboot?

 

[jksmurf]

Seem like DHCP assignment for Guests Network need to be manually enabled via CLI whenever router reboot.
Possible to make change permanent to survive router reboot?

Hmm, that has not been my experience i.e. it does survive a reboot.

Can you elaborate a bit on this please, which version you’re running, stable (master) or develop (latest is stable), what CLI command you’re running to get it going again, (once installed via amtm or the CLI everything else I manage via the GUI), whether you also have manually assigned DHCP in the GNP tab (x/32 and you should not double up and should delete these), whether you might have some legacy dnsmasq-sdn.conf.add files in /jffs/config/ (you shouldn’t), what you installed it over the top of (Merlin FW DHCP assignments for Primary)?

It does take a while after you enter the screen for the GNP ones to populate the list though, presumably you waited a short while?

 

[predatorz]

Hmm, that has not been my experience i.e. it does survive a reboot.

Can you elaborate a bit on this please, which version you’re running, stable (master) or develop (latest is stable), what CLI command you’re running to get it going again, (once installed via amtm or the CLI everything else I manage via the GUI), whether you also have manually assigned DHCP in the GNP tab (x/32 and you should not double up and should delete these), whether you might have some legacy dnsmasq-sdn.conf.add files in /jffs/config/ (you shouldn’t), what you installed it over the top of (Merlin FW DHCP assignments for Primary)?

It does take a while after you enter the screen for the GNP ones to populate the list though, presumably you waited a short while?

Updated to Stable 1.2.1 via amtm, can't remember the previous version

Guest DHCP reservation has been added via GUI
Yes, in GUI, it take a while to populate all the entries for both main & Guest.
When loaded, it will show red for Guest reservation address and Allow Guest Network Client Assignments as No and disabled for Currently

I do have dnsmasq.conf.add (should be created by default) under /jffs/configs/
Below is the config in dnsmasq.conf.add

dhcp-hostsfile=/jffs/addons/YazDHCP.d/.staticlist #YazDHCP_staticlist#
ipset=/feodotracker.abuse.ch/iplists.firehol.org/sigs.interserver.net/raw.githubusercontent.com/voipbl.org/ipdeny.com/ipapi.co/api.db-ip.com/api.bgpview.io/asn.ipinfo.app/speedguide.net/otx.alienvault.com/github.com/astrill.com/strongpath.net/snbforums.com/bin.entware.net/nwsrv-ns1.asus.com/0.pool.ntp.org/0.sg.pool.ntp.org/Skynet-WhitelistDomains # Skynet
ipset=/asuswrt-merlin.net/asuswrt.lostrealm.ca/big.oisd.nl/codeload.github.com/diversion.ch/drv.ms/entware.diversion.ch/entware.net/fwupdate.asuswrt-merlin.net/garycnew.github.io/localhost.localdomain/maurerr.github.io/mirrors.bfsu.edu.cn/mirrors.cernet.edu.cn/mirrors.cqupt.edu.cn/mirrors.nju.edu.cn/oisd.nl/onedrive.live.com/openstreetmap.org/pgl.yoyo.org/Skynet-WhitelistDomains # Skynet
ipset=/pkg.entware.net/small.oisd.nl/someonewhocares.org/sourceforge.net/sunrisesunset.io/urlhaus.abuse.ch/Skynet-WhitelistDomains # Skynet

 

[jksmurf]

Updated to Stable 1.2.1 via amtm, can't remember the previous version

Guest DHCP reservation has been added via GUI
Yes, in GUI, it take a while to populate all the entries for both main & Guest.
When loaded, it will show red for Guest reservation address and Allow Guest Network Client Assignments as No and disabled for Currently

You need to say yes…. to both.... then click APPLY at the bottom ;-). Reboot and see if preserved…

I do have dnsmasq.conf.add (should be created by default) under /jffs/configs/
Below is the config in dnsmasq.conf.add

Was actually asking about /jffs/configs/dnsmasq-x.conf.add where x is 1, 2 etc as your GNPs grow, but I think it might just be that toggle above.

 

[predatorz]

Already set to Yes for both in GUI previously
Nonetheless, re-applied settings again and will monitor on next reboot

 

[bennor]

Seem like DHCP assignment for Guests Network need to be manually enabled via CLI whenever router reboot.

Not experiencing that on a RT-AX86U Pro running 3006.102.5 firmware. The YazDHCP being Enabled survives reboot. Just tested again right now. No problem, Allow Guest Network Client Assignments remains enabled.

One thing to be aware of though, there is a slight delay, in my case of up to 10 to 15 seconds, before YazDHCP indicates Allow Guest Network Client Assignments as Enabled and it's Yes radio box indicates selected when ever I load or reload the DHCP Server page. Cause is the YazDHCP script processing things and the router System Log likewise will log several YazDHCP script processes being performed. Example of that delay:

 

[bennor]

@predatorz, to confirm you are running a RT-AX86U with 3004.388.10 firmware?
Wonder if that is the issue, working properly on 3006.102.x but not on 3004.388.x.
Don't have a router running 3004.388.x but do have an older RT-AC68U running 3004.386.14.2 and YazFi which seem to have similar issues running YazDHCP 1.2.1, the Allow Guest Network Client Assignments option is grayed out and listed as unavailable. Initially after importing a updated YazDHCP CVS file that has a number of YazFi Guest Network clients added to it, the Allow Guest Network Client Assignments appeared to be enabled, but after a reboot the option is grayed out on 3004.386.14.2 and listed as unavailable. Tried several things like logging out and logging back in, reimporting the CVS file and applying the change, and rebooting. Nothing seemed to work, the Allow Guest Network Client Assignments option remains grayed out and not selectable.

Will troubleshoot a bit more on that old router when I have a bit more time.

 

[jksmurf]

@predatorz, to confirm you are running a RT-AX86U with 3004.388.10 firmware?
Wonder if that is the issue, working properly on 3006.102.x but not on 3004.388.x.
Don't have a router running 3004.388.x but do have an older RT-AC68U running 3004.386.14.2 and YazFi which seem to have similar issues running YazDHCP 1.2.1, the Allow Guest Network Client Assignments option is grayed out and listed as unavailable. Initially after importing a updated YazDHCP CVS file that has a number of YazFi Guest Network clients added to it, the Allow Guest Network Client Assignments appeared to be enabled, but after a reboot the option is grayed out on 3004.386.14.2 and listed as unavailable. Tried several things like logging out and logging back in, reimporting the CVS file and applying the change, and rebooting. Nothing seemed to work, the Allow Guest Network Client Assignments option remains grayed out and not selectable.

Will troubleshoot a bit more on that old router when I have a bit more time.

Really good call @bennor.

Funny, I did think about this briefly but then looked at @Martinski signature (below) and thought, no, surely he must have tested it on an older rig too, despite the older versions of FW and addons in the sig. I don’t have such an animal immediately available to test it on, but kudos to you for testing it.

 

[bennor]

Really good call @bennor.

Updated my post above to include several screen shots from the RT-AC68U to provide context.

It was really strange. The Guest Network feature/option of YazDHCP seemed to work at first where I could enable or disable the feature, but then eventually stopped working with the option grayed out on the RT-AC68U after I rebooted.

 

[jksmurf]

Updated my post above to include several screen shots from the RT-AC68U to provide context.

It was really strange. The Guest Network feature/option of YazDHCP seemed to work at first where I could enable or disable the feature, but then eventually stopped working with the option grayed out on the RT-AC68U after I rebooted.

Thanks, it gives much more context to the issue and appears to duplicate exactly what the OP was referring to.

I thought by disabled @predatorz meant it said “No” but just revisiting the original comment, it seems I missed that “disabled” actually meant totally greyed out (as he already said the upper line said “No”). So again, great pickup.

When loaded, it will show red for Guest reservation address and Allow Guest Network Client Assignments as No and disabled for Currently

Poor fellow must have thought I was being a real smarty-pants when I practically said “works for me” … (apologies to @predatorz). I think we need @Martinski to take a wee look.

 

[bennor]

Some more testing with an RT-AC68U with 386.14_2 firmware and YazFi v4.4.8. Have manually uploaded via YazDHCP import a client list that includes two separate Guest Network groups of clients.

Can consistently replicate YazDHCP Allow Guest Network Client Assignment option winding up indicating Unavailable and the Yes/No option grayed out (unelectable) after the option was initially enabled and selectable. Actions performed using router GUI.

Method to reproduce:
Disconnect WAN from RT-AC68U router.
Boot router and access LAN > DHCP Server page. YazDHCP will not show as loaded, no manual client reservations listed.

With WAN disconnected the router System Log indicates repeated entries like the following: Dec 31 19:03:42 YazDHCP_[406]: Waiting for NTP to sync [180 secs]...

Connect WAN to router. (Above System Log messages stopped when WAN connected and NTP could sync.)
Navigate away from LAN > DHCP Server page, then navigate back to LAN > DHCP Server page. YazDHCP now properly loads. The Allow Guest Network Client Assignments option should be available for selection and indicate Disabled. Manual client reservations (including guest clients) should be listed.

Enable Allow Guest Network Client Assignments. Manual client reservations are color coded.

Apply the changes and the Allow Guest Network Client Assignments remains enabled and manual client reservations color coded.

REBOOT ROUTER (using router GUI reboot button)
When the router is rebooted and navigate back to LAN > DHCP Server page is when YazDHCP exhibits the Unavailable message, the Allow Guest Network Client Assignments is not selectable. Guest clients are marked in red.

Brave browser on Windows 11 with Brave addons uBlock Origin, Ghostery, FireShot, Kee (password manager) loaded. Brave Browser Console indicates the following on the LAN > DHCP Server page when YazDHCP indicates Unavailable.

If the router is rebooted (again with router GUI reboot button) with the WAN cable is removed, one can repeat the cycle again with the LAN > DHCP Server page not showing YazDHCP until the WAN cable is connected. Once WAN connected the YazDHCP Allow Guest Network Client Assignments option becomes enabled and shows Disabled, Guest client reservations again shown in Red. Everything with YazDHCP seems to work until router is rebooted at which point the Allow Guest Network Client Assignments option becomes Unavailable again.

Edit: System log portion via Paste Bin: https://pastebin.com/DCiuUcmP (valid for 7 days).

Hope this quick and dirty testing helps narrow down the cause.

 

[Ripshod]

System log wouldn't attach. Will include link at later time.

Rename as a .txt file and try again.

 

[bennor]

Rename as a .txt file and try again.

It was named with .txt, wouldn't show uploaded. Put on pastebin instead.

 

[bennor]

Some more testing with the RT-AC68U with 386.14_2 firmware, YazDHCP v1.2.1, and YazFi v4.4.8. This time using the YazDHCP Command Line Interface (CLI).

Powered on RT-AC68U. Router GUI > LAN > DHCP Server YazDHCP option Allow Guest Network Client DHCP IP Address Reservations indicates Unavailable. The YazDHCP CLI interface Allow Guest Network Client DHCP IP Address Reservations option indicates Disabled.

Using YazDHCP CLI, issued the gn command to enable Allow Guest Network Client DHCP IP Address Reservations option.
The YazDHCP CLI Allow Guest Network Client DHCP IP Address Reservations changed to Enabled.

Refreshed router GUI > LAN > DHCP Server YazDHCP page, YazDHCP Allow Guest Network Client DHCP IP Address Reservations changed to Enable.

Rebooted the router using the router GUI reboot button.
Post reboot, router GUI YazDHCP Allow Guest Network Client DHCP IP Address Reservations indicates Unavailable.

While the YazDHCP CLI Allow Guest Network Client DHCP IP Address Reservations indicates Disabled.

Tried several more cycles with the same result. Enable through the YazDHCP CLI and the Allow Guest Network Client DHCP IP Address Reservations option would be Enabled in both the YazDHCP GUI and YazDHCP CLI. However, once rebooted or if the router was physically powered off then back on (using power switch on back of router), both the YazDHCP GUI and YazDHCP CLI Allow Guest Network Client DHCP IP Address Reservations option would indicate Unavailable and Disabled respectively.

Been consistent on the RT-AC68U that when rebooted YazDHCP changes to Disabled in the CLI and Unavailable in the GUI. At least with the CLI one can select the enable (gn) option to reenable the Allow Guest Network Client DHCP IP Address Reservations option. With the GUI it was a bit more involved to reach the point where Allow Guest Network Client DHCP IP Address Reservations indicated Disabled, and not Unavailable, so one could enable the option in the GUI.

 

[jksmurf]

Some more testing with an RT-AC68U with 386.14_2 firmware and YazFi v4.4.8. Have manually uploaded via YazDHCP import a client list that includes two separate Guest Network groups of clients.

Some more testing with the RT-AC68U with 386.14_2 firmware, YazDHCP v1.2.1, and YazFi v4.4.8. This time using the YazDHCP Command Line Interface (CLI).

Wow @bennor you’ve really gone above and beyond here, I’m sure with all that detail @Martinski will be able to pinpoint it and fix it very readily. Star ️!

 

[Ripshod]

I have a little problem with v1.2.2 (develop), but the same with 1.2.1
I'm reinstalling everything from fresh but when I want to restore my custom icons the option is greyed out and a pop-up says there's no backup file in "/opt/var/SavedUserIcons". It's definitely there. I've tried deleting it and uploading it again, and I've tried rebooting. No go.

 

[Martinski]

I have a little problem with v1.2.2 (develop), but the same with 1.2.1
I'm reinstalling everything from fresh but when I want to restore my custom icons the option is greyed out and a pop-up says there's no backup file in "/opt/var/SavedUserIcons". It's definitely there. I've tried deleting it and uploading it again, and I've tried rebooting. No go.

Great find!! Thank you for reporting it. This was a timing issue when the WebUI requested data from the shell script about the custom user icons, but was checking for the results too early. Note that the CLI menu was correctly handling it, so you could also do the restoration via the CLI menu options ( 2 --> rt ).

Some more testing with an RT-AC68U with 386.14_2 firmware and YazFi v4.4.8. Have manually uploaded via YazDHCP import a client list that includes two separate Guest Network groups of clients.

Can consistently replicate YazDHCP Allow Guest Network Client Assignment option winding up indicating Unavailable and the Yes/No option grayed out (unelectable) after the option was initially enabled and selectable. Actions performed using router GUI.

Method to reproduce:
Disconnect WAN from RT-AC68U router.
Boot router and access LAN > DHCP Server page. YazDHCP will not show as loaded, no manual client reservations listed.

With WAN disconnected the router System Log indicates repeated entries like the following: Dec 31 19:03:42 YazDHCP_[406]: Waiting for NTP to sync [180 secs]...

Connect WAN to router. (Above System Log messages stopped when WAN connected and NTP could sync.)
Navigate away from LAN > DHCP Server page, then navigate back to LAN > DHCP Server page. YazDHCP now properly loads. The Allow Guest Network Client Assignments option should be available for selection and indicate Disabled. Manual client reservations (including guest clients) should be listed.

Enable Allow Guest Network Client Assignments. Manual client reservations are color coded.
...
Apply the changes and the Allow Guest Network Client Assignments remains enabled and manual client reservations color coded.

REBOOT ROUTER (using router GUI reboot button)
When the router is rebooted and navigate back to LAN > DHCP Server page is when YazDHCP exhibits the Unavailable message, the Allow Guest Network Client Assignments is not selectable. Guest clients are marked in red.
...
Brave browser on Windows 11 with Brave addons uBlock Origin, Ghostery, FireShot, Kee (password manager) loaded. Brave Browser Console indicates the following on the LAN > DHCP Server page when YazDHCP indicates Unavailable.

If the router is rebooted (again with router GUI reboot button) with the WAN cable is removed, one can repeat the cycle again with the LAN > DHCP Server page not showing YazDHCP until the WAN cable is connected. Once WAN connected the YazDHCP Allow Guest Network Client Assignments option becomes enabled and shows Disabled, Guest client reservations again shown in Red. Everything with YazDHCP seems to work until router is rebooted at which point the Allow Guest Network Client Assignments option becomes Unavailable again.

Edit: System log portion via Paste Bin: https://pastebin.com/DCiuUcmP (valid for 7 days).

Excellent troubleshooting and sleuthing!! Were you a System Test Engineer in a previous life?? LOL!!!

After reviewing the log you provided and the code around the startup sequence, it turns out this particular problem is due to a timing issue during the startup sequence between YazFi and YazDHCP. Upon reboot, the Guest Network interfaces created and set up by YazFi are not immediately configured and ready to go; it takes an extra minute or so until the YazFi GNs are set up and ready for clients to connect. In the meantime, during its own startup sequence, YazDHCP searches for any available Guest Network interfaces that are enabled and active in order to initialize and set up its internal files for presenting and maintaining the current configuration.

And the timing of this sequence of events can change widely depending on several factors (e.g. the startup order - who is starting up first: YazFi or YazDHP?, additional scripts also being launched and starting up in between during reboot, CPU load and processing speeds, etc.). In my case, with the simple configuration of the RT-AC86U, I didn't see the problem since, apparently, the timing was just right between YazFi and YazDHCP when starting up during reboots.

So I've modified/fixed some code in YazDHCP to allow 2 passes during its startup sequence in order to detect any available Guest Network interfaces that are enabled and active. These changes are in the latest 'develop' branch v1.2.2_25110123 version.

If you'd like to test and validate these latest changes, you can switch from production to 'develop' branch using the following command:

/jffs/scripts/YazDHCP develop

Thanks again for taking the time to test and troubleshoot the problem and for providing great reports. This kind of collaboration between users and developers is invaluable, and I fully appreciate it.

 

[bennor]

@Martinski, nice job on the quick turnaround for the v1.2.2_25110123 develop version. Seems to have fixed the RT-AC68U (386.14_2 / YazFi v4.4.8) issue with the YazDHCP Allow Guest Network Client DHCP IP Address Reservations Unavailable/Disabled when router powered on or when rebooted. Now shows Enabled for both the YazDHCP CLI and GUI after a reboot or when powering the router on. (Respective images attached.)

On a side note. Couple of other things I'm noticing. Not consistent but seems to happen from time to time, and which may be due to the RT-AC68U sitting behind a RT-AX86U Pro. When there is a NTP time sync issue delay in syncing on the RT-AC68U the YazDHCP portion of the GUI fails to load until the NTP syncs. When the YazDHCP fails to load the LAN DHCP Server page looks like default page without YazDHCP and with no manual client reservations listed. The NTP time sync delay or failure doesn't seem to happen consistantly but has happened several times over the two days of testing YazDHCP on the RT-AC68U. Usually see something like the following in the system log around the time there is an NTP issue and YazDHCP doesn't get populated in the GUI.

Nov  2 07:42:00 YazDHCP_[405]: Waiting for NTP to sync [90 secs]...
Nov  2 07:42:00 disk_monitor: be idle
Nov  2 07:42:01 YazDHCP_[405]: NTP has synced [90 secs]. YazDHCP will now continue.
Nov  2 07:42:19 YazDHCP_[405]: Mounting WebUI tab for YazDHCP...
Nov  2 07:42:19 YazDHCP_[405]: WebUI tab for YazDHCP was mounted.
Nov  2 07:42:51 crond[292]: time disparity of 967000 minutes detected
Nov  2 07:42:54 rc_service: httpd 311:notify_rc start_YazDHCPcheckUserIcons ; start_YazDHCPcheckGNetReservations
Nov  2 07:42:54 custom_script: Running /jffs/scripts/service-event (args: start YazDHCPcheckUserIcons)
Nov  2 07:42:55 custom_script: Running /jffs/scripts/service-event (args: start YazDHCPcheckGNetReservations)
Nov  2 07:43:06 YazDHCP_[7000]: DHCP IP address reservation list for Guest Network [wl0.2] remains unchanged
Nov  2 07:43:15 YazDHCP_[7000]: DHCP IP address reservation list for Guest Network [wl1.2] remains unchanged
Nov  2 07:43:15 YazDHCP_[7000]: DHCP IP address reservation list for main LAN [br0] remains unchanged

Also from time to time in the RT-AC68U system log post reboot or power on, I'm seeing entries that indicate a dnsmasq "unexpected fatal signal 11". Might be normal logging messages. But figured I'd mention it just in case.
Edit: Having trouble posting example dnsmasq unexpected fatal signal. Using Pastebin link instead:

https://pastebin.com/E6tD7zBA

(expires in 7 days)

 

[Martinski]

@Martinski, nice job on the quick turnaround for the v1.2.2_25110123 develop version. Seems to have fixed the RT-AC68U (386.14_2 / YazFi v4.4.8) issue with the YazDHCP Allow Guest Network Client DHCP IP Address Reservations Unavailable/Disabled when router powered on or when rebooted. Now shows Enabled for both the YazDHCP CLI and GUI after a reboot or when powering the router on. (Respective images attached.)

Thank you for testing and verifying the fix.

On a side note. Couple of other things I'm noticing. Not consistent but seems to happen from time to time, and which may be due to the RT-AC68U sitting behind a RT-AX86U Pro. When there is a NTP time sync issue delay in syncing on the RT-AC68U the YazDHCP portion of the GUI fails to load until the NTP syncs. When the YazDHCP fails to load the LAN DHCP Server page looks like default page without YazDHCP and with no manual client reservations listed. The NTP time sync delay or failure doesn't seem to happen consistantly but has happened several times over the two days of testing YazDHCP on the RT-AC68U. Usually see something like the following in the system log around the time there is an NTP issue and YazDHCP doesn't get populated in the GUI.

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.

Also from time to time in the RT-AC68U system log post reboot or power on, I'm seeing entries that indicate a dnsmasq "unexpected fatal signal 11".

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.