What's new

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

  • 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!

Why would they need to be on stock firmware? You initiate a manual update of AiMesh nodes now from the parent.
Because in the built in merlin firmware, the only nodes that support the parent firmware API downloading from the upstream and install are stock firmware on nodes. The nodes that run merlin have to be manually downloaded, and manually installed when triggering firmware API from parent node.

Basically if I trigger a firmware update check from parent node(running merlin firmware), the only nodes which will be eligible for the API to do the update for me(meaning without me manually downloading and manually installing myself) , are nodes that run stock firmware.
 
Last edited:
The only other alternative is just build an option to approve every release or ideally get RMerlin to agree to standardized wording for specific changes for me to find with the script.

I could also wing it with a collection of words that are considered high risk and ask for approval. But with that there's no guarantee it catches it if RMerlin decides to spice it up and talk with an accent in his writing one day.
Thank you for all your hard work, but I guess I will never trust your script to auto-update my network if it depends on you having reviewed the changelog instead of me.
 
Thank you for all your hard work, but I guess I will never trust your script to auto-update my network if it depends on you having reviewed the changelog instead of me.

No worries, I understand it won't be for everyone's use case. But it is for some use-cases for sure :)
Right now my thought is do a collection of words like "factory reset" etc. It's not perfect but it's as close as we can get without human intervention. The rest is on the user to check the changelogs.

As for the beta to production suggestion.

I'm not against the logic suggested one bit, but I still think it should likely be a config option for users which is saved to the settings file if it detects you install a beta.
Basically if you go to a beta, until the option in the file is set that you approve flashing beta to production, then it doesn't do anything. (Default disabled)
 
Because in the built in merlin firmware, the only nodes that support the parent firmware API downloading from the upstream and install are stock firmware on nodes. The nodes that run merlin have to be manually downloaded, and manually installed when triggering firmware API from parent node.

Basically if I trigger a firmware update check from parent node(running merlin firmware), the only nodes which will be eligible for the API to do the update for me(meaning without me manually downloading and manually installing myself) , are nodes that run stock firmware.
Gotcha. Thanks.
 
Thank you for all your hard work, but I guess I will never trust your script to auto-update my network if it depends on you having reviewed the changelog instead of me.

Keep in mind right now if depends on no one reviewing anything 😉 That was just an idea for a potential design solution.

I think the least maintenance and human intervention position is the best, it's not a perfect solution, but a dictionary of risk words in the changelog to ask for approval is the best safeguard I can think of now.

As always, checking SNB and the change logs will always be recommended no matter what solution is implemented.
 
Keep in mind right now if depends on no one reviewing anything 😉 That was just an idea for a potential design solution.

I think the least maintenance and human intervention position is the best, it's not a perfect solution, but a dictionary of risk words in the changelog to ask for approval is the best safeguard I can think of now.

As always, checking SNB and the change logs will always be recommended no matter what solution is implemented.
Well, the Merlin Firmware is usually pretty good. As long as your updater isn't downloading beta or alpha firmware I don't think there would be an issue. From my experience, Merlin doesn't usually release anything that poses actual "risk".
 
Well, the Merlin Firmware is usually pretty good. As long as your updater isn't downloading beta or alpha firmware I don't think there would be an issue. From my experience, Merlin doesn't usually release anything that poses actual "risk".

Agreed but the potential for a need for a factory reset or a feature removal or reduction has happened in the past, and we just want to make sure we cover our bases in those situations as best we can.

Again the mentality is always safety first with this project and I hear out all the concerns which helps shape the path of the design choices we make.
 
Thank you for all your hard work, but I guess I will never trust your script to auto-update my network if it depends on you having reviewed the changelog instead of me.
Again the mentality is always safety first with this project and I hear out all the concerns which helps shape the path of the design choices we make.

So I'm gonna go with a triple pronged approach to this problem.

1. I'm implementing a passive changelog verification in dev as found below:

1706023474635.png


This will do a few things for us.

It will give us a little piece of mind that if someone is completely clueless and not paying any attention at all, that it will check for very obvious red flags and advise.
This will prevent users from claiming they "didn't know what they were getting into" with any given update.

The red flags phrases it will search for are:

- features are disabled
- factory default reset
- break backward compatibility
- must be manually
- strongly recommended


I've selected those phrases as I've identified a pattern in the general language used in the changelogs as found here: https://www.asuswrt-merlin.net/node/10
and here: https://www.asuswrt-merlin.net/node/11

If you do a control + F search on both these pages for the phrases above, you'll find it's very specific in every case, and usually something the user should be aware of before flashing.
Why am I using whole phrases? Because I don't want to be too restrictive, the script won't care about specific words like "strongly" or "recommended" it cares about "strongly recommended"

Finally, it will give RMerlin some passive control over this script. (if he so chooses...)
If I implement something like "strongly recommended" RMerlin may decide to actively use it as a feature if he knows it exists. Worst case is he doesn't, then it's just a passive listener in the changelogs incase he uses the same language someday. (Like he as in the past.)


2. Martinski extended the Default Delay Cycle

As documented in PR: 86 Martinski has increased the maximum number of days to postpone new F/W updates from 30 days to 60 days. (Incase you plan to go on a month long vacation).
And he has also set the default to 15 days for new installs from 7 days.

This should give users more time in case they want to review/check change logs, or read SNB Forums posts related to the specific new F/W version.
If someone wants to review & check the change log every time before deciding whether or not to go ahead with a F/W update, they can set the delay to 30 days, which allows plenty of time for them to do what they need to before deciding to accept or stop the update.


3. Remind everyone this tool is to streamline your job, not replace it.

