Seeking Feedback & Contributions: Merlin Auto Update Solutions

[glens]

How about a request to package the firmware for that (and similar?) routers separately?

 

[glens]

Not so sure /dev and /tmp source space doesn't overlap, thus not really "fillable" simultaneously. Just a WAG...

 

[Yota]

How about a request to package the firmware for that (and similar?) routers separately?

It's honestly difficult, and RT-AC68U users may not know which correct version of firmware to choose.

Is the RT-AC68U V4 HND?

Anyone know?

www.snbforums.com

Not so sure /dev and /tmp source space doesn't overlap, thus not really "fillable" simultaneously. Just a WAG...

The upload behavior of /dev is the weirdest, in my tests the GUI didn't even return any page after uploading.

 

[glens]

Just have to blacklist (at least) that router, then, seems.

 

[ExtremeFiretop]

Just have to blacklist (at least) that router, then, seems.

I had a feeling some models would need to be blacklisted.
RT-AC68U may just need to be one of those models unfourtunantly.

I don't know if we can solve the weird issue with the RT-AC68U, one of the few such extreme models, and if we can't solve it, we'd have to exclude the RT-AC68U and its variants from using this script. I think the RT-AC68U is the most challenging model.

All these tests are valuable data, I appreciate you trying to debug it and get it working, sadly if we can't get this method to ever actually *upgrade* your firmware, even manually, then there is little hope to find a scripted method that works.

But you testing and showing that even on a worse case on such a model, that no permanent damage was done using this new method, and that is also a good take away for me. I'll re-implement the model block today.

Asides from the RT-AC68U, any other models we can expect to have similar issues?

As for changes, Martinski implemented a 0 to 30 day user selectable wait period for the actual update to process after it's been found. (This is a really nice improvement.)

The default buffer is 7 days, and to me that makes sense, the default cron is once a week as well, but you could in theory turn the cron schedule up to once a day and then the waiting period up to 30 days for example, so your guaranteed to be updated on the 30th day, etc.

Seems unlikely that a broken firmware would make it out into the wild without a patch/fix or being flat out removed within 7 days.

 

[dave14305]

I do dislike the current method of scraping sourceforge for the latest release. Merlin firmware is already capable of detecting updates by running /usr/sbin/webs_update.sh. If there’s an update available webs_state_flag will be set to 1 and the version details will be in webs_state_info.

Setting the countdown timer from a hook in a custom update-notification script would let us rely on a proven detection method, in my opinion.

The firmware will run its own detection script every night automatically, so this script can be more passively scheduled than the current fixed cron schedule.

 

[ExtremeFiretop]

I do dislike the current method of scraping sourceforge for the latest release. Merlin firmware is already capable of detecting updates by running /usr/sbin/webs_update.sh. If there’s an update available webs_state_flag will be set to 1 and the version details will be in webs_state_info.

Setting the countdown timer from a hook in a custom update-notification script would let us rely on a proven detection method, in my opinion.

The firmware will run its own detection script every night automatically, so this script can be more passively scheduled than the current fixed cron schedule.

but unless the webs_state_info also includes a direct download url, we would only benefit by grabbing the version number and skipping that step, right?
But would still end up scraping sourceforge for that version to download? Instead of scraping them all and sorting for the newer/highest release.

As for the detection method relying on the routers detection method, we could probably take that turn, now that this new delayed cycle is implemented that is.
Before this delay cycle, the cron was the only way to exercise control on when / if it would action, now even if it checks every night, a user can select a delayed cycle so it becomes less of a requirement.

 

[dave14305]

but unless the webs_state_info also includes a direct download url, we would only benefit by grabbing the version number and skipping that step, right?
But would still end up scraping sourceforge for that version to download? Instead of scaping them all and sorting for the newer/highest release.

I’d rather we go to SF.net knowing what we expect to find (model + /Release/ + version) and aborting if we don’t find it. If there is a mismatch between Merlin’s manifest.txt and SF.net, I’d bail out. And the info from the manifest will make its way into nvram on the nightly update check.

As for the detection method relying on the routers detection method, we could probably take that turn, now that this new delayed cycle is implemented that is.
Before this delay cycle, the cron was the only way to exercise control on when / if it would action, now even if it checks every night, a user can select a delayed cycle so it becomes less of a requirement.

I prefer not to duplicate effort or reinvent the wheel. I question the usefulness of an interactive CLI update. Why go through that trouble instead of just uploading the firmware directly? But a trigger from the built-in update-notification script can then schedule the auto-update 7-30 days out. If the version info changes between those times, start over with a new 7-30 days.

Give the user a CLI to login and abort the scheduled update. Better to send an email with the release notes as a reminder 48 hours and again 12 hours before the update. Would require the users to setup email settings in amtm.

 

[Yota]

Asides from the RT-AC68U, any other models we can expect to have similar issues?

RT-AC68U, RT-AC1900, RT-AC1900P and RT-AC66U_B1 these are all variants of the RT-AC68U, use the same firmware, and have the same 256MB of RAM.

But what I suggest is not to use a fixed list, but to use a script to determine the /tmp partition size. If the size is less than twice the firmware size, the script will not be run and an error will be reported.

Because in many previous cases, the firmware had memory leaks, and even to this day there are memory leaks in some Trend Micro components, and they slowly fill up /tmp on models that have been running for more than a year.

