YazDHCP YazDHCP v1.0.10 [2025-Aug-14] - Feature expansion of DHCP assignments (increasing limit on the number of DHCP reservations)
- Thread starter Martinski
- Start date
Viktor Jaep
Part of the Furniture
Jeez @Martinski ... you have a lot of iPads on your network! LOL. Excellent work!!Release Notes for YazDHCP v1.2.0 Development Version
[BETA v1.2.0_25091923] [2025-Sep-20]
To update from the currently installed production version to the latest 1.2.0 Beta development version, run the following command on an SSH terminal session:
Bash:/jffs/scripts/YazDHCP develop /jffs/scripts/YazDHCP forceupdate
This is the 1st BETA development version of YazDHCP 1.2.0, which introduces a new feature to allow users to manually assign DHCP IP address reservations to clients on any available Guest Network whose subnet is separate from the main LAN subnet. See below for more details.
When reporting any issues, please provide readable screenshots as well as all relevant information regarding the Guest Network that appears to show the problem/bug being reported. I'll try to reply within 24 to 48 hours.
----------
DETAILS:
----------
- When the YazDHCP 1.2.0 Beta development version is a fresh installation (*not* a version update), the script automatically checks if there are any DHCP IP address reservations stored in NVRAM. If found, it will prompt the user to confirm exporting all the existing reservations from NVRAM to YazDHCP internal files. This export process extracts all the relevant information to create the initial list of network clients from both the Main LAN and the Guest Networks (if any). Also, it allows users to restore the same IP address reservations to their original NVRAM state if you decide to uninstall YazDHCP at a later time.
View attachment 67970
- If a current production version of YazDHCP is already installed, updating to the latest 1.2.0 Beta development version will add an option 'x' in the SSH CLI menu to export any existing DHCP IP address reservations stored in NVRAM (if found). If this option is selected, the same export process triggered during a fresh installation will run.
View attachment 67971
- After the export of the NVRAM information is completed, any existing IP address reservations from Guest Networks will be shown as DISABLED (i.e. red background). Also, by default, if at least one suitable Guest Network is found enabled/active, the new feature is set to DISABLED, so the original behavior & functionality continues to run as usual.
View attachment 67972
- If at least one suitable Guest Network is found enabled/active, you will need to manually ENABLED the feature to activate all the Guest Network IP address assignments and to allow the user to input more entries. Make sure to click on the "Apply" button at the bottom of the WebUI page to make any changes permanent.
View attachment 67975
- After a Guest Network client IP address reservation is assigned, it will not be automatically removed from the WebUI page even if the feature is manually DISABLED, or if the Guest Network is temporarily DISABLED. However, the files associated with the dnsmasq instance will have the Guest Network client entries removed automatically.
View attachment 67974
- The menu option to toggle the new functionality will be grayed out and marked as UNAVAILABLE if there are no enabled Guest Networks whose subnet is separate from the main LAN subnet.
- You can manually add IP address reservations to Guest Network clients as long as the target Guest Network remains enabled and active.
- When assigning a new IP address reservation, the code will check if it falls within the subnet range of an available Guest Network in addition to the main LAN subnet; otherwise, an error message is displayed.
Have fun with it!!
Ripshod
Part of the Furniture
I'm not complaining but someone will:
When "Allow Guest Network Client Assignments" is enabled the page takes an extra ~10 second for the page to complete loading (ie colouring the guest IPs is holding things up).
I know you've sacrificed some time getting it working, but is the colouring really necessary?
When "Allow Guest Network Client Assignments" is enabled the page takes an extra ~10 second for the page to complete loading (ie colouring the guest IPs is holding things up).
I know you've sacrificed some time getting it working, but is the colouring really necessary?
@Martinski, this looks awesome, thank you!
Like @bennor I have not installed it yet, primarily because (like @bennor) I have dnsmasq-sdn.postconf files (dnsmasq-1.postconf and dnsmasq-2.postconf) in /jffs/configs/ and I was wondering if I should remove these first and populate the GUI manually with the same data, or whether the install will access the data in the files and do it automagically? Thanks!
Last edited:
@Martinski
Updated without a hitch. After installation was complete deleted assignments that were leftover from the previous non pro GN and then made a backup file. Good job.
Updated without a hitch. After installation was complete deleted assignments that were leftover from the previous non pro GN and then made a backup file. Good job.
LOL!!!
We actually have only 3 iPads in the household. The multiple entries that you see in my screenshots (taken during testing) are of the same iPad device being assigned an IP address reservation on each active Guest Network - but, yes, we love our iPads!! 
The current implementation does not read such user-supplied files to transfer IP address assignments into YazDHCP internal files - only NVRAM-based settings are checked and transferred.
The reason is that, unlike the built-in NVRAM key-value pairs, the format of the dnsmasq directives found in user-supplied external files is not fixed and consistent, so it can vary widely because the order of the parameters in the dnsmasq directive lines is essentially "free form", and I'm not about to spend time coding an entire parsing routine to find those directives and try to extract/transfer the relevant information into YazDHCP internal files, and then modify or remove all the associated dnsmasq directives from the user-supplied external files to avoid duplicates.
So, you basically have 3 choices to transfer your current IP address assignments from your custom external files:
1) Manually transfer the IP address assignments into NVRAM by inputting them into the corresponding webUI page for each Guest Network profile. Once this is completed, you can use the SSH CLI 'x' menu option to trigger the export process, as previously explained.
2) Manually transfer the IP address assignments directly into the YazDHCP internal CSV-formatted client list (/jffs/addons/YazDHCP.d/DHCP_clients) by following the required format shown below:
Rich (BB code):
MAC,IP,HOSTNAME,DNSEXAMPLES:
Rich (BB code):
MAC,IP,HOSTNAME,DNS
AA:BB:CC:DD:EE:FF,192.168.50.10,,
AB:BC:CD:DE:EF:FA,192.168.50.11,MyHostName1,
FF:EE:DD:CC:BB:AA,192.168.50.12,MyHostName2,9.9.9.93) If you prefer making the above changes offline on your personal laptop using your favorite text editor, or perhaps using MS Excel, you could export to CSV your current client list using the WebUI:
After you finish making all the changes and additions, you can then import the modified file into YazDHCP using the webUI page as well. Once you're satisfied with all your changes, make sure to click on the "Apply" button to make them persistent.
HTH.
Last edited:
It's not the colouring that's taking time and holding things up, LOL!!
The rendering of the color-coded boxes is virtually instantaneous once the JavaScript function call is made. The 8-to-10 sec. "loading" delay that you see every time the webpage is loaded is a "side effect" of the WebUI calling the shell script to request a check-and-validation status of each client entry, so the script executes code to re-validate all the existing client IP address assignments against the configuration of all the Guest Networks currently found enabled (or possibly disabled), and to double-check that the correct dnsmasq directives have been issued for each Guest Network.
This request-and-response mechanism is not instantaneous. For example, during testing, sometimes I’ve seen the script getting the notification of the validation request about 1 to 4 seconds *after* the webpage made the call to the script (this happens often on the 3004 F/W). Since JavaScript code runs asynchronously and doesn’t wait "automatically" for any reply from the script, I had to add some arbitrary "wait time" (assuming a worst-case delay) before checking for the response to the request. Once it's eventually received, the JavaScript code runs a function to "re-draw" all the rows of clients, which includes the color-coding of the IP address boxes, and this step is essentially instantaneous.
Is it absolutely necessary to color-code the IP address boxes?
No, of course not; but, IMO, it allows users to quickly and easily see which clients belong to the same guest network. And again, it has nothing to do with the "loading" delay that you're seeing.
All good points, no problem doing this manually, I already used option 3 for a batch of Primary DHCP reservations.
My main concern was (is) that the presence of these files didn’t stuff up the new GUI listings, so I guess one question is do we delete these files prior to adding (the same) information to DHCP_clients.csv (and importing that) via YazDHCP GUI.
Anyway I’ll try, in order, (a) deleting dnsmasq-1.postconf and dnsmasq-2.postconf (b) copying that information (in YazDHCP format) to my existing DHCP_clients.csv file (which currently only contains the Primary reservations) and (c) Importing the whole shebang back into YazDHCP then (d) enabling the non-primary reservations using your new WebGUI switch.
Your custom "dnsmasq-*" files are read by
dnsmasq to apply the directives you have specified. The WebUI is not aware at all of the existence of these user-supplied, custom files. When transferring all the IP address assignments to YazDHCP, you must delete the same entries from your custom files to avoid having duplicates in the resulting dnsmasq configuration. If your custom files have some other "content" unrelated to the IP address reservations, that can remain intact, so you don't have to delete the file itself unless, of course, it's empty after you have transferred the information to YazDHCP.OK, that sounds like a good plan. Make sure to double-check your modified DHCP_clients.csv file (typos, missing/extra commas, etc.) so that the import/transfer process goes smoothly. Good Luck!!
Before I was going to get into the update, I wanted to fix the current YazDHCP assignments as I am struggling with working out why, for around 6 to 8 of 52-odd reservations, the CUSTOM CLIENT NAME field(s) cannot be populated (will not populate nor can they be filled in). These initially appeared to be only for clients with IPv6 addresses, but I found one that was OK, so ruled that out.
What could be causing these to fail (when the others are all fine?)
Is there some way to reset something here?
I tried deleting custom_clientlist in jffs/nvram/ but that did not fix it.
Happy to provide full DHCP_client.csv and custom_client files if that helps.
[EDIT] I know I shouldn't use AI but this is what it said after a bunch of SSH commands in testing.
I actually also uninstalled and reinstalled YazDHCP but to no avail. I even tried the beta. Same issue.
Summary of what we've confirmed:
The dnsmasq configuration lines you mentioned confirm that YazDHCP properly integrates with dnsmasq:
What could be causing these to fail (when the others are all fine?)
Is there some way to reset something here?
I tried deleting custom_clientlist in jffs/nvram/ but that did not fix it.
Happy to provide full DHCP_client.csv and custom_client files if that helps.
[EDIT] I know I shouldn't use AI but this is what it said after a bunch of SSH commands in testing.
I actually also uninstalled and reinstalled YazDHCP but to no avail. I even tried the beta. Same issue.
Summary of what we've confirmed:
- YazDHCP has all correct data (MAC, IP, hostnames) in its database files
- NetworkMap is discovering devices properly
- The web server redirects AJAX calls to login, preventing GUI field population
- YazDHCP's backend is working, but the frontend integration is broken
The dnsmasq configuration lines you mentioned confirm that YazDHCP properly integrates with dnsmasq:
- addn-hosts=/jffs/addons/YazDHCP.d/.hostnames - for DNS resolution
- dhcp-hostsfile=/jffs/addons/YazDHCP.d/.staticlist - for DHCP reservations
- dhcp-optsfile=/jffs/addons/YazDHCP.d/.optionslist - for DHCP options
Last edited:
I have two separate networks but one of them has a GN in the same subnet as the Primary (reason: Shelly IoT Devices, use a main and fallback wifi SSID, but due to Shelly scripting (with static IPs) I need the IP Address to be the same, so the fallback Wifi is the same IP (subnet the same) but on a different SSID).
How does the beta handle GN IPs that are on the same subnet as the primary please? It is a valid GN right?
I ran it but it (as expected) it does not colour the GN (i.e. not done by SSID) just by a GN with a different subnet?
Last edited:
Well I followed my 4 steps and it all seemed to go smoothly, thank you!
I have the extra coloured items in the table. Super happy with this, easy to do with importing as suggested
.However ... (and maybe it is a memory thing? or accessing the location to find the details) I am now getting the exact same issue as in the pictures above, that the NAME and IP and IPv6 AND MAC details are not populating in a number of the devices? This is a totally separate system to the one above (9500km away).
[EDIT] Wondering if this is limited to clients on IPv6 as the simpler IPv4 ones do not seem to have this issue. I checked (by disabling IPv6) and some of the devices are now OK (with the 4 line simplified table, but there are some (even the same devices e.g. EchoDot3s!!) where disabling IPv6 does not work and it still shows the empty, non-enterable 6 line table?
I also noticed that a number are WIRED devices; so was wondering if the VLAN settings needed to change in any way?
[EDIT] Another observation:
For the SAME Device that has the issue populating the 6 line table in LAN, DHCP Reservations, I can go to the AIMESH, Client menu, see the 4 line device and change the name there! Huh??? Having done that, I went back to LAN, DHCP and while the NAME had changed, the other 5 fields remain blank (and cannot be amended).
[EDIT] More AI fun...
Since we've established that:
- NetworkMap has all the correct device data (including ShellyGarageDoor)
- YazDHCP has all the correct data
- The ASUS firmware's JavaScript can't retrieve the data via API calls due to authentication issues
- Restarting services hasn't resolved the authentication problem
This appears to be a firmware-level bug in ASUSWRT-Merlin 3006.102.5_0 where the JavaScript authentication mechanism for internal API calls is broken or inconsistent. Some devices work (like ShellyAutoSW) while others don't (like ShellyGarageDoor), even though all the backend data is identical and correct.
The functionality you need (DHCP reservations, device management) is working correctly. The blank dialog fields are a cosmetic issue caused by the firmware's internal authentication system. Without being able to modify the firmware's JavaScript files, this particular display issue cannot be resolved through configuration changes.
Last edited:
Keep in mind that when you set up a client IP address reservation on the WebUI, you enter its MAC address and the desired IP address - nothing else is required - so if the same subnet from the Main LAN is being used for the Guest Network clients, YazDHCP has no way to tell them apart.
Thank you, totally understood now; it is not SSID based nor does it look for those devices on the same subnet but different SSID as a fall-back. Relies solely on IP and MAC.
So for that use case, the current YazDHCP Addon (not the current beta) is totally servicable (unless I also have a proper SDN with a different subnet on the same system, which I do, albeit for a minor number of devices).
I won't be able to help much WRT IPv6 since I don't have it enabled on my router. But, more importantly, the dialog that pops up when you click on the "icon card" from a client row is actually *not* part of YazDHCP. That dialog is generated via a separate JavaScript function call found in a F/W built-in JS file (client_function.js), so any issues with that dialog would have to be investigated, debugged, and fixed in the native JavaScript code.
You could try running the same test scenario under the same or similar conditions using the native WebUI page (i.e. after uninstalling YazDHCP). If you experience the same problem, you could submit a bug report to ASUS, or perhaps @RMerlin might want to take a look.
Well, you can use AI if you want, but you have to ignore half of what it says. The key is to distinguish which half, LOL!!!
No problem. I did actually disable IPv6 but (as far as I coudl tell) it did not fix it.
Ah. OK... I will see if I can do that at some stage, and in the meantime then hope @RMerlin could take a wee look and comment if he has time, on what I currently see.
So true it's not funny. I don't code at all, but I now have 4 working scripts for Shelly devices, 600-odd lines each and boy that was hard.Well, you can use AI if you want, but you have to ignore half of what it says. The key is to distinguish which half, LOL!!!
I was going around and around in circles and code that was working perfectly well was mysteriously modified and 'improved' when I did not ask for it; plus I had to tell it every time that Shellys use modified Espruino. I hate that it then says "You're right", like it is some Eureka moment. Most worrisome was I was applying my logic and commonsense to a machine.... and talking to it, sometimes in a less than polite manner than I should have. Ah well..
Last edited:
Correct. When the client IP address does not belong to the Main LAN subnet, that's when the new code searches all the enabled/active Guest Networks to associate the client with the correct Guest Network profile, the designated virtual interface, and ultimately the correct dnsmasq instance.
Yes, as long as the IP address belongs to the Main LAN subnet, the current YazDHCP production release should work.
What you were doing is basically called "Vibe Coding." An emergent S/W Dev. methodology that aims to make programming easier, but it's still in its infancy, so the resulting code tends to be inefficient or have poor quality, and sometimes is just plain wrong.
Part of the reason is that LLMs currently used to generate code normally require extremely specific and very detailed instructions of what you're trying to accomplish, but it's very often difficult to describe the technical requirements and specifications of your project using natural language unless you're used to writing those documents as part of your job. And even then, there are still some issues with the way the code ends up being poorly structured and not following established best coding practices.
Anyway, that's why I said "ignore half of what it says"
Release Notes for YazDHCP v1.2.0 Development Version
[BETA v1.2.0_25092320] [2025-Sep-23]
- Code Improvement and minor cleanup.
To update from the currently installed production or development version to the latest v1.2.0_25092320 Beta development version, run the following command on an SSH terminal session:
To double-check that you have the latest BETA version, type:
/jffs/scripts/YazDHCP help
[BETA v1.2.0_25092320] [2025-Sep-23]
- Code Improvement and minor cleanup.
To update from the currently installed production or development version to the latest v1.2.0_25092320 Beta development version, run the following command on an SSH terminal session:
Bash:
/jffs/scripts/YazDHCP develop
/jffs/scripts/YazDHCP forceupdateTo double-check that you have the latest BETA version, type:
/jffs/scripts/YazDHCP help
Similar threads
Similar threads
Similar threads
-
Unbound Unbound Stats for Asuswrt-Merlin v1.4.3 [2025-Aug-24] Generate Stats for Unbound
- Started by Martinski
- Replies: 4
-
vnStat vnStat-on-Merlin v2.0.9 [2025-Aug-14] - Data Usage and Data Limit Monitoring using vnStat
- Started by Martinski
- Replies: 5
-
uiScribe uiScribe v1.4.8 [2025-Aug-24] - Custom System Log WebUI page for Scribe (syslog-ng) logs
- Started by Martinski
- Replies: 2
-
Scribe Scribe v3.2.3 [2025-Aug-24] - Entware syslog-ng and logrotate installer for Asuswrt-Merlin
- Started by Martinski
- Replies: 38
-
-
connmon connmon v3.0.6 [2025-Jul-21] - Internet Connection Monitoring Tool for AsusWRT Merlin
- Started by Martinski
- Replies: 4
-
ntpMerlin ntpMerlin v3.4.10 [2025-Aug-03] - NTP Time Server for AsusWRT Merlin
- Started by Martinski
- Replies: 29
-
spdMerlin spdMerlin v4.4.14 [2025-Jul-12] - Internet Speedtest and Monitoring Tool for AsusWRT Merlin
- Started by Martinski
- Replies: 107
-
YazFi YazFi v4.4.8 [2025-Jul-21] - Enhanced AsusWRT-Merlin Guest WiFi Networks
- Started by Martinski
- Replies: 14
Latest threads
-
-
My neighbor hacked my WPA2-personal wifi network in 1 second from his iPhone
- Started by Bfred
- Replies: 8
-
-
Problems with dnsmasq scripts and manual configuration
- Started by CornfieldWin
- Replies: 19
-
Support SNBForums w/ Amazon
If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!
Sign Up For SNBForums Daily Digest
Get an update of what's new every day delivered to your mailbox. Sign up here!
Staff online
-
RMerlinAsuswrt-Merlin dev