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

[TheLyppardMan]

The problem is caused by the blank spaces in your directory path. Most likely I missed a couple of places where file globbing was not properly set up when searching for the list of backup files within a directory path that happens to include one or more blank spaces.

I'll take a look at this tomorrow. That's a good catch, BTW.

In the meantime, if you want to keep the backup files safely stored, use a directory path *without* any blank spaces.

Thanks for the update. I've saved the backup file to a folder on my Synology Diskstation (where I store all my data) in case I need it in the future. BTW, if I did a full factory reset and then imported a configuration file made when using the same firmware build, would that restore all my DHCP static IP assignments as well or would I still need to set up YazDHCP again and then copy my backups back onto the USB flash drive ready for restoring that way?

 

[TheLyppardMan]

I've removed the spaces from the folder name. Would this be a correct routine for restoring the static IP clients and user icons?

 

[Martinski]

I've removed the spaces from the folder name. Would this be a correct routine for restoring the static IP clients and user icons?

View attachment 50689

Yeah, you got the gist of it and the overall steps are OK although some of the phrasings seem incorrect (and yes, I know; from an outside observer, this falls on the pedantic side, but when part of your job is reading & writing functional specs & requirements documents, and dealing with other s/w & h/w engineers on a daily basis, using the standard correct terminology to try to communicate more clearly & effectively becomes automatic & second nature).

So if you don't mind my take, here is a revised version for your purposes:

1) Install the YazDHCP add-on.

2) Make sure your LAN IP address, subnet mask & DHCP IP pool range is set up to accept the IP address reservations that you're going to import next.

3) Import the CSV file "DHCP_clients.csv" which contains the list of DHCP IP address reservations & hostnames.

4) If restoring the custom user icons, recreate the same backup folder path used before if it doesn't already exist (e.g. "/xxx/yyy/DHCP_UserIconsBackups/SavedUserIcons" - including the backup files) on the USB-attached disk drive (Note: YazDHCP is *not* installed on the USB drive but on the JFFS partition).

5) Make sure that YazDHCP is set up to back up & restore the user icons to/from the specified folder path on the USB disk drive.

6) Use the "Back up & Restore" facility (either from the YazDHCP webGUI or the CLI menu) to restore the custom user icons.

BTW, I ran out of time today to start looking into the problem you found. Perhaps after dinner I can have a brief look, but I doubt I'll be able to finish. Most likely I won't return to it until sometime next weekend.

 

[Martinski]

I'm just trying this out for the first time. I can run the user icons backup, but when I try to restore them, it says there are no backup files available. Am I doing something wrong?

I found where & what is causing the problem with backup directory paths containing blank spaces. I already have a fix, and initial tests look good. I'll finish up tomorrow evening and submit a GitHub PR.

FYI.

 

[TheLyppardMan]

Yeah, you got the gist of it and the overall steps are OK although some of the phrasings seem incorrect (and yes, I know; from an outside observer, this falls on the pedantic side, but when part of your job is reading & writing functional specs & requirements documents, and dealing with other s/w & h/w engineers on a daily basis, using the standard correct terminology to try to communicate more clearly & effectively becomes automatic & second nature).

So if you don't mind my take, here is a revised version for your purposes:

1) Install the YazDHCP add-on.

2) Make sure your LAN IP address, subnet mask & DHCP IP pool range is set up to accept the IP address reservations that you're going to import next.

3) Import the CSV file "DHCP_clients.csv" which contains the list of DHCP IP address reservations & hostnames.

4) If restoring the custom user icons, recreate the same backup folder path used before if it doesn't already exist (e.g. "/xxx/yyy/DHCP_UserIconsBackups/SavedUserIcons" - including the backup files) on the USB-attached disk drive (Note: YazDHCP is *not* installed on the USB drive but on the JFFS partition).

5) Make sure that YazDHCP is set up to back up & restore the user icons to/from the specified folder path on the USB disk drive.

