YazFi YazFi DHCP lease times

[SomeWhereOverTheRainBow]

I was doing some more testing with my modified YazFi version so that I could "dot my i's and cross my t's" and make sure that I didn't break anything due to my recent code changes, and I found three GUI bugs (very trivial & really cosmetic) in the valid range validation for "DHCP Start" & "DHCP End" parameters. I did double-check the official YazFi installation, and the bugs were already there before my changes. As stated, the bugs are really cosmetic and do not actually result in any bad output or wrong action by the rest of the code.

In any case, my s/w developer "OCD tendencies" took over, and so I made fixes in both the shell script & the JavaScript source code.

Here are some screenshots of what was found and fixed:

View attachment 46048


View attachment 46049


View attachment 46050

If you want to have the latest fixes/changes, all updated files are in PasteBin.

We are not worthy!,,,, hahaha Again Great Work!.

 

[SomeWhereOverTheRainBow]

@Martinski, could you provide that link within PasteBin, please?

A link within a link!

 

[eightiescalling]

@Martinski Seems to be running well so far. There might have been once instance where the changes didn't get flushed in to /etc/dnsmasq.conf but I haven't been able to reproduce that.

One question on the code changes you've done.... I saw the new RetCode 2 being introduced to trigger a reload of config if the fixblanks section had made corrections but that only applies to leases despite (as far as I can tell) the logic technically being applicable for other config items. Any reason for that?

 

[L&LD]

A link within a link!

Mentioning PasteBin isn't a link. Finding the relevant information fast and accurately is what the question was for.

 

[Martinski]

@Martinski Seems to be running well so far. There might have been once instance where the changes didn't get flushed in to /etc/dnsmasq.conf but I haven't been able to reproduce that.

I recall seeing the same problem when I first installed YazFi and was setting up my Guest Networks; but, like you, I couldn't reproduce it afterward so I've never again looked at the possible causes. It's something that happens very rarely (at least in my experience with the add-on) and, whatever the cause, it's been there for some time.

One question on the code changes you've done.... I saw the new RetCode 2 being introduced to trigger a reload of config if the fixblanks section had made corrections but that only applies to leases despite (as far as I can tell) the logic technically being applicable for other config items. Any reason for that?

Yeah, back when I made my changes to add the "DHCP Lease Time" config parameter in the shell script (~8 months ago by now), I was concerned only with the code that I was adding/modifying and so "RetCode" was introduced. At the time, I didn't think about the other config variables. Now that you brought up the question, and after looking at that code again, I believe you've got a good point: the other config variables would benefit from a "reload" of the configuration file *after* any changes have been made to it within the function. IIRC, I think the "reload" is done later in another function as part of the execution flow, but sometimes it didn't work in my case with "DHCP Lease Time," hence the "RetCode=2" code.

Anyway, I've modified the shell script code (YazFi.v4.4.2.MOD.sh), and this updated version is now in PasteBin (same link as before).

HTH.

 

[Ripshod]

I made a little booboo, but I've recovered it okay.
I've been running the modified scripts and they have been running just fine. But I dropped the ball when running my weekly checks in amtm for updates. Without thinking I updated YazFi and to save anyone else finding out for themselves it totally messed up YazFi. I only found out when I went into the YazFi ui and noticed everything was set wrong - but it was working fine. After the update if I wanted to change any one setting I had to populate all the ip boxes, even those that were disabled. Recovered by installing the files in post 16 again.
There you go, one error and the fix. Or just don't update it.

 

[Martinski]

I made a little booboo, but I've recovered it okay.
I've been running the modified scripts and they have been running just fine. But I dropped the ball when running my weekly checks in amtm for updates. Without thinking I updated YazFi and to save anyone else finding out for themselves it totally messed up YazFi. I only found out when I went into the YazFi ui and noticed everything was set wrong - but it was working fine. After the update if I wanted to change any one setting I had to populate all the ip boxes, even those that were disabled. Recovered by installing the files in post 16 again.
There you go, one error and the fix. Or just don't update it.

