MerlinAU MerlinAU v1.2.6 - The Ultimate Firmware Auto-Updater (**Thread closed due to age**)

[visortgw]

Hey @visortgw

Happy to continue to work on this on my spare time
Considering I've always wanted an add-on that did all this for me, I'm happy to contribute to the community and give this addon some love when I can.



We actually did do this in release 1.1.3 as noted below here:



The only thing is we changed the "defaults" post install.
So basically new installs will see the change, but existing installs would keep whichever schedule they had already set. (Unchanged)

Thanks, you are 100% correct! I missed that change...

 

[ExtremeFiretop]

Thanks, you are 100% correct! I missed that change...

No worries, I considered including a schedule migration for people that still had the default schedule on a node, but I didn't want to change the scheduling behavior from under people that may not be reading the forums, I figured I'd just communicate the change, and people could adjust their schedules if they so decided.

 

[maghuro]

Thank you for another great update keep the good work!
Can you please clarify how the new option really works? I can't fully understand what allowed and blocked do ...

Thanks!

Edit: the new option (6) doesn't show to me... Neither on main router and node.

 

[maghuro]

Thank you for another great update keep the good work!
Can you please clarify how the new option really works? I can't fully understand what allowed and blocked do ...

Thanks!

Thank you for another great update keep the good work!
Can you please clarify how the new option really works? I can't fully understand what allowed and blocked do ...

Thanks!

Edit: the new option (6) doesn't show to me... Neither on main router and node.View attachment 59088View attachment 59089

Edit 2:
There's a screenshot from when that menu option is loading.

 

[ExtremeFiretop]

Thank you for another great update keep the good work!
Can you please clarify how the new option really works? I can't fully understand what allowed and blocked do ...

Thanks!

The changelog check feature use to scan the changelog for high risk phrases at the moment it tried to update, not when an update was detected, and blocked the update as a cron and forced you to run interactively.
Now instead you'll get a notification right away that high risk phrases are found as soon as an update is detected. And this new menu option allows you to either approve, or block, that changelog check which runs as a cron job.

Edit: the new option (6) doesn't show to me... Neither on main router and node.View attachment 59088View attachment 59089

It will only show when an update is detected with high risk phrases.
Considering there's no new updates, it won't be shown. and even if there is a new update, it will only be shown if you have the changelog check enabled and high risk phrases are found in the changelogs.

Edit; it's a pre-approval for the changelog check for the cron job.

 

[ExtremeFiretop]

Edit 2:
There's a screenshot from when that menu option is loading.
View attachment 59091

Yep as designed

 

[maghuro]

Yep as designed

Oh ok, now I fully understand. My thoughts were that the new menu option would always appear and we must choose if we wanted to always block or approve and change it manually whenever an update with high risk phrases was found.

I thought that TBD value was a typo

Now it's clear as water. Thanks once again and I'm sorry for my flash dumbness

 

[ExtremeFiretop]

Oh ok, now I fully understand. My thoughts were that the new menu option would always appear and we must choose if we wanted to always block or approve and change it manually whenever an update with high risk phrases was found.

I thought that TBD value was a typo

Now it's clear as water. Thanks once again and I'm sorry for my flash dumbness

Not dumb, I didn't mention in the update changelog how the approval process worked. I just said it was now included.
But no TBD is short for "To be Determined" basically if that value is TBD then it won't show is what you see in that screenshot.

Basically, this now allows the script to run as a cron job, even if there are high risk phrases found. All it will do is email you as soon as the update is detected to advise, you'll load MerlinAU, it will give a quick splash screen about needing to approve the update and give you this new menu option.
By default it will always be blocked when it shows up. (This is the point of the changelog check of course).

If you keep it blocked, it won't run as a cron job and if you run it interactively, it will prompt for approval at the time. (i.e same behavior , like it used too. )
But for example, if you have a delay of a week. On day 1 it will email you that it found high risk phrases and needs approval, at anytime in that week you can go to MerlinAU, toggle the approval switch, and let it run as a cron job at the end of the week.

Since the changelog check is now pre-approved and "disabled" in essence but only for this one update.

 

[ExtremeFiretop]