6) Use the "Back up & Restore" facility (either from the YazDHCP webGUI or the CLI menu) to restore the custom user icons.

BTW, I ran out of time today to start looking into the problem you found. Perhaps after dinner I can have a brief look, but I doubt I'll be able to finish. Most likely I won't return to it until sometime next weekend.

Thanks for that. Setting the IP pool range is normally one of my first jobs, once I have the initial setup complete (WAN settings including VLAN tag for my ISP), router user name/password, Wi-Fi settings (channels, bandwidth, SSID names, passwords), etc. Then I usually work my way down the GUI, making any changes needed as I go. So, now I'll add the above list of additional things, after adding a newly-formatted flash drive. I've also set an automatic backup in an earlier copy of SyncBackPro to copy any saved usericon files from the flash drive on my router to my data share on my Synology NAS.

 

[Martinski]

Finished testing the fixes/improvements made to handle correctly directory paths containing one or more blank spaces. Thanks to @TheLyppardMan for finding & reporting the bug.

Here are some screenshots:

A GitHub PR has already been submitted to the YazDHCP 'develop' branch.

FYI.

 

[TheLyppardMan]

I've now created two new profiles in my backup software (SyncBackPro) to automatically copy any downloads of the DHCP_Clients file and any new files added to the SavedUserIcons folder to a backup folder on my NAS (and this gets backed up automatically every day at 01:00 to the cloud using the IDrive app on my Synology Diskstation).

 

[Martinski]

Finished testing the fixes/improvements made to handle correctly directory paths containing one or more blank spaces. Thanks to @TheLyppardMan for finding & reporting the bug.
....

A GitHub PR has already been submitted to the YazDHCP 'develop' branch.

@Jack Yaz has merged the PR containing the changes/fixes described above into the YazDHCP 'develop' branch.

If you want to switch from the current master branch 1.0.5 version to the develop branch 1.0.6 version run the following command:

/jffs/scripts/YazDHCP develop

If your add-on is already on the develop branch, do the update with the following command:

/jffs/scripts/YazDHCP forceupdate

FYI.

 

[SomeWhereOverTheRainBow]

@Jack Yaz has merged the PR containing the changes/fixes described above into the YazDHCP 'develop' branch.

If you want to switch from the current master branch 1.0.5 version to the develop branch 1.0.6 version run the following command:

/jffs/scripts/YazDHCP develop

If your add-on is already on the develop branch, do the update with the following command:

/jffs/scripts/YazDHCP forceupdate

FYI.

One issue I noticed is some newer model routers have an option to specify a lan dhcp address for ipv6, but YazDhcp covers up this webui option. Is there a fix for this?

 

[Martinski]

One issue I noticed is some newer model routers have an option to specify a lan dhcp address for ipv6, but YazDhcp covers up this webui option. Is there a fix for this?

For development purposes, I have access to only two ASUS AC-class routers so that limits what I can do WRT newer AX-class routers, and I don't have IPv6 enabled on my own router. This means that it's very unlikely that I'll be able to take a look at what the problem is & see what it would take to fix any IPv6-related issues on YazDHCP running on newer router models.

 

[SomeWhereOverTheRainBow]

For development purposes, I have access to only two ASUS AC-class routers so that limits what I can do WRT newer AX-class routers, and I don't have IPv6 enabled on my own router. This means that it's very unlikely that I'll be able to take a look at what the problem is & see what it would take to fix any IPv6-related issues on YazDHCP running on newer router models.

Don't quote me on this, but I believe the option is present whether or not IPV6 is enabled. This is on an RT-AX88U_PRO running 388.3_0 firmware.

The NVRAM variable is

ipv6_dns1_x

as appose to the traditional ipv6 variables

ipv6_dns1=
ipv6_dns2=
ipv6_dns3=

use for manually setting the WAN DNS for ipv6.

It is probably specifically only visible for 388.x firmware when ipv6 option is enabled.

If there is away I can share more information that would help I would be willing.

 

[SomeWhereOverTheRainBow]

@Martinski

Here is a copy of the default .asp, the nvram variable is ipv6_dns1_x. If I knew how to properly copy it over or apply it to YazDHCP, I would.

This is what it looks like on the default page.

 

[SomeWhereOverTheRainBow]

For development purposes, I have access to only two ASUS AC-class routers so that limits what I can do WRT newer AX-class routers, and I don't have IPv6 enabled on my own router. This means that it's very unlikely that I'll be able to take a look at what the problem is & see what it would take to fix any IPv6-related issues on YazDHCP running on newer router models.

I completely understand if your limited time and resources prevent you from looking further into this issue. However, if the resources I have provided above is a good starting point for you to come up with something that could be tested, I would be completely willing to devote my time and resources to testing it. What ever you choose to do, I still look forward to your next endeavors. Thank you for everything you do.

 

[Martinski]

The NVRAM variable is

ipv6_dns1_x

as appose to the traditional ipv6 variables

ipv6_dns1=
ipv6_dns2=
ipv6_dns3=

use for manually setting the WAN DNS for ipv6.

It is probably specifically only visible for 388.x firmware when ipv6 option is enabled.

I have all those NVRAM variables available on both my RT-AC86U & my cousin's RT-AX86S router:

But I don't see any IPv6-related option on the "LAN - DHCP Server" webGUI tab of the RT-AX86S (which is running the latest 388.2_2 f/w *without* the YazDHCP add-on installed), so it seems that there's something specific that enables the visibility of the IPv6 option.

Here is a copy of the default .asp, the nvram variable is ipv6_dns1_x. If I knew how to properly copy it over or apply it to YazDHCP, I would.

This is what it looks like on the default page.

View attachment 50953

I appreciate your offer to share more detailed info. I'll review the code in the ASP file and see if I can glean more details from it to have at least a better idea of what's going on. However, without an AX-class router readily available for s/w development & testing purposes (and no, my cousin's router would not be - it's available for me to help him with the router's maintenance & updates), and probably having IPv6 enabled, I'd be writing & trying to test code with "one hand tied behind my back and an eye patch covering my good eye."

Anyway, at this point, I can't promise anything other than "I'll take a look." However, I won't have enough time in the next 2 weekends (Father's Day here in the US next weekend, and attending an out-of-state college graduation celebration the following weekend), so likely nothing will happen until July.

 

[SomeWhereOverTheRainBow]

I have all those NVRAM variables available on both my RT-AC86U & my cousin's RT-AX86S router:

View attachment 50954

View attachment 50955

But I don't see any IPv6-related option on the "LAN - DHCP Server" webGUI tab of the RT-AX86S (which is running the latest 388.2_2 f/w *without* the YazDHCP add-on installed), so it seems that there's something specific that enables the visibility of the IPv6 option.



I appreciate your offer to share more detailed info. I'll review the code in the ASP file and see if I can glean more details from it to have at least a better idea of what's going on. However, without an AX-class router readily available for s/w development & testing purposes (and no, my cousin's router would not be - it's available for me to help him with the router's maintenance & updates), and probably having IPv6 enabled, I'd be writing & trying to test code with "one hand tied behind my back and an eye patch covering my good eye."

Anyway, at this point, I can't promise anything other than "I'll take a look." However, I won't have enough time in the next 2 weekends (Father's Day here in the US next weekend, and attending an out-of-state college graduation celebration the following weekend), so likely nothing will happen until July.

That is perfectly fine. I am also approaching fathers day (and my wifes birthday). We have big plans from the 15th to the 20th. No big time crunch for a fix. As far as I can tell, my nvram variable is still intact. even with YazDhcp mounted over the default .asp.

 

[Martinski]

I completely understand if your limited time and resources prevent you from looking further into this issue. However, if the resources I have provided above is a good starting point for you to come up with something that could be tested, I would be completely willing to devote my time and resources to testing it. What ever you choose to do, I still look forward to your next endeavors. Thank you for everything you do.

Well, as usual, my innate curiosity prevailed once again. After dinner & some rest, I couldn't resist so I ended up reviewing the ASP file, and it turned out that the port of the IPv6-related code seemed fairly straightforward, so I went ahead and did it. Also, it became clear that IPv6 must be enabled so that the "IPv6 DNS Server" option becomes visible on the "LAN - DHCP Server" webGUI page. This is true even on my RT-AC86U running 386.10_0 F/W.

I'll post instructions shortly so you can download & set up the newly modified ASP file (after I run some testing on my own router just to make sure nothing was broken due to the port).

[To be continued...]

TO CONTINUE:
Here are the instructions so you can test the modified ASP file:

1) Make sure your YazDHCP add-on is on the latest develop branch 1.0.6 version.

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

2) Download the modified ASP file from PasteBin.