Yeah, the modified config file "/jffs/addons/YazFi.d/config" that contains the new "wlxx_DHCPLEASE" variables is *not* compatible with the official YazFi versions (current or previous) because the "old" YazFi GUI doesn't take into account the new variables when parsing the file (i.e. doesn't expect them), and so the end result is that the user entry fields in the GUI panel are not populated correctly because they are "out of sync" with the config file, which is what you saw happen.

Sorry, I should have made it clear before about this incompatibility. If/when you indeed want to go back to the official version, just run the "Setup_YazFi_TEST.sh" script and then type "n" or "N" (for NO) when prompted about setting up YazFi for testing; it will then prompt you if you want to RESTORE the previous files.

BTW, if you mistakenly do an update again from AMTM, you could also restore the GUI entry fields by simply overwriting the modified config file with the backup copy of the original file (/jffs/addons/YazFi.d/config.ORIG.txt). Then you can set up YazFi again with the test files if you so choose.

HTH

 

[Jack Yaz]

@Martinski I just merged your PR, in theory running

YazFi develop

on a standard install will swap over to your updated version of the script. If all goes well in testing, i can merge it over to master

 

[Martinski]

@Martinski I just merged your PR, in theory running

YazFi develop

on a standard install will swap over to your updated version of the script. If all goes well in testing, i can merge it over to master

OK, that sounds good. Thanks.

 

[Martinski]

@Martinski I just merged your PR, in theory running

YazFi develop

on a standard install will swap over to your updated version of the script. If all goes well in testing, i can merge it over to master

OK, I finally had some time this weekend to do some testing (without getting those "death stares" from the family - yeah, you know what I'm talking about ).

Updating from YazFi's official "4.4.2" version to the new "develop" branch "4.4.3" went well, and I didn't have any issues during or after the transition. Before the update, I did however save the config file (/jffs/addons/YazFi.d/config) that I had created previously with my "4.4.3_AlphaX" test version, and then *after* the update, I overwrote the "4.4.2" config file with the saved version. This way I didn't have to recreate the configuration that was already working well, and that I was happy with.

IOW, for those who happen to be currently running the modified "4.4.3_AlphaX" files of YazFi that I provided before, here are the steps for a smooth upgrade transition.

1) Save the current configuration file containing the new "wlxx_DHCPLEASE" settings.

cp -fp  /jffs/addons/YazFi.d/config  /jffs/addons/YazFi.d/config.v4.4.3.SAVED.txt

2) Run the "/jffs/scripts/Setup_YazFi_TEST.sh" script and answer "n" or "N" to skip setting up YazFi for testing, and then answer "y" or "Y" to *RESTORE* the previous "4.4.2" version files.

3) After the files have been restored, and YazFi is up and running, delete the following files:

rm -f  /jffs/scripts/Setup_YazFi_TEST.sh 
rm -f  /jffs/scripts/YazFi.v4.4.2.MOD.sh
rm -f  /jffs/addons/YazFi.d/YazFi_www.asp.v4.4.2.MOD.ASP

4) Now run the following command to upgrade to the develop branch "4.4.3" version:

/jffs/scripts/YazFi  develop

5) After the upgrade to "4.4.3" has been completed *and* before doing anything else, overwrite the configuration file:

mv -f /jffs/addons/YazFi.d/config.v4.4.3.SAVED.txt  /jffs/addons/YazFi.d/config

6) Now you can use YazFi as usual, including its webGUI page.

HTH.

 

[Martinski]

If all goes well in testing, i can merge it over to master

FYI,
While doing testing, I found a couple of minor cosmetic bugs in the WebGUI validation messages affecting the 5GHz & 5GHz-2 Guest Networks.

Before the fixes:

After the fixes:

I've already submitted a PR to the "4.4.3" develop branch for the fixes.

 

[Martinski]

This past Saturday, a friend of mine who is running the latest YazFi 4.4.3 Develop branch on his ASUS router asked me if I could make the following 2 changes in YazFi:

1) Increase the maximum DHCP Lease Time from 7 days to 14 days so all his IoT devices in one of his Guest Networks can renew their reserved IP address only once per week (i.e. wl**_DHCPLEASE=14d).