Oh ok, now I fully understand. My thoughts were that the new menu option would always appear and we must choose if we wanted to always block or approve and change it manually whenever an update with high risk phrases was found.

I thought that TBD value was a typo

Now it's clear as water. Thanks once again and I'm sorry for my flash dumbness

I'll add a new Wiki entry for this new feature shortly.

 

[ExtremeFiretop]

MerlinAU Version 1.2.0 released.

What's Changed/Fixed?:

PR: #226 - Changes to support new "3006.102.X" F/W versions (Thanks @Martinski4GitHub)!

Some initial changes to support upcoming "3006.102.X" F/W versions.

-Modified code to use the corresponding NVRAM variable: "led_disable" (old F/W) or "AllLED" (new F/W).
-Modified code to get the corresponding 3006 filename & URL for the 3006 F/W Changelog.
-Modified code to always get the long F/W version string instead of the short F/W version, so that we make correct numerical comparisons between "3004.388.X.Y" & "3006.102.X.Y" versions.
-Code improvements to minimize some calls to NVRAM.
-Fixed bug when "F/W Changelog Check Approval" did not always change the setting to "BLOCK" in scenarios where the user would run MerlinAU before it's nightly check.

This was a Martinski special MerlinAU is now focusing on gearing up for the 3006 F/W releases.

Significant screenshots:

GUI and feature-set remains the same, only behind the scene bug fixes and improvements.

 

[ExtremeFiretop]

MerlinAU Version 1.2.1 released.

What's Changed/Fixed?:

More changes to support upcoming "3006.102.X" F/W versions.

PR: #230 - Changes to support "3006.102.X" ROG Patch
-As per RMerlin here: https://www.snbforums.com/threads/a...derway-for-3-wifi-7-routers.90126/post-909548
ROG UI will no longer be supported in version 3006. Due to this, I have made some logical changes to the update flow for ROG options.

PR: #231 - Some code improvements. (Thanks @Martinski4GitHub)!

PR: #232 - Bug fix for MerlinAU script update function (Thanks @Martinski4GitHub)!

Significant screenshots:
GUI and feature-set remains the same, only behind the scene bug fixes and improvements.

 

[sfx2000]

this is a good reason why auto-update is not a good thing...

HP bricks ProBook laptops with bad BIOS delivered via automatic updates — many users face black screen after Windows pushes new firmware

HP / Microsoft seems to have removed the bugged BIOS download now.

www.tomshardware.com

 

[Viktor Jaep]

this is a good reason why auto-update is not a good thing...

HP bricks ProBook laptops with bad BIOS delivered via automatic updates — many users face black screen after Windows pushes new firmware

HP / Microsoft seems to have removed the bugged BIOS download now.

www.tomshardware.com

I would rather leave auto-updates in the capable hands of @ExtremeFiretop and @Martinski than the clowns running HP. These guys have done nothing but bent over backwards building protections upon safeties upon grepping release notes upon sending email notices/warnings, to ensure that the user is fully aware of the update that's about to get loaded... which is being loaded through the same exact methodology as hitting that "upload" button on the firmware update page... many times DAYS after the release has already hit, so you can stop any potential "bad" firmware update before it gets loaded. How often has that happened. Right?

 

[sfx2000]

I would rather leave auto-updates in the capable hands of @ExtremeFiretop and @Martinski than the clowns running HP.

Yeah, but this actually made it through the folks that run Windows Update - so MSFT has a bit to blame here.

I've always been good with auto-update notifications and let the user decide to do the upgrade or not - give them a couple of days - much like Android or iOS updates - I usually wait a couple of days before pulling the trigger...

 

[Viktor Jaep]

Yeah, but this actually made it through the folks that run Windows Update - so MSFT has a bit to blame here.

With the thousands of vendors that are constantly pushing driver updates through Windows Update every week, I sincerely doubt Microsoft has any say or manpower to even go through proper testing of all that software/firmware matched to very specific hardware. I bet they are counting on the actual hardware/software vendors to have done their due diligence in ensuring firmware was tested on their own hardware. Microsoft is just the delivery vehicle to get it disseminated.

I've always been good with auto-update notifications and let the user decide to do the upgrade or not - give them a couple of days - much like Android or iOS updates - I usually wait a couple of days before pulling the trigger...