My personal preference as I've done already:

The rest is on the user to check the changelogs.
As always, checking SNB and the change logs will always be recommended no matter what solution is implemented.

Remind everyone to check/review the changelog, this script is made to streamline and make your job easier, you no longer need to stay up at night or do the steps manually yourself, but the research should still be done by you before-hand.
Set the delay to the maximum number of days so you can make a decision based on your comfort level.

I will never trust your script to auto-update my network
You can trust the script to update your network perfectly fine every time, what you really need is to trust yourself that you know when to stop it.

For now by default, if after 15 days, the user has not stopped the F/W update, it becomes a tacit approval to go ahead.
Remember you can simply disable it at anytime to stop any update and it's manual going forwards:

1706024017058.png


We can make it as dummy proof as possible, but at the end of the day, it's to each of you to determine your comfort level and specific network environment.
Your network is still your responsibility no matter how good the tools become. Make your own educated calls and use with discretion.

For example, I always read the changelogs and check for any changes that may affect my network setup. That's why I have set up a delay of 7 days for my own router, and 30 days for my parents & in-laws routers.
This allows me time to review & prepare for any possible changes and get a chance to disable it if something potently problematic comes up in the logs.

Keep in mind that as @Jumpstarter mentioned above, it's very rare on it's face this would be an issue, most of the time you can upgrade merlin firmware without a concern or thought in the world.
But if somehow there is a reset needed or a feature changed, and you didn't catch it, the script didn't catch it, and the delay didn't catch it, and you still flashed and got caught off guard by a change... Well at that point it's on you and I won't even take responsibility for that, we've done all we can.

Even in a worst case were you needed to fully reset and reconfigure, as long as you have a backup as we recommend, that takes what? Minutes of time?
Compare that to how much time you'll save for every successful flash in comparison.
 
Normally I just run stock firmware but you needed models tested so I did test.
Installed Merlin 388.5 then used script to update to 388.6 and all went well.
Model is in sig so you can now put this model on your tested list and now I am going back to stock firmware.

Your the true MVP! I love the initiative!
Thanks so much will update the list ASAP!
 
do the steps manually yourself

How many steps are need to upgrade the firmware? I honestly don’t see what is this script saving the users. It doesn’t save time. It only increases the probability of something going wrong when the user is not there. Looking at the last Asuswrt-Merlin release thread - folks with the same router model report success or failure. RT-AX88U owners for example.
 
How many steps are need to upgrade the firmware? I honestly don’t see what is this script saving the users. It doesn’t save time. It only increases the probability of something going wrong when the user is not there. Looking at the last Asuswrt-Merlin release thread - folks with the same router model report success or failure. RT-AX88U owners for example.

1. Wait until no one is using the network at night
2. Download the firmware.
3. Extract the firmware
4. Review the changelogs
5. Login to the router.
6. Upload the firmware
7. Monitor for success and reboot

Gets cut down to one step:

1. Review the changelogs

Which can be done at anytime within the delay window and at which point if your happy you just let it do it's thing overnight.

Or.

Install the script on a remote device. Configure it. And just monitor the change logs and let the script do it's thing. Only stop if it you see something you don't like in the change logs.

Instead of having to displace yourself and do all 7 steps above.

If you don't see a use case, you don't need to install it. If you do, then install it.
 
I’m sure most of Asuswrt-Merlin users can do the above under 2 minutes or faster than installing and configuring this script. Monitoring the results is what this script can’t do. Many people have fire, flood, smoke sensors on their IoT network. Router down - no notifications. Rule No.1 when upgrading firmware - be present. Some of Asuswrt-Merlin users use this firmware just because it doesn’t auto upgrade.
 
Some of Asuswrt-Merlin users use this firmware just because it doesn’t auto upgrade.

Agreed. That's why it's an addon and not built into the firmware :)

Some users use Merlin Firmware for other reasons and want to have it auto update like stock firmware and the many other IoT devices around the home.

As I already said, use your own discretion. I'm not sure what your trying to gain, with this conversation so thats the end for now.😺
 
I’m sharing my opinion. You may like it or not. I don’t like the way you handle criticism. Good luck.
 
I’m sharing my opinion. You may like it or not. I don’t like the way you handle criticism. Good luck.

You've shared it enough over the last 3 threads I've been apart of on this topic.

I'm not sure why you keep following if your opinion is what it is. First thread you told everyone the idea was dumb. Then second thread you wanted to share how dangerous and impossible this was to make safe.

Now that it is safe and functional, in this thread you want to tell everyone how you won't use it anyways. Look, good for you.

I handle all feedback the same, I as I've said many times my opinion of the usefulness of this tool wont change. It streamlines my job of handling many routers as I've mention (friends, family, inlaws) down to just reviewing changelogs

If you have actual opinions about what you'd like to see in the tool, then please share, if your just following to share your opinion of how you won't use this. My recommendation is simply move on and forget it exists. Life is simpler that way.

Thanks again! Wishing you luck as well!
 
Feature request: As soon as a new firmware is available, trigger a URL to post a useless “First!” or “Let’s Go!” reply to the release thread on the forum.

Just kidding, of course.

Maybe one that tags @Tech9 in the forums everytime someone's router successfully updates with the script.
 
Feature request: As soon as a new firmware is available, trigger a URL to post a useless “First!” or “Let’s Go!” reply to the release thread on the forum.

Just kidding, of course.
Gee, that was a roller coaster of a story. Happy that it ended so well.
 
Gee, that was a roller coaster of a story. Happy that it ended so well.

Right? I was this close to selling tickets and popcorn for the next episode.
 

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

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