2) Make the DHCP Lease Time input field in the YazFi WebGUI more user-friendly by allowing typing of entries such as "48h" or "14d" which correspond to "48 hours" and "14 days" lease times, respectively.

I've now completed & tested the modifications in both the shell script & the JavaScript code, and the DHCP Lease Time input field allows you to enter the value in seconds (e.g. 86400s), or minutes (e.g. 720m), or hours (e.g. 24h), or days (e.g. 10d) or weeks (e.g. 2w). Only positive integer values are allowed, so "24.5h" or "2.5d" are *not* valid input. If none of the valid suffixes is given (s, m, h, d, w) the default unit is seconds, so the new change is backward compatible with previously valid configuration settings.

Here is a screenshot showing an example of the new changes:

I will make a GitHub PR to @JackYaz for the Develop branch.

FYI.

 

[Martinski]

FYI,

@JackYaz has merged my latest changes into the YazFi "4.4.3" Develop branch.

1) Maximum DHCP Lease Time is 90 days.

2) Added a simple mechanism to set an "infinite" DHCP Lease Time value by allowing a single upper-case 'I' or a single ZERO '0' entry in the WebGUI to indicate the user wants to set an "infinite" lease time.

If you want to switch from the "4.4.2" production/stable version to the "4.4.3" Develop branch follow these 2 steps:

1) Switch to Develop branch & update using the 4.4.2 shell script.

/jffs/scripts/YazFi develop

2) Force update using the now-installed 4.4.3 shell script.

/jffs/scripts/YazFi forceupdate

 

[SomeWhereOverTheRainBow]

FYI,

@JackYaz has merged my latest changes into the YazFi "4.4.3" Develop branch.

1) Maximum DHCP Lease Time is 90 days.

2) Added a simple mechanism to set an "infinite" DHCP Lease Time value by allowing a single upper-case 'I' or a single ZERO '0' entry in the WebGUI to indicate the user wants to set an "infinite" lease time.

View attachment 47450

If you want to switch from the "4.4.2" production/stable version to the "4.4.3" Develop branch follow these 2 steps:

1) Switch to Develop branch & update using the 4.4.2 shell script.

/jffs/scripts/YazFi develop

2) Force update using the now-installed 4.4.3 shell script.

/jffs/scripts/YazFi forceupdate

I was thinking "0" would be a great option to indicate infinite, great work! I guess we telepathically agreed'. I wonder if the subnet range options can be ported over to YazDHCP for additional Lan option functionality in the webui. obviously we can already control the subnet range, but it would be awesome to have better control over the lease time in the webui.

 

[Martinski]

I was thinking "0" would be a great option to indicate infinite, great work! I guess we telepathically agreed'.

When I was writing the GitHub PR for @JackYaz to merge my 1st set of changes that increased the maximum value of DHCP Lease Time to 14 days, it occurred to me that at some point (perhaps in a few months, or a year) some user out there would request an increase to 30 days, or 60 days, or 100 days, so to preempt further requests to increase the maximum value, I figured that 90 days would satisfy 99.9% of use cases, and for the remaining 0.1% the "infinite" setting should meet their needs.

I wonder if the subnet range options can be ported over to YazDHCP for additional Lan option functionality in the webui. obviously we can already control the subnet range, but it would be awesome to have better control over the lease time in the webui.

I don't use the YazDHCP add-on so I can't say with absolute certainty. Still, given that both YazFi & YazDHCP use the same framework/infrastructure that was set up to support all WebGUI add-ons in Asuswrt-Merlin, I'm fairly sure the WebGUI Validator functions that I wrote in the JavaScript code to handle all the possible "DHCP Lease Time" input field entries can be easily ported over to YazDHCP. However, my 1st question would be: Where is the value from that input field stored?

If it's stored in a separate config file that YazDHCP controls, then porting over the code would be pretty simple; but, if the input field value is stored directly into a built-in NVRAM variable (e.g. "dhcp_lease"), like the built-in WebGUI does, then there might be some limitations or unintended side-effects because everyone else reading that built-in NVRAM variable is very likely still expecting the value to be in seconds and, therefore, any other settings (e.g. "24h" or "4d" or "infinite") would be treated as "bad" value.

One way to handle any possible issues is to create a separate config file for YazDHCP (similar to what YazFi has) and store the user input value there, then convert the value to seconds for the NVRAM setting. Bottom line, given enough time & motivation, I'd say porting the code is likely doable but again, I haven't looked at the YazDHCP source code to know with absolute certainty.

It would be a fun project, whichever way it turns out to be (don't tempt me, though!! ).

 

[SomeWhereOverTheRainBow]

(don't tempt me, though!! ).

I can't help it. I love to see the pro's at work.

 

[eightiescalling]

It would be a fun project, whichever way it turns out to be (don't tempt me, though!! ).

I don't think you need much tempting. Pretty sure your hand is already raised in case Jack is looking for a custodian to continue his work.

 

[Martinski]

I don't think you need much tempting. Pretty sure your hand is already raised in case Jack is looking for a custodian to continue his work.

Well, you called it: not much tempting was needed - just enough inquisitiveness and curiosity on my part...

This evening I took a look at and reviewed the YazDHCP source files and, as suspected, the "DHCP Lease Time" code that I wrote for YazFi can indeed be ported over and, with just a few modifications, be fitted for YazDHCP. I also found that the current YazDHCP code doesn't store the value from the "DHCP Lease" input field in a separate file so it gets eventually saved only to NVRAM (same behavior as the built-in webpage). This part will need to be modified to preserve the user-friendly input from the WebGUI and be able to populate the input field correctly every time.

I won't have any more time today (I have relatives coming over for dinner later this evening) but by late afternoon tomorrow, I should have some free hours and could start the work. Barring some unforeseen issues, I think I should be able to finish it by the end of the day and test it. We'll see how it goes.

FYI.

 

[Jack Yaz]

Well, you called it: not much tempting was needed - just enough inquisitiveness and curiosity on my part...

This evening I took a look at and reviewed the YazDHCP source files and, as suspected, the "DHCP Lease Time" code that I wrote for YazFi can indeed be ported over and, with just a few modifications, be fitted for YazDHCP. I also found that the current YazDHCP code doesn't store the value from the "DHCP Lease" input field in a separate file so it gets eventually saved only to NVRAM (same behavior as the built-in webpage). This part will need to be modified to preserve the user-friendly input from the WebGUI and be able to populate the input field correctly every time.

I won't have any more time today (I have relatives coming over for dinner later this evening) but by late afternoon tomorrow, I should have some free hours and could start the work. Barring some unforeseen issues, I think I should be able to finish it by the end of the day and test it. We'll see how it goes.

FYI.

Bare in mind the Addon API has a ceiling on the number of characters that can be passed through it. Adding DHCP field will reduce the number of DHCP reservations possible. Unless @RMerlin is able to increase the Addon API character limit, of course!

 

[Martinski]

Bare in mind the Addon API has a ceiling on the number of characters that can be passed through it. Adding DHCP field will reduce the number of DHCP reservations possible. Unless @RMerlin is able to increase the Addon API character limit, of course!

Yes, that's a very good point. I did see the code where you're checking against a maximum of "6498" for the total length of the value strings to be passed (not counting the "yazdhcp_clients*" key names), and then another check against the maximum limit of 8KB.

In the new code for the "DHCP Lease Time" input field, the worst-case scenario would be a value of "7776000" (90 days) which is 7 chars long; however, I suspect that given the options and the maximum limits, most people would choose the more user-friendly notation of "90d" which is only 3 chars long. In most cases, I'd expect people would use hours (e.g. "48h", "96h") or days (e.g. "5d", "14d") notation for the input field because it's just simpler to read and grasp at once (as opposed to a 5-to-7-digit number). So overall the loss of 3 chars (on average) may not be significant unless the user is just right at the edge of the maximum limit (close to 128 DHCP IP reservations?).

My 2 cents.