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

[JohnD5000]

BTW, today @Jack Yaz merged the PR that includes the changes/fixes for 2 recent issues: a) missing the "IPv6 DNS Server" option on the webGUI page, and b) the backup directory being reset to an alternative path.

To get the latest develop branch 1.0.6 version do the update with the following commands:

/jffs/scripts/YazDHCP develop
/jffs/scripts/YazDHCP forceupdate

Cheers mates!

When is 1.0.6 going to get approved/upgraded from development to production?

 

[Martinski]

When is 1.0.6 going to get approved/upgraded from development to production?

That decision is completely up to @Jack Yaz. I sent him a private message in early September, and another "ping" around the middle of October (about a month ago), and I have not heard back from him. He's usually pretty good at responding within a few days, so I just assumed he was really busy and would respond whenever he's able to, or perhaps he just forgot about it after a while (we all have personal lives & "stuff" to deal with, of course, so I can understand, especially since these add-ons are a very low priority for him now).

I hope @Jack Yaz is doing well and will eventually resurface whenever he can (I don't think he's "officially" left this forum, but I could be wrong).

 

[SomeWhereOverTheRainBow]

That decision is completely up to @Jack Yaz. I sent him a private message in early September, and another "ping" around the middle of October (about a month ago), and I have not heard back from him. He's usually pretty good at responding within a few days, so I just assumed he was really busy and would respond whenever he's able to, or perhaps he just forgot about it after a while (we all have personal lives & "stuff" to deal with, of course, so I can understand, especially since these add-ons are a very low priority for him now).

I hope @Jack Yaz is doing well and will eventually resurface whenever he can (I don't think he's "officially" left this forum, but I could be wrong).

Yea he hasn't said anything since August 10th. I hope he is doing well.

 

[JohnD5000]

That decision is completely up to @Jack Yaz. I sent him a private message in early September, and another "ping" around the middle of October (about a month ago), and I have not heard back from him. He's usually pretty good at responding within a few days, so I just assumed he was really busy and would respond whenever he's able to, or perhaps he just forgot about it after a while (we all have personal lives & "stuff" to deal with, of course, so I can understand, especially since these add-ons are a very low priority for him now).

I hope @Jack Yaz is doing well and will eventually resurface whenever he can (I don't think he's "officially" left this forum, but I could be wrong).

I don't know how this works. Assuming he has left the forum and the project, is this project something someone else could pick up? Or, does it need to be Jack (i.e. it is not open source)? Again, I don't know how this works and I'm just asking.

 

[heysoundude]

I don't know how this works. Assuming he has left the forum and the project, is this project something someone else could pick up? Or, does it need to be Jack (i.e. it is not open source)? Again, I don't know how this works and I'm just asking.

It's all there on a github that anyone can fork from and make it their own, and for some of these scripts/addons to survive moving forward, that's what's going to have to happen:
as the underlying firmware evolves, it will move past the coding and dependencies of the scripts as they were written and last maintained. right now what's happening is maintenance, so unless people step up and into the fray, theyre going to start to become unusable.
supporting unpaid users as a hobby can become tedious and burdensome, however, which is why few hats are being thrown in the ring.

 

[Jack Yaz]

I don't know how this works. Assuming he has left the forum and the project, is this project something someone else could pick up? Or, does it need to be Jack (i.e. it is not open source)? Again, I don't know how this works and I'm just asking.

 

[Jack Yaz]

Yea he hasn't said anything since August 10th. I hope he is doing well.

thanks. just very very busy!

 

[Viktor Jaep]

thanks. just very very busy!

Good to hear from you again, @Jack Yaz!

 

[SomeWhereOverTheRainBow]

thanks. just very very busy!

Yes, I understand all too well what it is like to go spelunking in the caves of life's mysteries. Great to hear from you man!

 

[Jack Yaz]

v1.0.6 is now available!

All credit for this release goes to @Martinski

NEW: "Back up & Restore custom user icons" option that provides a method to save & restore custom user icon image files and their corresponding icon-to-client associations.

Notes:

