MerlinAU MerlinAU v1.1.2 - The Ultimate Firmware Auto-Updater (Now available in AMTM)

[maghuro]

Assuming a user has setup email credentials in AMTM, how about an email notification after an update?

And also before...

"Starting flashing firmware..."
If we don't receive the "update done" email after a couple of minutes, we know that something went (terrible) bad

 

[Tech9]

Perhaps @RMerlin opinion is needed here. This script updates his firmware. If the procedure is safe to use - all good.

 

[ExtremeFiretop]

@RMerlin is free to review and test at his leisure if he so chooses like anyone else here

Always open to feedback and opportunities to improve!

 

[KevTech]

Perhaps @RMerlin opinion is needed here. This script updates his firmware. If the procedure is safe to use - all good.

Pretty sure his opinion has not changed. If it was something he had wanted he would have implemented this himself.

Seeking Feedback & Contributions: Merlin Auto Update Solutions

I still don’t understand how a simple shell script would “know” there’s a problem with the firmware or wifi or vpn, and it’s now necessary to downgrade the firmware. Internet access checks are easy to implement by having a script download a file over the Internet. Detecting WiFi is also easy...

www.snbforums.com

 

[ExtremeFiretop]

Pretty sure his opinion has not changed. If it was something he had wanted he could have easily done this himself.

Seeking Feedback & Contributions: Merlin Auto Update Solutions

I still don’t understand how a simple shell script would “know” there’s a problem with the firmware or wifi or vpn, and it’s now necessary to downgrade the firmware. Internet access checks are easy to implement by having a script download a file over the Internet. Detecting WiFi is also easy...

www.snbforums.com

Agreed. It's something I and a friend wanted so we built it.

But my opinion has not changed either, if RMerlin has any ideas for improvement I'm all open to it!

If it's a question about it working, I'm not concerned. It works. If it's a question about how safe it is, the worst case that's happened to me in all my testing is the flash never started I think? Never even had to do a factory reset.

The flash is just a web request to the WebGUI to upload the firmware like any other.

If it was to fail, It's likely to fail before that web request or at that request and be denied.

But if the router accepts that request, then the rest is up to the router itself and the normal update process and the same risks would apply if you did it yourself from that point forwards.

In my eyes, this is as safe as is gets without reverse engineering the entire update process.

 

[RMerlin]

As long the upgrade process uses the regular web-based API and not direct calls to hnd-write/mtd-write, I'm ok with it. Still wouldn`t want to integrate that into the firmware, but I have no problem with it being available as a script.

I would strongly recommend limiting it to devices that use a dual partition system however. Single partition systems (like the RT-AC68U) still carry a small chance of crashing during its reboot as the update is applied to a live filesystem. Currently, all HND models supported by Asuswrt-Merlin use a dual partition system.

 

[ExtremeFiretop]

As long the upgrade process uses the regular web-based API and not direct calls to hnd-write/mtd-write, I'm ok with it. Still wouldn`t want to integrate that into the firmware, but I have no problem with it being available as a script.

I would strongly recommend limiting it to devices that use a dual partition system however. Single partition systems (like the RT-AC68U) still carry a small chance of crashing during its reboot as the update is applied to a live filesystem. Currently, all HND models supported by Asuswrt-Merlin use a dual partition system.

Thank you for your input. Exactly what it does.

And I just wanted to say as always your opinion is highly valued here.

Since the very first thread seeking feedback, your input has helped shape this project to the functional script it is today.

 

[ExtremeFiretop]

I would strongly recommend limiting it to devices that use a dual partition system however. Single partition systems (like the RT-AC68U) still carry a small chance of crashing during its reboot as the update is applied to a live filesystem. Currently, all HND models supported by Asuswrt-Merlin use a dual partition system.

In a situation where this happens, my best guess is it would still be just as likely to happen when doing the firmware flash yourself? since this would be a post reboot process to the file system?

So I guess the question becomes for people with those routers, if they want to assume that risk, or if it should be blocked just due to that risk existing at all.

Maybe a poll for Single partition device users or some comments from such users would be appreciated.

 