Other user scripts may also use /tmp as a cache and configuration location, and they may store large files here.

So we shouldn't assume that low RAM issues only affect a limited number of models.

Additionally, I recommend deleting the zip file in /tmp after the unzip is complete, even on the 512MB/1024MB model. Because the firmware uploaded by the GUI will also be cached to /tmp first, we should reduce the usage of /tmp to avoid complications in the user environment that lead to failure to update.

 

[Yota]

The firmware will run its own detection script every night automatically, so this script can be more passively scheduled than the current fixed cron schedule.

What happens if the user turns off "Scheduled check for new firmware availability" on the firmware upgrade page?

 

[glens]

They've consciously chosen not to have the router check for new firmware? My guess is that it won't.

 

[Tech9]

If you touch AiMesh page in Asuswrt-Merlin in will perform new firmware check regardless of this setting.

 

[Yota]

If you touch AiMesh page in Asuswrt-Merlin in will perform new firmware check regardless of this setting.

Aw, it seems that's why I'm getting this

Release - Asuswrt-Merlin 386.1 is now available

Dirty upgrade from 386.1 to 386.1_2 on AC-88U smoothly. Thanks for the firmware!!

www.snbforums.com

 

[Tech9]

The lack of dependencies in Asuswrt makes it a bit unpredictable. Things you enable or disable are not guaranteed to be enabled or disabled neither guaranteed to stay enabled or disabled. You have to know and match the holes in the swiss cheese model if you want something to happen.

 

[ExtremeFiretop]

I’d rather we go to SF.net knowing what we expect to find (model + /Release/ + version) and aborting if we don’t find it. If there is a mismatch between Merlin’s manifest.txt and SF.net, I’d bail out. And the info from the manifest will make its way into nvram on the nightly update check.

I prefer not to duplicate effort or reinvent the wheel. I question the usefulness of an interactive CLI update. Why go through that trouble instead of just uploading the firmware directly? But a trigger from the built-in update-notification script can then schedule the auto-update 7-30 days out. If the version info changes between those times, start over with a new 7-30 days.

Give the user a CLI to login and abort the scheduled update. Better to send an email with the release notes as a reminder 48 hours and again 12 hours before the update. Would require the users to setup email settings in amtm.

This was a good idea, I actually like the CLI for setup for the credentials, for the schedule of the delay cycle, and for the rog file or pure build, but the point was valid on the method of detection and scraping SF.

So with this in mind Martin implemented some code modifications/additions last night to use the router's built-in "F/W Update Check" & NVRAM variables to get the latest release update version to set or reset the delayed days for actual updates.

Martin also added a menu item to enable/disable the built-in "F/W Update Check" so that users can control the Auto-Update feature from the same place as the router.

Along with other miscellaneous code improvements.

What happens if the user turns off "Scheduled check for new firmware availability" on the firmware upgrade page?

They've consciously chosen not to have the router check for new firmware? My guess is that it won't.

This is what we observed as well.

 

[Maverickcdn]

Merlin firmware is already capable of detecting updates by running /usr/sbin/webs_update.sh. If there’s an update available webs_state_flag will be set to 1 and the version details will be in webs_state_info.

The firmware will run its own detection script every night automatically

Question unrelated to this project on this...

Do you know if manually invoking /usr/sbin/webs_update.sh, will this also trigger the update-notification merlin script to run if an update is found? Or does update-notification only get called with the fw scheduled check?

And I vaguely remember seeing somewhere the firmware check is every 48hrs or is it every 24hrs?

 

[dave14305]

Do you know if manually invoking /usr/sbin/webs_update.sh, will this also trigger the update-notification merlin script to run if an update is found? Or does update-notification only get called with the fw scheduled check?

This is a good point. The update-notification only gets called by the nightly check of the firmware. Running the script manually will trigger the flashing icon in the GUI, but not the custom script (at least by searching the code).

And I vaguely remember seeing somewhere the firmware check is every 48hrs or is it every 24hrs?

Watchdog will check at 2am or so every night, with some randomization thrown in.

 

[ExtremeFiretop]

Just wanted to mention lots of improvements on the script over the last 2 months.

I've just recently updated to the latest 388.5.0 successfully using the script.
And so far it's being tested on the following devices:

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

And no, not once has a router died using the curl method.

 

[ExtremeFiretop]

Found the problem with .pkgtb files and .trx files... The logic was only filtering for .w files.
Newest release is fully working with all file update types (.w and .pkgtb and .trx files)

Was successfully tested on a: AX88U_Pro using .pkgtb files.
Now the list of tested models includes:

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

Looking for more testers since @Yota's been away since end of October, but would be great to find someone willing to try on any of the following models:

• RT-AC68U (Untested)
• RT-AC66U_B1 (Untested)
• RT-AC1900 (Untested)

As we made changes to logic for memory handling and also storage handling.
Those models will now be unblocked and instead need a USB connected for the firmware update to run as found below:

If anyone is willing to test on those models, please send me a PM or report the results using the template on Github.
Thanks in advance!

 

[MatteoPV]

Good morning everyone. I installed the script to have automatic updates of the addons and since then when I enter AMTM the system is as if it were in a loop, it continues to repeatedly give me the screen of the addons that I have installed. How can I remove the addon auto update script?