What's new

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

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

ExtremeFiretop

Senior Member
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.

1713269774237.png

1713269778725.png

1713269783328.png


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 router model detection and Automatic update detection.
  2. Automatically install updates to your router with the latest firmware from the Asuswrt-Merlin repository.
  3. Logic to manage cron jobs for automated firmware update checks.
  4. Notifications for new MerlinAU updates and download the latest version of MerlinAU
  5. User configurable wait periods. Wait for a set duration after a new firmware release.
  6. Easy Enable/Disable: A menu switch for automatic update checking.
  7. Easy Uninstall: A routine to cleanly uninstall MerlinAU, removing all related files and settings.
  8. Logging and Cleanup: MerlinAU maintains logs for its operations and includes functions for cleanup tasks.
  9. Blinking LEDs: A visual indicator before starting the firmware update.
  10. Changelog verification check: Checks the changelogs for very obvious red flags and prompts for approval.
  11. Checks RAM usage: Functions to check and manage available memory for firmware update operations.
  12. Compatible with ROG and non-ROG routers; select ROG or Pure Build for ROG routers.
  13. Backup the new firmware version to the USB drive. (If USB is selected for storage)
  14. Email notifications if you configured email options in AMTM.
  15. Automatic backup with BACKUPMON if installed.
  16. Allow or Block Alpha/Beta upgrades to Production versions of the same cycle. (388.6.alpha1 or 388.6.beta1 --> 388.6.0)
  17. Automatically stops all Entware services before the flash if running.
  18. Automatically stops diversion if installed and running before the flash.
  19. Unmounts any physically attached storage via USB as the last step before the flash.
  20. AiMesh Node Update Check from Primary Router. (No Flashing from Primary, MerlinAU needs to be on each node for flashing)

What update mechanism does MerlinAU use to Auto-Update?

MerlinAU 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-AX6000 (Tested)
  • GT-AX11000 (Tested)
  • GT-AXE11000 (Tested)
  • GT-AX11000_PRO (Tested)
  • RT-AX88U_PRO (Tested)
  • RT-AX88U (Tested)
  • RT-AC86U (Tested)
  • RT-AX86U (Tested)
  • RT-AX86U_PRO (Tested)
  • RT-AX86S (Tested)
  • RT-AX58U (Tested)
  • XT12 (Tested)
All tests were successful on all subsequent firmware updates, the firmware upgraded correctly, and no issues with compatibility with other addons were identified.

UNSUPPORTED MODELS: (Single image models) - i.e. Any model that uses a .trx file​

Blocked due to being a single image model, as well as low RAM/ROM space
Most AC models are end-of-life and have not received updates in several years.
  • RT-AC87U (Blocked)
  • RT-AC56U (Blocked)
  • RT-AC66U (Blocked)
  • RT-AC3200 (Blocked)
  • RT-N66U (Blocked)
  • RT-AC88U (Blocked)
  • RT-AC5300 (Blocked)
  • RT-AC3100 (Blocked)
  • RT-AC68U (Blocked)
  • RT-AC66U_B1 (Blocked)
  • RT-AC1900 (Blocked)

How to Get MerlinAU

(Edit: Feburary 3rd 2024) - NOW AVAILABLE THROUGH AMTM!
Many thanks to @thelonelycoder for including us in the AMTM family!

MerlinAU is also available for download on our GitHub repository here.
Installation and update information are provided on the same github page.
For any questions please visit our FAQ on Github here

PLEASE READ ALL THE DETAILS AND BACKUP BEFORE STARTING!

Post-Update Notes for MerlinAU Users

  • Confirm your entered crons with Crontab.guru here: https://crontab.guru/ and review the below FAQ questions in the second post.
  • 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.

Again for any additional questions the FAQ was moved to Github here: https://github.com/ExtremeFiretop/MerlinAutoUpdate-Router/wiki
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!
 
Last edited:
MerlinAU FAQ Moved to Github HERE:
https://github.com/ExtremeFiretop/MerlinAutoUpdate-Router/wiki


Latest Changelog can be found
here

-V1.1.1

Previous Changelogs can be found below for historical reference:
-V1.1.0

-V1.0.10

-V1.0.9

-V1.0.8

-V1.0.7

-V1.0.6

-V1.0.5

-V1.0.4

-V1.0.3

-V1.0.2

-V1.0.1

-V1.0.0

-Pre-Release V0.2.54

-Updated April 16th, 2024
 
Last edited:
Let‘s hear the users reactions - this sounds like solid work and - despite my reservations earlier - be a candidate for amtm integration.
 
A lot of work and I applaud the expertise used here by both @ExtremeFiretop and @Martinski.

This may be made better if it implemented (if it can, of course) something like the following (or better).


The ability to have access to files to put the router back to how it was is invaluable.

For myself (and most of my customers), an auto-updater is expected to cause more issues than it is worth, not on its own, but from unseen interactions that can't be accounted/scripted for.

RMerlin firmware is so highly preferred because it explicitly disables such features.

I do hope such collaborations continue for amtm and RMerlin-supported routers, of course. But 'just' an auto-updating script? I'm shuddering in advance.
 
A lot of work and I applaud the expertise used here by both @ExtremeFiretop and @Martinski.

This may be made better if it implemented (if it can, of course) something like the following (or better).


The ability to have access to files to put the router back to how it was is invaluable.

For myself (and most of my customers), an auto-updater is expected to cause more issues than it is worth, not on its own, but from unseen interactions that can't be accounted/scripted for.