curl -kLSs --retry 3 --retry-delay 5 --retry-connrefused pastebin.com/raw/He2phbxJ | tr -d '\r' > /jffs/addons/YazDHCP.d/Advanced_DHCP_Content.asp.MOD.TEST.txt
chmod 644 /jffs/addons/YazDHCP.d/Advanced_DHCP_Content.asp.MOD.TEST.txt

3) Save your "original" ASP file by renaming it.

mv -f /jffs/addons/YazDHCP.d/Advanced_DHCP_Content.asp  /jffs/addons/YazDHCP.d/Advanced_DHCP_Content.asp.SAVE.txt

4) Replace the "original" ASP file with the new TEST version:

cp -fp /jffs/addons/YazDHCP.d/Advanced_DHCP_Content.asp.MOD.TEST.txt  /jffs/addons/YazDHCP.d/Advanced_DHCP_Content.asp

5) Reboot your ASUS router.

6) While the router reboots, I'd recommend clearing the cache of the web browser you use to log in to the router.

7) Once the router reboots, log in and check if the "IPv6 DNS Server" option is now available on YazDHCP and that it works as expected.

If you later want to go back to the "original" ASP file, simply copy the file over the TEST version and reboot again.

HTH.

 

[TheLyppardMan]

I've now created two new profiles in my backup software (SyncBackPro) to automatically copy any downloads of the DHCP_Clients file and any new files added to the SavedUserIcons folder to a backup folder on my NAS (and this gets backed up automatically every day at 01:00 to the cloud using the IDrive app on my Synology Diskstation).

View attachment 50824

Slight problem - the save location I have specified on my USB flash drive keeps being changed back to the default location in jffs/configs. It seems to happen when I have changed some settings on my router. For example, today, I made some changes to my wireless network, after which I noticed that the leds had come back on (normally I leave them switched off by means of the button on the back of the router because they are so bright). Could that be a clue to what might be going on here?

 

[Stephen Harrington]

Slight problem - the save location I have specified on my USB flash drive keeps being changed back to the default location in jffs/configs.

I have noticed that if I update or force update YazDHCP it goes back to the default /jffs/configs save location and I have to re-point it to my preferred location on my external SSD every time. @Martinski as a suggestion it would be extra nice if the location "stuck" between updates?

 

[SomeWhereOverTheRainBow]

Well, as usual, my innate curiosity prevailed once again. After dinner & some rest, I couldn't resist so I ended up reviewing the ASP file, and it turned out that the port of the IPv6-related code seemed fairly straightforward, so I went ahead and did it. Also, it became clear that IPv6 must be enabled so that the "IPv6 DNS Server" option becomes visible on the "LAN - DHCP Server" webGUI page. This is true even on my RT-AC86U running 386.10_0 F/W.

I'll post instructions shortly so you can download & set up the newly modified ASP file (after I run some testing on my own router just to make sure nothing was broken due to the port).

