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

[TheLyppardMan]

Hmm - I'm not entirely sure what you are asking me to do here. Do I have to copy and paste the lines of code one at a time into Xshell in the order above and if so, does that include the entire line, such as this: mv -f /jffs/scripts/YazDHCP /jffs/scripts/YazDHCP.sh.SAVE.txt? Just wondering what mv stands for, for instance (move? - just guessing)

 

[TheLyppardMan]

One other thought - I wonder if the disc-checker script could be responsible for delaying the availability of my flash drive and therefore resulting in YazDHCP being unable to find the intended target?

 

[bennor]

Hmm - I'm not entirely sure what you are asking me to do here. Do I have to copy and paste the lines of code one at a time into Xshell in the order above and if so, does that include the entire line, such as this: mv -f /jffs/scripts/YazDHCP /jffs/scripts/YazDHCP.sh.SAVE.txt? Just wondering what mv stands for, for instance (move? - just guessing)

You would run the commands in steps 1, 2, 3 and 4 using the SSH command line. The "mv" command stands for "move". That line of code is moving the file and renaming it. The "cp" command is "copying" the file.

 

[TheLyppardMan]

You would run the commands in steps 1, 2, 3 and 4 using the SSH command line. The "mv" command stands for "move". That line of code is moving the file and renaming it. The "cp" command is "copying" the file.

Yes, that's what I thought, but I wanted to make sure before doing anything.

 

[TheLyppardMan]

I've pasted in the commands one by one. How will I know if it's done anything? BTW, I'm running the develop version of YazDHCP.
I'll reboot my router in the morning and see what happens.

 

[bennor]

I've pasted in the commands one by one. How will I know if it's done anything?

See step 5 in Martinski's post above:

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..."

 

[Stephen Harrington]

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).

@Martinski - I'm unable to reproduce the error at will so it seems to be intermittent, but after doing some more focused playing this morning it is definitely related to rebooting, NOT forcing an update as I stated earlier in the thread. I did get the "error" to occur once, but not unfortunately whilst I had your "test" version installed so didn't capture any log messages. I ran out of time to have the house internet being "fiddled with".

I think @TheLyppardMan may be on to something with regard to:-

I wonder if the disc-checker script could be responsible for delaying the availability of my flash drive and therefore resulting in YazDHCP being unable to find the intended target?

I think if you incorporated a short 10-15 second delay in your startup this may well solve it?
Or if you wanted to get cleverer it possibly needs a loop function to wait for the USB drives to become available if the user-specified location is within "/mnt"?

 

[SomeWhereOverTheRainBow]

@Martinski - I'm unable to reproduce the error at will so it seems to be intermittent, but after doing some more focused playing this morning it is definitely related to rebooting, NOT forcing an update as I stated earlier in the thread. I did get the "error" to occur once, but not unfortunately whilst I had your "test" version installed so didn't capture any log messages. I ran out of time to have the house internet being "fiddled with".

I think @TheLyppardMan may be on to something with regard to:-



I think if you incorporated a short 10-15 second delay in your startup this may well solve it?
Or if you wanted to get cleverer it possibly needs a loop function to wait for the USB drives to become available if the user-specified location is within "/mnt"?

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.

 

[Martinski]

Awesome work! It definitely worked man!
...
I knew you'd figure it out after having dinner!

Yeah well, that’s just how I roll...

But, seriously, I’m glad the code port worked out well in the end, and it was actually needed to keep YazDHCP moving forward & running with the more recent F/W versions. Thank you for finding the problem & reporting it here.

I’ve just submitted a GitHub PR for @Jack Yaz to merge into his 'develop' branch.

 

[Stephen Harrington]

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.

You could be right, but in my case it's a "standard as recommended by the experts here" SSD-in-a-USB 3.0 Case drive which is only for AMTM/Entware/Swap File usage, so it doesn't go to sleep that I'm aware of, as at least some of my add-ons in use (as per my sig) write to disk pretty regularly. Can't speak for other people's setups of course.

 

[Martinski]

One other thought - I wonder if the disc-checker script could be responsible for delaying the availability of my flash drive and therefore resulting in YazDHCP being unable to find the intended target?

I'm unable to reproduce the error at will so it seems to be intermittent, but after doing some more focused playing this morning it is definitely related to rebooting, NOT forcing an update as I stated earlier in the thread. I did get the "error" to occur once, but not unfortunately whilst I had your "test" version installed so didn't capture any log messages. I ran out of time to have the house internet being "fiddled with".

...
I think if you incorporated a short 10-15 second delay in your startup this may well solve it?
Or if you wanted to get cleverer it possibly needs a loop function to wait for the USB drives to become available if the user-specified location is within "/mnt"?

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.