• The current implementation of "Back up & Restore custom user icons" does not export to or import from an external PC or client device connected to the router. Instead, it targets a directory available either on the router's JFFS partition or on a USB-attached disk drive. This target directory is where the subdirectory for backups is created and can be modified using the CLI menu (see note v1.0.3 #3 below).
• The CLI main menu option 2 for the "Back up & Restore" functionality will show up only if there is at least one custom user icon file found in the "/jffs/usericon" directory, or if at least one backup file is found in the directory path defined for backups. If none of those 2 conditions is met, option 2 will not show up in the main menu.
• To start using the "Back up & Restore custom user icons" feature, it's highly recommended to set the target directory where the subdirectory for backups is to be located (see option "dp" in the CLI menu). For the backups subdirectory to survive a "Factory Defaults Reset" of the router, it's highly recommended to use a directory path located on a disk drive plugged into one of the router's USB ports. You don't have to have Entware installed on the USB-attached disk; any USB disk drive formatted with either NTFS or ext4 is sufficient to use as storage for the backup files.

1. FIXED issue when uninstalling YazDHCP and the "dhcp_lease" NVRAM variable could be left behind with a value that was greater than 7 days which is considered "invalid" for the stock built-in "LAN - DHCP Server" webGUI page.
2. FIXED issue where the CLI menu option to "Export NVRAM settings" was no longer available after completing the YazDHCP installation.
3. FIXED issue where the webGUI "IPv6 DNS Server" option was not made visible when the IPv6 feature was enabled.
4. General Improvements:

• Avoid restarting dnsmasq too often whenever webGUI changes are made.
• Avoid calling the CLI shell script every time "/jffs/scripts/service-event" is executed for events unrelated to YazDHCP.
• Check for possible conflicts to avoid ending up with duplicate MAC or IP address settings in dnsmasq when exporting DHCP settings from NVRAM or when applying DHCP IP address reservations from the webGUI page.
• Added code to handle a possible scenario where the NVRAM values for "dhcp_staticlist" & "custom_clientlist" variables may be missing the first angle bracket as expected in their regular syntax.

 

[Kingp1n]

v1.0.6 is now available!

All credit for this release goes to @Martinski

NEW: "Back up & Restore custom user icons" option that provides a method to save & restore custom user icon image files and their corresponding icon-to-client associations.

Notes:

• The current implementation of "Back up & Restore custom user icons" does not export to or import from an external PC or client device connected to the router. Instead, it targets a directory available either on the router's JFFS partition or on a USB-attached disk drive. This target directory is where the subdirectory for backups is created and can be modified using the CLI menu (see note v1.0.3 #3 below).
• The CLI main menu option 2 for the "Back up & Restore" functionality will show up only if there is at least one custom user icon file found in the "/jffs/usericon" directory, or if at least one backup file is found in the directory path defined for backups. If none of those 2 conditions is met, option 2 will not show up in the main menu.
• To start using the "Back up & Restore custom user icons" feature, it's highly recommended to set the target directory where the subdirectory for backups is to be located (see option "dp" in the CLI menu). For the backups subdirectory to survive a "Factory Defaults Reset" of the router, it's highly recommended to use a directory path located on a disk drive plugged into one of the router's USB ports. You don't have to have Entware installed on the USB-attached disk; any USB disk drive formatted with either NTFS or ext4 is sufficient to use as storage for the backup files.

1. FIXED issue when uninstalling YazDHCP and the "dhcp_lease" NVRAM variable could be left behind with a value that was greater than 7 days which is considered "invalid" for the stock built-in "LAN - DHCP Server" webGUI page.
2. FIXED issue where the CLI menu option to "Export NVRAM settings" was no longer available after completing the YazDHCP installation.
3. FIXED issue where the webGUI "IPv6 DNS Server" option was not made visible when the IPv6 feature was enabled.
4. General Improvements:

• Avoid restarting dnsmasq too often whenever webGUI changes are made.
• Avoid calling the CLI shell script every time "/jffs/scripts/service-event" is executed for events unrelated to YazDHCP.
• Check for possible conflicts to avoid ending up with duplicate MAC or IP address settings in dnsmasq when exporting DHCP settings from NVRAM or when applying DHCP IP address reservations from the webGUI page.
• Added code to handle a possible scenario where the NVRAM values for "dhcp_staticlist" & "custom_clientlist" variables may be missing the first angle bracket as expected in their regular syntax.

Thank you @Jack Yaz & @Martinski !!!

 

[bennor]

@Martinski
To confirm. Is it normal, after updating to v1.0.6, to see the following YazDHCP entries in the system log when one visits the LAN > DHCP Server page?

rc_service: httpd 1256:notify_rc start_YazDHCPcheckIcons
custom_script: Running /jffs/scripts/service-event (args: start YazDHCPcheckIcons)
YazDHCP: **ERROR**: Backup directory [/opt/var/SavedUserIcons] NOT FOUND.
YazDHCP: Trying again with directory [/jffs/configs/SavedUserIcons]
YazDHCP: *WARNING*: Alternative Backup directory [/jffs/configs/SavedUserIcons]

