YazDHCP YazDHCP v1.2.2 [2025-Nov-03] - 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.