Yeah, all good points. Anything that would make unavailable or delay the availability of the USB drive where the backup directory is located could result in the reported problem where the code ends up selecting an alternative path for backups, especially during the bootup process.

As a general rule, I wouldn't want to make arbitrary "sleep" calls or put "while" loops because it's really impossible to know for sure how long to wait for the USB drive to be available, especially not knowing why it's unavailable (what about when the disk is unmounted for some reason?). And a long delay/loop would just make starting up the add-on seem like is "stuck" and could be annoying during those times when you don't actually want to use the "Back Up & Restore" feature after having it set up previously.

Anyway, I believe I have a solution/workaround that should work under different conditions, but of course, it assumes that the USB drive will eventually become available *before* YazDHCP is run by the user on-demand. I should have something by tomorrow evening.

 

[Stephen Harrington]

Anyway, I believe I have a solution/workaround that should work under different conditions

Makes sense what you say about sleep calls and "while" loops" ... I wasn't really thinking that one through.

FWIW I've now done another 7-8 reboots and have triggered the error a couple more times, so in my case at least it definitely seems related to the USB drive sometimes not being available in time, possibly due to disk checking or whatever?

Shall await your next release and re-test ...

 

[Martinski]

FWIW I've now done another 7-8 reboots and have triggered the error a couple more times, so in my case at least it definitely seems related to the USB drive sometimes not being available in time, possibly due to disk checking or whatever?

Was the YazDHCP TEST version installed when the errors during reboot were triggered?
If so, can you send me the part of the syslog.log file where you see the YazDHCP log messages?
Look for error messages such as this:

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

I'd like to see the context surrounding those error messages.

Thanks.

 

[Stephen Harrington]

I'd like to see the context surrounding those error messages.

@Martinski - yes I finally captured one!

Link to a zipped messages.log on my OneDrive, YazDHCP errors are around line 681 ... for context as well as having my USB 3.0 AMTM/Entware/Swap SSD plugged in, I also have a Huawei USB 4G LTE USB stick plugged in I use for failover WAN ...

Link To Log

 

[SomeWhereOverTheRainBow]

@Martinski - yes I finally captured one!

Link to a zipped messages.log on my OneDrive, YazDHCP errors are around line 681 ... for context as well as having my USB 3.0 AMTM/Entware/Swap SSD plugged in, I also have a Huawei USB 4G LTE USB stick plugged in I use for failover WAN ...

Link To Log

That is interesting. From my understanding, the most accurate place to ensure we catch the usb mount on time is for a trigger or call from post-mount. @Martinski does yazdhcp rely on any mechanisms as such?

 

[Stephen Harrington]

That is interesting.

@SomeWhereOverTheRainBow

Yes, and it doesn't error out on every boot, maybe 1 in 3-4 from what I can tell so far. So feels like a timing issue.
I mentioned the 4G LTE stick in my other port as maybe being something a bit atypical in terms of USB bus initialisation/timings, but maybe that is just a red herring ...

 

[Martinski]

@Martinski - yes I finally captured one!

Link to a zipped messages.log on my OneDrive, YazDHCP errors are around line 681 ... for context as well as having my USB 3.0 AMTM/Entware/Swap SSD plugged in, I also have a Huawei USB 4G LTE USB stick plugged in I use for failover WAN ...

Thank you for providing the log file!!
It clearly shows the sequence of events that leads to the problem and confirms my suspicions of the likely root cause.
For example:

...
Jun 16 10:00:10 custom_script: Running /jffs/scripts/services-start
...
Jun 16 10:00:11 YazDHCP: **ERROR**: Backup directory [/mnt/AMTM-USB/entware/share/yazdhcp.d/SavedUserIcons] NOT FOUND.
...
Jun 16 10:01:37 custom_script: Running /jffs/scripts/post-mount (args: /tmp/mnt/AMTM-USB)
...

The call to start YazDHCP is made from "services-start" *before* "post-mount" so the USB drive is not yet fully mounted, thus the backup directory is not found during startup and so the alternative path becomes the new backup location.

My solution will circumvent all this by re-initializing the backup directory path variable when YazDHCP is executed every time the user calls for it, either via the CLI menu or the webGUI page. This way, it doesn't matter when the USB drive becomes available during the boot process; it only matters if it's indeed available when there's a call for it by the user executing the script.

That is interesting. From my understanding, the most accurate place to ensure we catch the usb mount on time is for a trigger or call from post-mount. @Martinski does yazdhcp rely on any mechanisms as such?

No need for it. See above.

 

[Stephen Harrington]

Thank you for providing the log file!!
It clearly shows the sequence of events that leads to the problem and confirms my suspicions of the likely root cause.

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

 

[TheLyppardMan]

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.

 

[SomeWhereOverTheRainBow]

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.

No worries, as soon as @Martinski roles out with this new solution you will see the issue melt away. See his last reply above.