It appears just visiting the DHCP server page now triggers "start_YazDHCPcheckIcons" which generates the errors/warnings due to not finding the directory when one isn't using a USB hard drive.
Edit: I should mention I don't use custom icons, only default stock icons included with the firmware.)

 

[Martinski]

@Martinski
To confirm. Is it normal, after updating to v1.0.6, to see the following YazDHCP entries in the system log when one visits the LAN > DHCP Server page?

rc_service: httpd 1256:notify_rc start_YazDHCPcheckIcons
custom_script: Running /jffs/scripts/service-event (args: start YazDHCPcheckIcons)
YazDHCP: **ERROR**: Backup directory [/opt/var/SavedUserIcons] NOT FOUND.
YazDHCP: Trying again with directory [/jffs/configs/SavedUserIcons]
YazDHCP: *WARNING*: Alternative Backup directory [/jffs/configs/SavedUserIcons]

It appears just visiting the DHCP server page now triggers "start_YazDHCPcheckIcons" which generates the errors/warnings due to not finding the directory when one isn't using a USB hard drive.
Edit: I should mention I don't use custom icons, only default stock icons included with the firmware.)

Yes, the "start_YazDHCPcheckIcons" is now a normal interface between the YazDHCP webGUI and its shell script. The call is made to find out if there are 1) any custom icon files found in the "/jffs/usericon" directory, and 2) any backups of custom icon files to be restored from a specified backup directory. If both of those conditions are false the "Back up icons" & "Restore icons" buttons on the webGUI are/remain disabled (i.e. grayed out) because there's nothing to do; otherwise, the corresponding button is enabled so you can perform the desired action. Note that the same checks are made (for the same reasons) when you manually execute the YazDHCP shell script.

Since you have no custom icons to save & no backups of custom icons to restore, you could try "turning off" the error/warning messages by manually editing the "/jffs/addons/YazDHCP.d/CustomUserIconsConfig" file and setting the following 2 configuration variables to some temporary directory on your router filesystem.

For example:

Icons_SAVED_DIR=/tmp/var/tmp/SavedUserIcons
Icons_PREFS_DIR=/tmp/var/tmp/SavedUserIcons

If at some point in the future, you decide to add custom icons for some client devices, you will then have to go into the YazDHCP CLI menu and select a more suitable & permanent directory where to save the backup files.

HTH.

 

[bennor]

Thanks for the explanation. Hopefully it will help explain things for others who see those messages and think somethings wrong.

 

[sebmack]

v1.0.6
Updated 2023-11-18

dhcp-optsfile contains a list of MAC address to DNS server address bindings, to provide the specified DNS server as a DHCP option for a MAC address

How does this interact/over-ride DNS director and DNS utilities. I have ctrld installed but also use DNS director (which overrides ctrld) to redirect some devices to 8.8.8.8 and DNS didn't work once I installed YazDHCP. Any suggestions? Tks.

 

[JGrana]

I noticed something today. I am using YazDHCP and see in /etc/dnsmasq.conf it adds:

addn-hosts=/jffs/addons/YazDHCP.d/.hostnames

That file has all my assigned IP/Hostnames. When dnsmasq starts, it reports that it read that file.

But, it doesn’t seem that dnsmasq actually uses it. For example, I have one of my servers called PlexMedia as:
192.168.1.7 PlexMedia

If I ping that name I get “name or service not known”.

If I add that line to /etc/hosts, it works fine.

Are there other settings I need to set or is something not working with dnsmasq?

 

[bennor]

Which router is having the issue and what firmware is it running?
Pinging a name listed in my /jffs/addons/YazDHCP.d/.hostnames file is working for me on a RT-AX86U Pro running YazDHCP. It returns the correct IP address (listed in .hostnames) and indicates a reply.

Have you tried a different device?
Have you rebooted the router?
Have you tried reinstalling YazDHCP?
Have you checked the permissions on the .hostnames file? It should be rw-rw-rw- or 0666.

 

[Tech9]

I noticed something today.

Yes, me too.

Are you looking for trouble?

 

[Viktor Jaep]

Yes, me too.

View attachment 56940 View attachment 56942

Are you looking for trouble?

I can't even tell you guys apart any longer... who is WHO!?

 

[SomeWhereOverTheRainBow]

I can't even tell you guys apart any longer... who is WHO!?

Striking isn't it.