[RMerlin]

it would still be just as likely to happen when doing the firmware flash yourself?

That`s correct.

I've had it happen to me a few times in the past when I was doing remote development (flashing a new image while still at work). It's very rare because most of the necessary components are copied to a temp rootfs, but that rootfs design was implemented by Asus, so it might not contain everything used by Asuswrt-Merlin. When that happens, sometimes the router will still reboot itself with the kernel panic, but sometimes it gets stuck with a bunch of filesystem errors in the log, until you power cycle the router.

These are why sometimes the web page will instruct you to manually reboot the router. (and sometimes that page will show up if the router is just taking longer than expected to reboot).

So I guess the question becomes for people with those routers, if they want to assume that risk, or if it should be blocked just due to that risk existing at all.

The question is also whether you want to deal with any potential tech support request related to that. That`s why the decision should also be up to you, and not to a poll that will be biased by a user`s past experience.

 

[ExtremeFiretop]

That`s correct.

I've had it happen to me a few times in the past when I was doing remote development (flashing a new image while still at work). It's very rare because most of the necessary components are copied to a temp rootfs, but that rootfs design was implemented by Asus, so it might not contain everything used by Asuswrt-Merlin. When that happens, sometimes the router will still reboot itself with the kernel panic, but sometimes it gets stuck with a bunch of filesystem errors in the log, until you power cycle the router.

These are why sometimes the web page will instruct you to manually reboot the router. (and sometimes that page will show up if the router is just taking longer than expected to reboot).


The question is also whether you want to deal with any potential tech support request related to that. That`s why the decision should also be up to you, and not to a poll that will be biased by a user`s past experience.

I'll take this conversation offline with Martinski, and see if we want to deal with potential issues relating to this.

We do however value user opinions, so feel free to make your arguments if you own any of these routers:

• RT-AC88U (Untested)
• RT-AC5300 (Untested)
• RT-AC3100 (Untested)
• RT-AC68U (Untested)
• RT-AC66U_B1 (Untested)
• RT-AC1900 (Untested)

(As these are the devices we are discussing blocking)

 

[dave14305]

What are the chances of many more firmware updates being released for the older 386.* AC models? I would focus on the 388.* models, personally.

 

[robinjoo1]

sounds like a good idea
but i stick with downloading the update .zip manually extract that and upload the firmware via the user interface , sounds more foolproof by doing it all manually

 

[ExtremeFiretop]

What are the chances of many more firmware updates being released for the older 386.* AC models? I would focus on the 388.* models, personally.

My personal opinion as it stands now, is I'm more interested in developing than providing personal support for stuff unrelated to my script.

I also think, to protect the reputation of the script and give it the highest chance of success going forwards, it may be smartest to drop the support for the older 386.* AC models and reduce any potential for unintentional risks.

The goal has always been a safety first approach.

 

[ExtremeFiretop]

As documented in PR 82 as of Version 0.2.54 the following models will be blocked:

• RT-AC88U (Untested)
• RT-AC5300 (Untested)
• RT-AC3100 (Untested)
• RT-AC68U (Untested)
• RT-AC66U_B1 (Untested)
• RT-AC1900 (Untested)

Not only are these models now on the blocked list, but I have purposefully completely disabled support for .trx firmware files.
Version 0.2.54 also resolves the ROG discussion from page 1 and has been pushed out.

Thanks again for the valuable input and insight. We only focus on newer models going forwards.

 

[aex.perez]

Would this exclude you if you apply alpha/beta FW releases?
I'm guessing running alpha/beta code would still be a manual process.
I'm also assumimg this is applies released FW, and guessing that if I apply alpha/beta FW when the final is released it'll apply the released version automatically?

On the mesh nodes with Merlin and AMTM, guessing those can use the script as well (as if they were a router)?

I think the only thing I didn't see (so far) is setting a window of time when a released FW could be applied, or exclude a window of time so that it doesn't happen when it would cause unwanted interruptions, like in the middle of the wife's Telenovela

On second thought the seeing the Update Schedule and Postponement days options in the release notes, I could satisfy that workaround

 

