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

[SomeWhereOverTheRainBow]

Happy to be able to help in the small ways I am capable of, looking forward to a new Develop version!

You are always providing the necessary feedback. I know it keeps @Viktor Jaep on his developing toes, and the cat out of the bag.

 

[TheLyppardMan]

The real question in my mind is, does every one keep their specified storage devices awake, connected, and available during their expected hours of operational use. I am noticing words like "intermittent" being used. This tells me the issue might not only happen after the router reboots, but also might relate to storage devices that are not always kept awaken or connected for active use.

In my case, the flash drive is also being used to store traffic data, so I guess that means it should always be awake?

 

[SomeWhereOverTheRainBow]

In my case, the flash drive is also being used to store traffic data, so I guess that means it should always be awake?

No worries, as soon as @Martinski roles out with this new solution you should be fine.

 

[Martinski]

Happy to be able to help in the small ways I am capable of, looking forward to a new Develop version!

I've just rebooted my router, but the problem hasn't occurred. I've attached the syslog in case there is any useful information in there.

OK, I have finished implementing & testing the fix. Note that you will still see the "YazDHCP: **ERROR**: Backup directory [...] NOT FOUND" messages in the syslog during reboot when the USB drive is not yet available, and the alternate path will be set *temporarily* since the code needs to initialize the path to a "good" value. However, after the reboot process has been completed and the USB drive is in fact fully mounted & available, any time you run YazDHCP the code will re-initialize with your expected custom directory path.

Here are the instructions to get the latest TEST script version so you can verify the fix with your own router setup, especially the reboot scenarios.

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

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

2) Remove the previous/older TEST script file:

rm -f /jffs/scripts/YazDHCP.sh.MOD.TEST.txt

3) Download the latest TEST 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

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

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

5) Replace the "original" script with the latest TEST script version:

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

6) Run the following command to double-check that you have in fact the latest TEST version:

grep -E "# Last Modified:|readonly SCRIPT_VERSION=" /jffs/scripts/YazDHCP

The output should look as follows:

# Last Modified: 2023-Jun-16
readonly SCRIPT_VERSION="v1.0.6_Beta_20230616_#2"

If it's different, you don't have the latest TEST script version. Start again from step 2 above.

7) Make sure to use the CLI menu to set the backup directory to your custom directory path. This step is to ensure that the expected backup path has been set properly *before* testing/verification can begin.

8) Run YazDHCP as usual to test your specific setup.

 

[Stephen Harrington]

8) Run YazDHCP as usual to test your specific setup.

@Martinski

Ran the new test version v1.0.6_Beta_20230616_#2 and it triggered the error on the 1st go, I must be getting better at it!

My user-selected directory on the errant USB drive, namely "/mnt/AMTM-USB/backups/yazdhcp/SavedUserIcons" was still there when I went in to have a look, both via CLI and web interface, so I think this is behaving now how you intended?

Log link below, line 686 is the relevant area.

messages.log.zip

 

[Martinski]

Ran the new test version v1.0.6_Beta_20230616_#2 and it triggered the error on the 1st go, I must be getting better at it!

My user-selected directory on the errant USB drive, namely "/mnt/AMTM-USB/backups/yazdhcp/SavedUserIcons" was still there when I went in to have a look, both via CLI and web interface, so I think this is behaving now how you intended?

Thank you for providing feedback. And yes, your log file shows the intended behavior of the new code during reboot, and the "resetting" of the backup directory path when you run YazDHCP after the reboot has completed. I appreciate your taking the time to help with reproducing the problem, capturing the logs, and then testing the fix.

I'll be submitting a GitHub PR to @Jack Yaz's 'develop' branch sometime tomorrow.

 

[TheLyppardMan]

It seems to be OK now.

 

[Martinski]

It seems to be OK now.

Thanks a lot for testing & verifying the fix.

Credit goes to you & @Stephen Harrington for help in narrowing down the specific scenario that reproduced the problem, for providing debug logs, and finally for testing the fix. I must say that I fully appreciate the spirit of collaboration that both of you, along with @SomeWhereOverTheRainBow, have demonstrated recently.

I know I’ve said it before, but I’ll say it again:
"There's nothing like a 2nd (and 3rd or more :>) pair of eyes when it comes to testing & verification."

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!

 

[Nas.CloudBusinessPortal]

Just wanted to say thanks @Jack Yaz

 

[ICDeadPpl]

I just want to say that this addon is great!
I wish there were a similar export/import for "WAN - Virtual Server / Port Forwarding" too.

 

[Robert Tickle]

I just want to say that this addon is great!
I wish there were a similar export/import for "WAN - Virtual Server / Port Forwarding" too.

I would like to second this motion. I just recently discovered YazDHCP and I love it. Thank you @Jack Yaz.
Having an addon that exports/imports the Virtual Server / Port Forwarding entries would make my ASUSwrt-Merlin life complete.

 

[JGrana]

