YazDHCP YazDHCP - feature expansion of DHCP assignments (increasing limit on the number of DHCP reservations)

[Antonym8527]

Are you using DNS Director to force clients who try to ignore the Pi-Hole's, to use the Pi-Holes?
Example DNS Director:

I tried defining the Pi-hole IP 1 and 2 as User defined DNS1 and DNS2, but haven tried what you are suggesting. Let me give it a try if that solves the problem.

Edit: I don't have the DNS director option, is that another add-on/script? I have RT-AC68U

 

[bennor]

I tried defining the Pi-hole IP 1 and 2 as User defined DNS1 and DNS2, but haven tried what you are suggesting. Let me give it a try if that solves the problem.

Edit: I don't have the DNS director option, is that another add-on/script?

DNS Director is DNS Filter, just renamed in the Asus-Merlin 386.9 firmware (or the 388.x firmware) because there is an actual company called DNS Filter. This change is mentioned in the latest Asus-Merlin firmware release notes/change log.
https://www.asuswrt-merlin.net/changelog

Rebranded DNSFilter as DNS Director. This will prevent confusion with the company sharing the same name, and also better describes what the feature does.

 

[diabolyk]

I'm viewing all tour posts about DNS, i'm trying to learn all possibilities of this firmware...

But Can you explain what it is used for ?


Thanks

 

[visortgw]

DNS, aka Domain Name System, is the "phonebook of the Internet". DNS translates hostnames to IP addresses for all Internet activity.

 

[Antonym8527]

Are you using DNS Director to force clients who try to ignore the Pi-Hole's, to use the Pi-Holes?
Example DNS Director:

This worked. Thank you.

 

[Jack Yaz]

v1.0.5 is now available
All credit for this release goes to @Martinski

• IMPROVED: The WebGUI "DHCP Lease" input field has been enhanced to accept a maximum value of 7776000 seconds (90 days). Time values can be entered in seconds (e.g. 86400s), minutes (e.g. 1440m), hours (e.g. 24h), days (e.g. 2d), or weeks (e.g. 2w). A single digit ZERO '0' or an upper-case letter 'I' indicates that an "infinite" lease time value will be applied.

 

[Viktor Jaep]

v1.0.5 is now available
All credit for this release goes to @Martinski

• IMPROVED: The WebGUI "DHCP Lease" input field has been enhanced to accept a maximum value of 7776000 seconds (90 days). Time values can be entered in seconds (e.g. 86400s), minutes (e.g. 1440m), hours (e.g. 24h), days (e.g. 2d), or weeks (e.g. 2w). A single digit ZERO '0' or an upper-case letter 'I' indicates that an "infinite" lease time value will be applied.

Nice work, @Martinski!!

 

[SomeWhereOverTheRainBow]

v1.0.5 is now available
All credit for this release goes to @Martinski

• IMPROVED: The WebGUI "DHCP Lease" input field has been enhanced to accept a maximum value of 7776000 seconds (90 days). Time values can be entered in seconds (e.g. 86400s), minutes (e.g. 1440m), hours (e.g. 24h), days (e.g. 2d), or weeks (e.g. 2w). A single digit ZERO '0' or an upper-case letter 'I' indicates that an "infinite" lease time value will be applied.

I wonder what else @Martinski has up their sleeve! Way to go!

 

[Martinski]

Nice work, @Martinski!!

Thanks. It's a small contribution, building on top of @Jack Yaz 's excellent work, standing on his shoulders, as it were.

 

[Martinski]

I wonder what else @Martinski has up their sleeve! Way to go!

The YazFi 4.4.3 release should be coming soon as well, once @Jack Yaz finds the time between his other projects.

 

[JemTheWire]

This is probably my must valued add-on. Thank you all.

 

[JohnD5000]

I wonder what else @Martinski has up their sleeve! Way to go!

If @Martinski is looking for suggestions, adding the ability to save the image/icons attached to each client would be nice (I'm not sure if it is possible though).

 

[Martinski]

If @Martinski is looking for suggestions, adding the ability to save the image/icons attached to each client would be nice (I'm not sure if it is possible though).

I've never changed the icons assigned to client devices from the standard WebGUI so I don't know what issues currently exist with WRT saving/restoring the icons.

Is the problem that the icon images assigned to clients don't survive a reboot so you're forced to reassign the icons every time? Or, is it something else entirely?

I'm not committing at this point, but I'm certainly curious to understand what exactly the problem is. Can you elaborate and provide more context about what or where the issue is, if you don't mind?

 

[JohnD5000]

The icons do survive a reboot. However, one of the ways I use YazDHCP is when I occasionally perform a factory default reset and then re enter my configurations. One of the most time consuming is entering the DHCPs. YazDHCP speeds this up significantly. But, I like specific icons assigned to my clients. These need to be assigned by hand. It would be nice if YazDHCP could save and restore these, too. I'm assuming the icon assignment is stored with the DHCP data somewhere, Cut, I'm not sure how it works behind the scenes and if it is possible. But @SomeWhereOverTheRainBow was wondering what else you had coming, so I was just offering a suggestion.

 

[JGrana]

The icons do survive a reboot. However, one of the ways I use YazDHCP is when I occasionally perform a factory default reset and then re enter my configurations. One of the most time consuming is entering the DHCPs. YazDHCP speeds this up significantly. But, I like specific icons assigned to my clients. These need to be assigned by hand. It would be nice if YazDHCP could save and restore these, too. I'm assuming the icon assignment is stored with the DHCP data somewhere, Cut, I'm not sure how it works behind the scenes and if it is possible. But @SomeWhereOverTheRainBow was wondering what else you had coming, so I was just offering a suggestion.

I believe they are stored in the /jffs/usericon directory.
Maybe as part of the DHCP export, it checks for any files in that directory and saves it as well?

 

[Martinski]

The icons do survive a reboot. However, one of the ways I use YazDHCP is when I occasionally perform a factory default reset and then re enter my configurations. One of the most time consuming is entering the DHCPs. YazDHCP speeds this up significantly. But, I like specific icons assigned to my clients. These need to be assigned by hand. It would be nice if YazDHCP could save and restore these, too. I'm assuming the icon assignment is stored with the DHCP data somewhere, Cut, I'm not sure how it works behind the scenes and if it is possible. But @SomeWhereOverTheRainBow was wondering what else you had coming, so I was just offering a suggestion.

Ah, OK. Thanks for the explanation. And my apologies for the belated response (I've been very busy with work & family stuff).

So if I understood correctly, basically you want to be able to restore the icon images & the icon-to-client associations that existed prior to doing a factory defaults reset. Note that icon associations are not part of the DHCP functionality so those bindings would not necessarily be stored along with DHCP-related settings. The icon images happen to be shown on the same WebGUI page as the DHCP IP reservations because they're associated with the clients' presentation on the GUI.

I believe they are stored in the /jffs/usericon directory.

You're right. I just ran a quick test where I assigned custom icons to a couple of clients, and the "/jffs/usericon" directory was populated with some files, which apparently are "equivalent" to the custom icons, although it's still not crystal clear to me how the icon-to-client bindings work because some of the files have odd naming conventions (e.g. 2.log, 9.log, etc.) for icon images, and there is only one JSON file for one of the files. Also, it's yet to be determined if simply saving the files somewhere else, and then restoring them to the same folder *after* a factory defaults reset would be not only necessary but sufficient to fully restore the icon-to-client bindings. IOW, could there be something else "behind the curtains" of the ASUS code that I'm not aware of which is also required for the entire mechanism to be properly & fully restored?

In any case, I might have some time this coming weekend to take a further look and see what I can find, but I can't promise anything at this point.

EDIT:
P.S.
I just remember that I have a shell script (which I wrote a few years ago for a friend) that handles via simple menu selections the option to save files from a directory into time-stamped tarballs, and then the option to restore those files from one of the existing tarballs; also the option to delete the old archives that might have accumulated over time. Anyway, I believe I can reuse most of that script to target the "/jffs/usericon" folder and to test & check out the actual behavior & results of restoring the files *after* a factory defaults reset.

Oh man, I can just "feel the itch" to take the old script and modify it before going to bed...

 

[Martinski]

... However, one of the ways I use YazDHCP is when I occasionally perform a factory default reset and then re enter my configurations. One of the most time consuming is entering the DHCPs. YazDHCP speeds this up significantly. But, I like specific icons assigned to my clients. These need to be assigned by hand. It would be nice if YazDHCP could save and restore these, too.

I've modified my old script to specifically target the "/jffs/usericon" directory.

UPDATE [2023-Mar-09]
Given new information, the script has been updated as explained in post #294.

The script is now available in PasteBin:

mkdir -m 755 -p /jffs/scripts
curl -kLSs --retry 3 --retry-delay 5 --retry-connrefused pastebin.com/raw/6ZHZHpMk | tr -d '\r' > /jffs/scripts/SaveRestoreUserIcons.sh
chmod 755 /jffs/scripts/*.sh

With this script, one can easily create time-stamped tarballs of the "/jffs/usericon" directory, and then restore the icon images from a selected tarball. Note that by default the tarballs are created on the USB drive where Entware is installed (i.e. /opt/var/SavedUserIcons). If the USB drive is not available, then the archives are created in the "/jffs/scripts/SavedUserIcons" directory. You can change the default directory location by modifying the variable in the "CUSTOMIZABLE PARAMETERS SECTION."

userIconsSavedDir="/opt/var/SavedUserIcons"

Make sure that it's in a location that is persistent across reboots and across factory defaults resets so that the tarballs are available afterward to restore the files.

To run the script simply call it without any arguments. It's menu-driven so no other instructions are needed, IMO.

/jffs/scripts/SaveRestoreUserIcons.sh

Now, the next step is to test & verify if *after* a factory defaults reset, restoring all the icon images & files into the "/jffs/usericon" directory is sufficient to fully & properly re-establish the icon-to-client associations that are ultimately shown on the WebGUI. Obviously, the only way to do that is to do the factory reset. Currently, it's not a good time for me to reset my router in the middle of a busy work schedule, plus the kids' & wife's work/school responsibilities, but if you can and want to try it out, please let us know of the results. Without knowing with certainty that the current hypothesis is correct, I wouldn't really want to modify YazDHCP.

 

[dave14305]

Also, it's yet to be determined if simply saving the files somewhere else, and then restoring them to the same folder *after* a factory defaults reset would be not only necessary but sufficient to fully restore the icon-to-client bindings. IOW, could there be something else "behind the curtains" of the ASUS code that I'm not aware of which is also required for the entire mechanism to be properly & fully restored?

The numbers in the icon filenames should match the numbers in the 4th field of each client entry in the custom_clientlist nvram var.

 

[Martinski]

The numbers in the icon filenames should match the numbers in the 4th field of each client entry in the custom_clientlist nvram var.

Thank you! Yes, that certainly seems to be where each icon is linked to a specific client. BTW, the client's MAC address is used as well for some icon filenames.

I've modified the shell script to save also the "custom_clientlist" NVRAM variable (whether it's a file, an actual NVRAM entry, or both) along with the icon images so that when called to restore the icons, the NVRAM variable is recreated as well.

The script in PasteBin has already been updated with the latest version, so if someone is planning to do a factory defaults reset in the next few days you can try to see if the script works for you.

I ran a simple test to check if in fact the icon-to-client bindings would be restored. Here are the steps I took:

1. Log off the router's WebGUI and open an SSH terminal window.
2. Run my latest script to create a time-stamped tarball and save it on the USB drive.
3. Delete *all* files inside the "/jffs/usericon" directory.
4. Unset the "custom_clientlist" NVRAM variable (i.e. nvram unset custom_clientlist).
5. Make sure the file "/jffs/nvram/custom_clientlist" (if available) is empty or removed.
6. Login back onto the router's WebGUI and check if any previous icon-to-client associations are still shown. In my case, the 4 client devices that previously had custom icons reverted to their default icons.
7. Log off the router's WebGUI.
8. Run my latest script to restore the icon images along with the NVRAM var.
9. Login back onto the router's WebGUI and verify if the custom icons are now shown for each client as expected. In my case, they were indeed back.

Now, as the saying goes, the "proof is in the pudding" and the ultimate test would be to do a factory defaults reset, but I can't do it within the next 8 days or so (I have a work deadline on March 17th).

Anyway, it's looking good so far. Thanks again to @JGrana & @dave14305 for providing very useful pieces of information.

 

[Martinski]

Last weekend, I finally had some free time to do a factory defaults reset on my RT-AC86U router before I upgraded to the 386.10 F/W version and also took the opportunity to test & verify that the custom user icons that were previously saved with my modified shell script were then properly restored with the corresponding icon-to-client bindings fully in place.

Everything went very well so I decided to port my script into the YazDHCP add-on and also added some more menu-driven options as well as more error handling and reporting.

I've submitted a GitHub PR to @JackYaz to merge the implementation into his 'develop' branch.

Note that I do plan to add some WebGUI support eventually, but I've been very busy with my work projects recently (and likely to be in the near future) that I haven't had the time (and the weekends have been busy as well). Anyway, the YazDHCP shell script changes/additions offer what I believe to be a good implementation with menu-driven CLI options which are fairly self-explanatory (IMO). In the meantime, if you want to have a "test drive" just let me know and I can provide the script.

Just FYI.