[maghuro]

Let me ask you a doubt I have.

Currently, I have set the Cron job to run every Friday at 5:15am. It means that on this day, it'll check for an update.
Then, I have a postpone of 1 day. Does it mean that it'll flash the firmware on Saturday at 5:15 am?

 

[SomeWhereOverTheRainBow]

Hello SNB Community,

We're pleased to introduce an exciting new add-on for Asuswrt-Merlin: MerlinAU (Merlin AutoUpdate).
This tool is designed to streamline and automate firmware updates, making your router maintenance simpler and smoother than ever.

View attachment 55829


What's MerlinAU All About?

MerlinAU is a sophisticated and comprehensive script designed for Asus routers running Asuswrt-Merlin firmware.
It's a collaborative effort by @ExtremeFiretop (myself) and @Martinski W. It offers an extensive range of features:

1. Automatic Firmware Checks and Downloads: MerlinAU diligently checks for the latest ASUS firmware updates and downloads them automatically.
2. Customizable Settings and Logging: Tailor MerlinAU's behavior to your needs. Choose how and where to store firmware files, logs, and configure various other settings.
3. Self-Updating Script: Stay up-to-date effortlessly. MerlinAU can update itself directly from its GitHub repository.
4. User-Friendly Interactive Menu: An intuitive menu interface lets you easily configure settings, execute firmware updates, and more.
5. Compatibility and Support Checks: MerlinAU verifies the router model and firmware version for compatibility before any update.
6. Safety First Approach: With hash checksums and mechanisms to prevent concurrent script executions, and handle unexpected interruptions, your update process is safe and reliable.
7. Visual Feedback with LED Indicators: Get visual cues during specific operations thanks to LED manipulation.
8. Scheduled Update Checks: Set up cron jobs for automated firmware checks at your convenience.
9. Hassle-Free Firmware Flashing: Automated and safe firmware flashing with robust pre-checks.
10. Easy Uninstallation: Decide to remove MerlinAU? It comes with a clean uninstallation feature.

What update mechanism does MerlinAU use to Auto-Update?

Our script actually implements a curl update mechanism. Curl can simulate almost all behaviors of the browser through get/post.
While hnd-write is unsafe and unpredictable, we instead use curl to simulate a browser for the router to upload the firmware through it's own GUI, which is the safest way. As discussed on the forums in length here.

Essentially the router logins to it's own WebUI like a person does, and uploads the firmware through the WebUI.
Doing this insures that the firmware checks done by the router when uploading a firmware via the webUI are not skipped, and the router can follow it's regular update process from there.

This has been tested extensively on the following devices since 388.4:

• GT-AXE11000 (Tested)
• RT-AX88U_PRO (Tested)
• RT-AX88U (Tested)
• RT-AC86U (Tested)
• RT-AX86U (Tested)

All tests were successful on all subsequent firmware updates, the firmware upgraded correctly, and no issues with compatibility with other scripts were identified.


How to Get MerlinAU

MerlinAU is available for download on our GitHub repository here.

Installation and update information are provided on the same page.
PLEASE READ ALL THE DETAILS AND BACKUP BEFORE STARTING!


Post-Update Notes for MerlinAU Users

• After installing or updating MerlinAU, it's recommended to review the new settings and adjust them as per your preference.
• If using a USB drive for firmware storage, ensure it's properly connected and mounted.

We're eager to hear your feedback and experiences with MerlinAU. Your suggestions and comments are invaluable in making MerlinAU even better!
MerlinAU is available under the GNU General Public License version 3 (GPL-3.0).

Thank you, and enjoy a hassle-free firmware updating experience with MerlinAU!

I am wondering what failsafes are in place if the router crashes during a automated update? I saw @RMerlin mentioned the dual partition failsafe, but are there any other concerns that may need to be addressed before users consider using this script? We have @Viktor Jaep 's lovely backup script. Also, does this script check for, and update Aimesh nodes in the same firmware update process? If not, would there be away to integrate a Aimesh node updating process as well?

 

[ExtremeFiretop]