I'm glad you practice safe auto-updating... MerlinAU definitely seems to practice this same methodology. Although, I usually get a bit antsy as I'm always a day-1-release-lock-and-load-and-let-it-fly kind of guy when it comes to Asus firmware.

 

[ExtremeFiretop]

I would rather leave auto-updates in the capable hands of @ExtremeFiretop and @Martinski than the clowns running HP. These guys have done nothing but bent over backwards building protections upon safeties upon grepping release notes upon sending email notices/warnings, to ensure that the user is fully aware of the update that's about to get loaded... which is being loaded through the same exact methodology as hitting that "upload" button on the firmware update page... many times DAYS after the release has already hit, so you can stop any potential "bad" firmware update before it gets loaded. How often has that happened. Right?

Thank you Viktor

Yes exactly what I was doing to say, we built more safeties than I can count off the top of my head into this script, we realize auto-update isn't for everyone's use-case and environment, but this is why we made it an addon and it's optional.
On the other hand, many people do expect their internet connected devices (including their routers) to Auto-update, which is the main goal of this project. (Along with providing a tool to help manage some remote devices)

At the end of the day, the risk involved is the same (probably less actually for many users) than doing it manually yourself. Since we go above and beyond what a standard user may do with SHA256 checks, etc.

Worst comes to worst, Backups is always recommended, which is integrated into MerlinAU to save the day with the help of @Viktor Jaep and Backupmon
Speaking of development work, I just picked up an RT-AX92U and flashed Gnuton on it... So more movement coming on the Gnuton branch soon to add support.

 

[sfx2000]

With the thousands of vendors that are constantly pushing driver updates through Windows Update every week, I sincerely doubt Microsoft has any say or manpower to even go through proper testing of all that software/firmware matched to very specific hardware. I bet they are counting on the actual hardware/software vendors to have done their due diligence in ensuring firmware was tested on their own hardware. Microsoft is just the delivery vehicle to get it disseminated.

Something tells me you've never been thru WHQL certs - this applies to drivers and firmware updates that are made through Windows update.

You're missing my point though - I'm totally ok with notification and even 1-click updates by the end-user...

auto-bricking devices is never a good thing...

There was a recent event where a class of carrier devices where bricked...

and even Apple has had issues with auto-bricking due to pushed updates.

 

[nlurker]

I was skeptical of auto-updates at first, but the high quality of this script won me over. It has so many protections built in, it is probably safer than doing it all manually like I've always done. And it is certainly a lot more convenient, especially letting it update during off-hours so I don't have to interrupt the network when in use. "Day-1-lock-and-load" is definitely not safe, use the postponement period to let others risk getting bricked instead of you.

 

[ExtremeFiretop]

auto-bricking devices is never a good thing...

There was a recent event where a class of carrier devices where bricked...

and even Apple has had issues with auto-bricking due to pushed updates.

I'm confused. Is your concern with bricking a device?
Or auto-bricking a device?

Because as mentioned already nothing about MerlinAU posts risks to bricking a device. Since it uses the same method as a user through the WebUI, the same risks apply as if you were doing it manually (through the WebUI)
With that said. The only "bricking" that can happen is by an issue in the firmware itself, which I trust Rmerlin with my hardware completely. So at the end of the day, no matter if it's Auto-Update or manual updated, your expositing yourself to the same risks of "bricking" any device with Merlin Firmware.

 

[ExtremeFiretop]

this is a good reason why auto-update is not a good thing...

HP bricks ProBook laptops with bad BIOS delivered via automatic updates — many users face black screen after Windows pushes new firmware

HP / Microsoft seems to have removed the bugged BIOS download now.

www.tomshardware.com

This is comparing apples to oranges because here (in this thread) we are talking about the risks of update method. Not the updates the themselves.
Windows update didn't brick those devices, the updates did.

No one blames Windows update for those bricked devices, they blame the updates pushed down through Windows update, no one asked for Windows update to be redesigned due to the bricks, they ask for the drivers and updates to be fixed and pushed down again.
In this example, MerlinAU is Windows update, that would be a proper comparison. The risks involved of the updates being pushed down is a different debate.