RMerlin firmware is so highly preferred because it explicitly disables such features.

I do hope such collaborations continue for amtm and RMerlin-supported routers, of course. But 'just' an auto-updating script? I'm shuddering in advance.

If you connect a USB drive to the router, MerlinAU will dump the update firmware file on the USB before flashing.

We haven't implemented a backup solution directly as there's no reason to re-invent the wheel, solutions like BACKUPMON from @Viktor Jaep is what we recommend on GitHub and what I personally use to dump backup Configs to the USB as well weekly.

Between our script saving the firmware to the USB, and his script saving the configuration to the USB, most bases should be covered offline in a disaster situation.

However I'm not against working towards close and tighter integration to achieve a confirmed backup before a flash if you have BACKUPMON installed for example. :)

or a way to configure current firmware to be dumped before flashing. For now if you configure BACKUPMON to do weekly or even monthly backups your likely safe offline, but future goals for the project for sure!

Thanks for the positive feedback and continued support and advice throughout this journey btw!
 
Let‘s hear the users reactions - this sounds like solid work and - despite my reservations earlier - be a candidate for amtm integration.

Thank you!

I was waiting to hear from most available models before reaching out myself.

I know we still have a bit of tweaking to do before we integrate if we go down that path. But we've taken some preemptive steps to make it easy, and try to follow current standards.

Hoping to hear more good feedback soon! Thank you for following the project! Means a lot!
 
Good job!
I'll be testing on my GT-AX6000.

I suggest a simple thing - do an "integration" with backupmon - for those who have it installed, make the possibility to auto run a full backup before the firmware upgrade.
A little fail safe.
 
Good job!
I'll be testing on my GT-AX6000.

I suggest a simple thing - do an "integration" with backupmon - for those who have it installed, make the possibility to auto run a full backup before the firmware upgrade.
A little fail safe.

I'm up for it!! I don't think it's a bad idea.

If @Viktor Jaep has a hanging hook for me, I'll gladly trigger it before a flash!

Thanks again, and feel free to report here or on GitHub the results of your upgrades for that model. (So we can update the successful tests list!)
 
I'm up for it!! I don't think it's a bad idea.

If @Viktor Jaep has a hanging hook for me, I'll gladly trigger it before a flash!

Thanks again, and feel free to report here or on GitHub the results of your upgrades for that model. (So we can update the successful tests list!)

Let's go, guys 😀
---
A doubt I have (I haven't read the code yet), is that - on this particular model, with two firmware version (ROG and non ROG), does it upgrades to the same version I have? Or does it always upgrade to the non ROG version?
 
Let's go, guys 😀
---
A doubt I have (I haven't read the code yet), is that - on this particular model, with two firmware version (ROG and non ROG), does it upgrades to the same version I have? Or does it always upgrade to the non ROG version?

ROG models like mine or yours, give you a new option in the menu to configure. Essentially on the first attempt to flash interactively, it will detect the ROG version and prompt you with which version you would like to use (ROG or Pure).
That selection is saved for all future flashes, and can be changed later from the menu.

If you happen to not configure the first flash interactively, and it happens to find an update before you configured it, it will default to the Pure (Non-ROG) version of the file but again give you the option in the menu to change at any point.

1705924640414.png
 
Let's go, guys 😀
---
A doubt I have (I haven't read the code yet), is that - on this particular model, with two firmware version (ROG and non ROG), does it upgrades to the same version I have? Or does it always upgrade to the non ROG version?

I just thought of a new way to eliminate the need for the first interactive flash. (if you want to configure it to use the ROG build.)

More work ahead! Lol!
 
I just thought of a new way to eliminate the need for the first interactive flash. (if you want to configure it to use the ROG build.)

More work ahead! Lol!
That's the spirit 😂😁

Btw, you could add an option to check for script updates.
When integrated to amtm, that's a must have.
 
That's the spirit 😂😁

Btw, you could add an option to check for script updates.
When integrated to amtm, that's a must have.

Check the photo in the OP, its already there :)
 
Oh I'm sorry, didn't notice that it only appears when an update is available 😇

No worries like I mentioned above I tried to follow standards as closely a possible so really only a few tweaks would be needed for amtm integration. Wouldn't take very long.

Right now I don't include a force-update option so due to that, the update option only shows when one is available :)
 
I suggest a simple thing - do an "integration" with backupmon - for those who have it installed, make the possibility to auto run a full backup before the firmware upgrade.
A little fail safe.

Sent a DM to @Viktor Jaep with some ideas on this :)

I just thought of a new way to eliminate the need for the first interactive flash. (if you want to configure it to use the ROG build.)

Already have this ready in dev, and quickly tested with positive results here: https://github.com/ExtremeFiretop/MerlinAutoUpdate-Router/pull/82/files

Should eliminate the need for a "interactive" first run to change to ROG builds for ROG routers.
I still recommend an interactive first run so you can see what going on for any user, before you let it do it through a background cron job.

But technically won't be a requirement going forwards for ROG users that want to continue to use the ROG specific interface.
 
Assuming a user has setup email credentials in AMTM, how about an email notification after an update?
 
Assuming a user has setup email credentials in AMTM, how about an email notification after an update?

Oh that's a pretty slick idea...
 
Recently I have had a few upgrades that told me to manually reboot the router.

What would this tool do then (if anything is possible)?
 
Recently I have had a few upgrades that told me to manually reboot the router.

What would this tool do then (if anything is possible)?

It handles the manual reboots if required. (and reboots to complete the update)
 
Last edited:

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top