YazDHCP YazDHCP v1.0.10 [2025-Aug-14] - Feature expansion of DHCP assignments (increasing limit on the number of DHCP reservations)

[Ripshod]

Bangin' beta

Will be thoroughly tested

 

[Viktor Jaep]

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:

/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!!

Jeez @Martinski ... you have a lot of iPads on your network! LOL. Excellent work!!

 

[Ripshod]

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?

 

[jksmurf]

@Martinski, haven't installed the beta yet, but do have a question. For the Guest Network Pro profile IP reservations, does the Beta only pull those reservations from NVRAM? Or does the Beta also check and pull the reservations from dnsmasq-INDEX.conf.add or dnsmasq-sdn.postconf file if those are used for the manual reservations instead of using the Guest Network Pro profile's Manually assigned IP around the DHCP list option (which are saved to NVRAM)?

@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!

 

[donbru]

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

 

[Martinski]

Jeez @Martinski ... you have a lot of iPads on your network! LOL. Excellent work!!

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!!

 

[Martinski]

@Martinski, haven't installed the beta yet, but do have a question. For the Guest Network Pro profile IP reservations, does the Beta only pull those reservations from NVRAM? Or does the Beta also check and pull the reservations from dnsmasq-INDEX.conf.add or dnsmasq-sdn.postconf file if those are used for the manual reservations instead of using the Guest Network Pro profile's Manually assigned IP around the DHCP list option (which are saved to NVRAM)?

@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!

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:

MAC,IP,HOSTNAME,DNS

EXAMPLES:

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

Once you have finished adding all the entries into the internal client list file, you can use the SSH CLI '1' menu option to process the newly-modified list.

3) 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.

 

[Martinski]

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?

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.

 

[jksmurf]

3) If you prefer doing the above changes offline on your personal laptop using your preferred text editor, or perhaps using MS Excel, you could export to CSV your current client list using the WebUI:

View attachment 67987

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.

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.

 

[Martinski]

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.

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.

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.

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!!