MerlinAU MerlinAU v1.4.6 - The Ultimate Firmware Auto-Updater (WEBUI + GNUTON SUPPORT!)

[kriukas]

Pending review and approval from @Martinski

P.S. If anyone might guide me, how to disable the actual flash code of the script permanently, without affecting all the cycle (including reboots), I would be glad to test script under "real" conditions. Dunno, if script tries to flash again if previous cycle didn't up the version - this must also be accounted for.

 

[ExtremeFiretop]

Dunno, if script tries to flash again if previous cycle didn't up the version - this must also be accounted for.

Yes it will continue to try if it didn't work the first time. For example if the first night your Backupmon backup didn't complete successfully and the script cancels, but you fixed it through the day, the next night it would try again.

 

[kriukas]

Yes it will continue to try if it didn't work the first time. For example if the first night your Backupmon backup didn't complete successfully, but you fixed it through the day, the next night it would try again.

I had the experience with this one. But I might have not explained what I was intended to. I mean not "daily" or etc. cron-based re-cycle. I mean, when the script goes to the stage of the flash, which end-user cannot cancel in a normai UI-way, does the script execute one time, or does it try to cycle "within" until success? Preaty dumb question on its own - but better to ask, than sorry.

 

[ExtremeFiretop]

I had the experience with this one. But I might have not explained what I was intended to. I mean not "daily" or etc. cron-based re-cycle. I mean, when the script goes to the stage of the flash, which end-user cannot cancel in a normai UI-way, does the script execute one time, or does it try to cycle "within" until success? Preaty dumb question on its own - but better to ask, than sorry.

It runs once per cron job call. If that's once a day it will try once a day. If you configured the cron job to run once an hour it will try once an hour. If you configured it for once a month it will try once a month. The ability to schedule the flash attempts are in the users control.
It does not try to "reflash" within the same run... If it got cancelled. It got cancelled.

 

[ExtremeFiretop]

View attachment 65908

The screenshot of the CLI clearly shows it's asking to proceed even though it's scheduled to postpone for 5 days, which is unrelated to the blocked changelog approval.
If you accept to proceed and not delay, then it will do the changelog verification at a later step and check if it's blocked or approved.

Same flow with the WebUI. If you select to bypass the postone and flash now, it will try, and fail, the changelog has not been approved.
You would need to approve the changelog, and bypass the postpone period for it to flash from the WebUI.

 

[kriukas]

The screenshot of the CLI clearly shows it's asking to proceed even though it's scheduled to postpone for 5 days, which is unrelated to the blocked changelog approval.
If you accept to proceed and not delay, then it will do the changelog verification at a later step and check if it's blocked or approved.

Same flow with the WebUI. If you select to bypass the postone and flash now, it will try, and fail, the changelog has not been approved.
You would need to approve the changelog, and bypass the postpone period for it to flash from the WebUI.

If I am not offending anyone, I would like to argue, to switch the place of these two workflow steps. My argument would be simple from system theory (the best way to fullfill user requirements with minimum steps) POV:

A. If there is a block pending, which is known before the goal we are seeking, and the user is guided towards the goal and expects to reach the goal immediatly, but is blocked after "promise", then:
B. all such blocks (which are in fact requirements to be filled by user), must be fullfilled before final step - submitting to the goal.

Counter-argument, to cross-check this maxima:

"if the designer would choose to make a promise to immediately to submit to the goal by "asking one-final-question", and then instead would "break" this promise by asking to fulfill 1+N requirements from user, each time resetting to the "asking one-final-question" again and again, thus he has had broken the promise already, and then - again and again.

Just my 2 cents...

 

[Martinski]

Hi @kriukas

Every single one of your 7 bug reports (listed below) have been resolved

1. Added missing changelog patch from previous PR to force 3006 changelogs in an upgrade from 3004 to 3006
2. Fix Web Access Restrictions by modifying the regex to accept subnets larger than /20
3. Fix Web Access Restriction 32-bit integer overflow with multiple large /5 ranges for example.

I'm just catching up on the recent posts, and I just cannot find any bug report that talks about a "Web Access Restriction 32-bit integer overflow" problem.

Would you please provide a link where the user reported this specific problem found in the current production release?

I'm just gathering context to understand what needed to be fixed.

Thanks.

 

[Martinski]

...
3. To my best understanding, despite *current dev level* script implementation as non-blocker, script itself is inconsistent at determining the truthnes/falseness of router's LAN IP belonging to the mathematical set IPs, and one can easy find corner cases, when scripts thinks (and passes!) as OK, but is wrong.
...

Would you please provide some real-life, valid examples of such "corner cases"?
I'm not asking about some hypothetical scenarios, but actual valid examples since "one can easy find corner cases, when scripts thinks (and passes!) as OK, but is wrong."

I just want to make sure we understand what you're referring to.

Thanks.