Would this exclude you if you apply alpha/beta FW releases?
I'm guessing running alpha/beta code would still be a manual process.
I'm also assumimg this is applies released FW, and guessing that if I apply alpha/beta FW when the final is released it'll apply the released version automatically?

Correct to a point, for example below:
We are currently on 388.6 as the production release. Therefore if I go to beta of 388.6 it will detect a newer release but not be satisfied enough with the version difference to actually try to update as seen below:

However, if I go all the way back to 388.5 beta 1. Then not only does it detect a different firmware available but it satisfies the difference in version required to update and therefore will allow it to update.

Basically this means that if your on a beta, your safe until the next major release. If somehow your still on beta1 388.5 by the time the major release of 388.6 comes around, then it will force update you to the next major release.

On the mesh nodes with Merlin and AMTM, guessing those can use the script as well (as if they were a router)?

Correct it doesn't need to be in router mode.

I think the only thing I didn't see (so far) is setting a window of time when a released FW could be applied, or exclude a window of time so that it doesn't happen when it would cause unwanted interruptions, like in the middle of the wife's Telenovela

On second thought the seeing the Update Schedule and Postponement days options in the release notes, I could satisfy that workaround

Happy you found it!

Let me ask you a doubt I have.

Currently, I have set the Cron job to run every Friday at 5:15am. It means that on this day, it'll check for an update.
Then, I have a postpone of 1 day. Does it mean that it'll flash the firmware on Saturday at 5:15 am?

As you'll notice from the screenshot above, it was a double test, 2 birds with 1 stone, I get to demo to you what happens when I configure it exactly like you did.
In the screenshot above on beta1 of 388.5. You'll see I configured every Friday at midnight and a 1 day delay.

When I try and run the script manually the delay is invoked. However the next time it will run would be at the end of the week, at which point the 1 day delay is obviously passed and the update will go through.
That's why we selected the wording we did around the cron job here:

The cron schedule isn't just how often the script checks, it's how often the script runs at all, if you make it run only once a week it will wait a week before checking again, if you wanted it to happen exactly on that Friday at that 5:15AM, you would need a zero delay, else it would actually be the next Friday at 5:15AM.
Hope that explains in detail.

 

[visortgw]

Correct to a point, for example below:
We are currently on 388.6 as the production release. Therefore if I go to beta of 388.6 it will detect a newer release but not be satisfied enough with the version difference to actually try to update as seen below:

View attachment 55862

However, if I go all the way back to 388.5 beta 1. Then not only does it detect a different firmware available but it satisfies the difference in version required to update and therefore will allow it to update.

View attachment 55863

Basically this means that if your on a beta, your safe until the next major release. If somehow your still on beta1 388.5 by the time the major release of 388.6 comes around, then it will force update you to the next major release.


Correct it doesn't need to be in router mode.



Happy you found it!



As you'll notice from the screenshot above, it was a double test, 2 birds with 1 stone, I get to demo to you what happens when I configure it exactly like you did.
In the screenshot above on beta1 of 388.5. You'll see I configured every Friday at midnight and a 1 day delay.

When I try and run the script manually the delay is invoked. However the next time it will run would be at the end of the week, at which point the 1 day delay is obviously passed and the update will go through.
That's why we selected the wording we did around the cron job here:

View attachment 55865

The cron schedule isn't just how often the script checks, it's how often the script runs at all, if you make it run only once a week it will wait a week before checking again, if you wanted it to happen exactly on that Friday at that 5:15AM, you would need a zero delay, else it would actually be the next Friday at 5:15AM.
Hope that explains in detail.

What about updating AiMesh nodes from the router as one does now manually?

 

[SomeWhereOverTheRainBow]

What about updating AiMesh nodes from the router as one does now manually?

Already asked this in my post as well...

I am wondering what failsafes are in place if the router crashes during a automated update? I saw @RMerlin mentioned the dual partition failsafe, but are there any other concerns that may need to be addressed before users consider using this script? We have @Viktor Jaep 's lovely backup script. Also, does this script check for, and update Aimesh nodes in the same firmware update process? If not, would there be away to integrate a Aimesh node updating process as well?