[To be continued...]

TO CONTINUE:
Here are the instructions so you can test the modified ASP file:

1) Make sure your YazDHCP add-on is on the latest develop branch 1.0.6 version.

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

2) Download the modified ASP file from PasteBin.

curl -kLSs --retry 3 --retry-delay 5 --retry-connrefused pastebin.com/raw/He2phbxJ | tr -d '\r' > /jffs/addons/YazDHCP.d/Advanced_DHCP_Content.asp.MOD.TEST.txt
chmod 644 /jffs/addons/YazDHCP.d/Advanced_DHCP_Content.asp.MOD.TEST.txt

3) Save your "original" ASP file by renaming it.

mv -f /jffs/addons/YazDHCP.d/Advanced_DHCP_Content.asp  /jffs/addons/YazDHCP.d/Advanced_DHCP_Content.asp.SAVE.txt

4) Replace the "original" ASP file with the new TEST version:

cp -fp /jffs/addons/YazDHCP.d/Advanced_DHCP_Content.asp.MOD.TEST.txt  /jffs/addons/YazDHCP.d/Advanced_DHCP_Content.asp

5) Reboot your ASUS router.

6) While the router reboots, I'd recommend clearing the cache of the web browser you use to log in to the router.

7) Once the router reboots, log in and check if the "IPv6 DNS Server" option is now available on YazDHCP and that it works as expected.

If you later want to go back to the "original" ASP file, simply copy the file over the TEST version and reboot again.

HTH.

Awesome work! It definitely worked man!

I knew you'd figure it out after having dinner!

 

[Martinski]

Slight problem - the save location I have specified on my USB flash drive keeps being changed back to the default location in jffs/configs. It seems to happen when I have changed some settings on my router.

I have noticed that if I update or force update YazDHCP it goes back to the default /jffs/configs save location and I have to re-point it to my preferred location on my external SSD every time.

Those seem to be very "odd" scenarios and without further context & more precise details (e.g. some step-by-step instructions), there's very little I can do since I cannot reproduce the problem (though, admittedly, I tried only a couple of times each).

The custom backup directory path that you set up with the CLI menu is meant to be a "sticky" option. However, when YazDHCP is starting up & initializing, if that custom directory is *not* found at all, the code tries the following locations until it finds one that exists & is readily available:

/opt/var/
/jffs/config/

This means that if your custom backup location is reverting to one of the above alternative paths, the code could not find your intended target. Perhaps something is causing your USB-attached disk to momentarily "disconnect" so the path cannot be found at the moment that YazDHCP is running, but it's all speculation at this point.

I have now added some code to track the location and output log messages whenever the custom backup directory is *not* found, so if/when the situation happens again, check the syslog.log file and look for messages such as:

YazDHCP: **ERROR**: Backup directory [...] NOT FOUND.

Here are the instructions so you can test with the modified shell script:

1) Download the script file from PasteBin:

curl -kLSs --retry 3 --retry-delay 5 --retry-connrefused pastebin.com/raw/dGF2pEaJ | tr -d '\r' > /jffs/scripts/YazDHCP.sh.MOD.TEST.txt
chmod 755 /jffs/scripts/YazDHCP.sh.MOD.TEST.txt

2) Make sure your YazDHCP add-on is already on the latest develop branch 1.0.6 version.

3) Save the "original" shell script file by renaming it.

mv -f /jffs/scripts/YazDHCP  /jffs/scripts/YazDHCP.sh.SAVE.txt

4) Replace the "original" script with the new TEST version:

cp -fp /jffs/scripts/YazDHCP.sh.MOD.TEST.txt  /jffs/scripts/YazDHCP

5) Run YazDHCP to test your particular scenario and recreate the problem.

Once you reproduce the problem, check your syslog.log file and look for the "YazDHCP: **ERROR**" messages, and note the exact circumstances under which the problem occurs. As usual, "the devil is in the details..."