Not a Web based Addon, but this new script shows promise. You can add the nvram variables that relate to VS/Port Forwarding and this script will create a backup.

Script to Back Up & Restore Subsets of NVRAM Variable Settings.

I moved this thread's topic from this post as it was off-topic on that particular thread. UPDATE [2024-Apr-10]: The script was moved to GitHub. The latest "0.7.12" version update is now available. =========================================================== I see, there's however no such...

www.snbforums.com

 

[Martinski]

I wish there were a similar export/import for "WAN - Virtual Server / Port Forwarding" too.

Having an addon that exports/imports the Virtual Server / Port Forwarding entries would make my ASUSwrt-Merlin life complete.

If you want to try the "SaveRestoreNVRAMvars.sh" shell script, attached is the input file (NVRAM_VarList.txt) modified to back up the "WAN - Virtual Server / Port Forwarding" settings. I've never used port forwarding on ASUS routers but, AFAIK, there are only 2 NVRAM vars for "WAN - Virtual Server / Port Forwarding" so I doubt a full add-on would be needed specifically just for that (IMO).

 

[HoopsRsa]

I am having a strange issue with my GT-AX6000 on the 3008.344.4 firmware. It runs perfectly for a day or two and then suddenly all devices cannot access the internet. The router looks normal and WAN is up and showing the ISP IP address normally. PC's show the internet connection as normal and do not show the "world" that normally shows when the internet goes down.

I posted the issue in the merlin firmware update thread and the repy I received that it was possibly a YazDHCP issue.

A reboot resolves the issue. I have attached a extract of the log in the time frame where the error happens (see attached) - can someone please have a look and see if they can see the issue.

 

[bennor]

I am having a strange issue with my GT-AX6000 on the 3008.344.4 firmware. It runs perfectly for a day or two and then suddenly all devices cannot access the internet. The router looks normal and WAN is up and showing the ISP IP address normally. PC's show the internet connection as normal and do not show the "world" that normally shows when the internet goes down.

I posted the issue in the merlin firmware update thread and the repy I received that it was possibly a YazDHCP issue.

A reboot resolves the issue. I have attached a extract of the log in the time frame where the error happens (see attached) - can someone please have a look and see if they can see the issue.

If you haven't done so already, see Jeffrey Young's reply, in the other thread, about checking the hosts file for errors:
https://www.snbforums.com/threads/asuswrt-merlin-3004-388-4-is-now-available.86428/post-863486

As @MDM has pointed out, dnsmasq is crashing after the list of hosts is loaded. Check your hosts file you created in dnsmasq. Check for any duplicate MAC address or incorrectly formatted MAC address. I've had this happen to me. It was a MAC address on a dhcp-host line that I mistyped.

 

[HoopsRsa]

If you haven't done so already, see Jeffrey Young's reply, in the other thread, about checking the hosts file for errors:
https://www.snbforums.com/threads/asuswrt-merlin-3004-388-4-is-now-available.86428/post-863486

Thank you, will have a look at the hosts file.

 

[privacyguy123]

Very new to this ASUS Router script stuff ...

Seeing this error on systemlog every reboot - right enought the files aren't there. Did I need to manually assign DHCP AFTER Installing YazDHCP? I had entries in there before.

Sep 29 21:32:25 dnsmasq[25555]: failed to load names from /jffs/addons/YazDHCP.d/.hostnames: No such file or directory
Sep 29 21:32:25 dnsmasq[25555]: cannot read /jffs/addons/YazDHCP.d/.staticlist: No such file or directory
Sep 29 21:32:25 dnsmasq[25555]: cannot read /jffs/addons/YazDHCP.d/.optionslist: No such file or directory
Sep 29 21:32:37 dnsmasq[25792]: cannot read /jffs/addons/YazDHCP.d/.optionslist: No such file or directory

 

[JGrana]

During YazDHCP install it should have seen any reservations you had in either nvram or /jffs and exported them to the files being complained about.

If you run:

$ /jffs/scripts/YazDHCP

do you see a menu item asking to export? (I think it’s “x”). If so, select it.

If not, then you either had no reservations or it thinks it already did it.

 

[privacyguy123]

During YazDHCP install it should have seen any reservations you had in either nvram or /jffs and exported them to the files being complained about.

If you run:

$ /jffs/scripts/YazDHCP

do you see a menu item asking to export? (I think it’s “x”). If so, select it.

If not, then you either had no reservations or it thinks it already did it.

Nope - but I followed some instructions to update to "develop" and that seems to have fixed the erros in the logs anyway

 

[bennor]

During YazDHCP install it should have seen any reservations you had in either nvram or /jffs and exported them to the files being complained about.
<snip>

Yes. Usually when one first installs YazDHCP it should ask to export existing DHCP assignments and host names from NVRAM. But once installed this is what the CLI non developer version of YazDHCP interface looks like. So it only shows the export option when it thinks it hasn't done it.

However, if one does select "x" they will (or should) get the prompt asking to export: