Seeking Feedback & Contributions: Merlin Auto Update Solutions

[ExtremeFiretop]

Also please keep in mind all I did was modify the original script this some new logic to include this method, it's pretty basic, but again it's just a starting point to review, basically we started over again with the Original Post. (OP)
Any suggest changes and improvements if you can think of anything (Especially @RMerlin , @Yota @dave14305 )!!

 

[dave14305]

parses SourceForge for the latest release for that model

At the low volume of users expected, I would just get the latest version from Merlin’s manifest. The router hits it anyway doing update checks itself.
https://fwupdate.asuswrt-merlin.net/manifest.txt

 

[dave14305]

I can envision the router version being triggered by the update-notification script when a new release is available. The user would configure upfront a time of night to install it (e.g. 3AM) and how many days to delay the upgrade before auto-updating. Then it could just schedule the cron job in a persistent manner (e.g. adding it to services-start) until the upgrade happens.

 

[dave14305]

Curiously, I can’t get the upgrade to work when run directly on the router with curl. It’s like the file upload stops, or curl is killed, or httpd stops. Not sure. Maybe the AC86U is lacking enough RAM to store the unzipped firmware file in tmpfs and receive it as an upload.

 

[ExtremeFiretop]

Curiously, I can’t get the upgrade to work when run directly on the router with curl. It’s like the file upload stops, or curl is killed, or httpd stops. Not sure. Maybe the AC86U is lacking enough RAM to store the unzipped firmware file in tmpfs and receive it as an upload.

Odd, if your using my script. I just identified a potential issue i can quickly correct for.
I hard coded http://www.asusrouter.co by accident on the curl request, instead of using the routers IP.

So you would need this enabled for it to work?:

If your not using my script or you already tweaked that, then it's likely something else like you mentioned.

 

[dave14305]

If your not using my script or you already tweaked that, then it's likely something else like you mentioned.

I’ve tried localhost, 127.0.0.1, www.asusrouter.com and 192.168.50.1 with the same results…

 

[Yota]

Curiously, I can’t get the upgrade to work when run directly on the router with curl. It’s like the file upload stops, or curl is killed, or httpd stops. Not sure. Maybe the AC86U is lacking enough RAM to store the unzipped firmware file in tmpfs and receive it as an upload.

If you download the firmware to tmpfs (RAM), it is very likely that there is not enough RAM to store the firmware, because the router upgrade program will also cache the complete firmware on the RAM before flashing, so you actually have the firmware stored twice in RAM.

My suggestion is to save the firmware on a USB drive. curl gets the firmware file by pointing to /mnt/sda1/xxxx and then uploads it to the GUI.

The only thing to note is that the USB drive will cache the content to RAM after downloading/writing. You can quickly release RAM through some commands such as unmounting and remounting the USB drive.

It was necessary to test the RT-AC68U because it has an extremely large firmware file (two firmwares in one/80MB) and has low RAM (256MB). If the RT-AC68U can successfully update automatically, the problem of lack of RAM will no longer affect any model.


I think automatic firmware updates must rely on USB drives, otherwise we cannot perform various backups and future restores.

 

[Yota]

My only instant thoughts is if ASUS changes stuff in regards to the Web UI or any of the introduced security measures to avoid storing clear text passwords in the router.

In fact, once the curl-based automatic firmware update script appears, its only problem is the risk of storing clear text passwords in the router. Asus has taken a number of steps to follow the advice of some security experts (such as not storing clear text passwords on routers) to find a balance between security and the openness of the system. In fact, what we have done will directly break the security architecture established by Asus, and we must find ways to mitigate this security risk as much as possible.

One idea is that we don't store the clear text password, but the bese64 encoding of the password, after all that's the only thing we need in the whole process. This base64-encoded content is then AES256 encrypted. Of course, the encrypted key is saved in clear text, but it is enough to prevent a large number of automated scripts from abusing our stored password.

Almost all scripts/programs running on the Asuswrt router use root privileges, so relying on Unix/Linux's own key protection mechanism is obviously risky, but we can also try this method.

 

[Yota]

I hard coded http://www.asusrouter.co by accident on the curl request, instead of using the routers IP.

I recommend that the script always uses the router's IP address because when the router itself resolves DNS it may bypass the custom IP address specified in hosts, as Asuswrt-Merlin did introduce a change previously where the router itself uses the upstream default DNS resolution, while the LAN uses the router's custom DNS (such as DoT or others). Of course, the IP address needs to be a variable, which can be obtained through nvram.

 

[Yota]

Any suggest changes and improvements if you can think of anything

Thank you, glad I could help.

I updated my reply yesterday with two feature suggestions. I was a little drunk last night, and my LED idea was indeed a bit crazy, hahaha.

Seeking Feedback & Contributions: Merlin Auto Update Solutions

Lots and lots of valuable take away here. Thank you very much!!! Especially the SourceForge stuff and the idea on the backup to the USB. You've given both valuable points and ideas to alternative solutions and I like that, it's really what the discussion was aiming to achieve. @RMerlin as well...

www.snbforums.com

 

[Yota]

Just tested on my own router (GT-AXE11000) and it seems to work for me.

We always need to keep an eye on RAM usage, I have an RT-AC68U that I can use for debugging (I can test it this weekend, let me know if you need me to do anything).

Therefore, the reasonable use of RAM will determine whether we can upgrade smoothly. This script requires many techniques to free up RAM.

Of course, high-end models won't run into RAM bottlenecks as easily, but hopefully this project will work for everyone.

 

[Yota]

I can envision the router version being triggered by the update-notification script when a new release is available. The user would configure upfront a time of night to install it (e.g. 3AM) and how many days to delay the upgrade before auto-updating. Then it could just schedule the cron job in a persistent manner (e.g. adding it to services-start) until the upgrade happens.

I like this great idea. The router itself performs update checks, so we don't need to send DDOS to RMerlin's server, hahaha.

 

[ExtremeFiretop]

I'm starting to think the problem is storage as well...

1. We download the .zip (145MB in my case) and then expand it to a folder which becomes 162 MB,
2. I still haven't deleted the .zip in the script so 145+162MB which is 307MB,
3. Then because of our method of going through the UI for an upload, we select an 80MB file in that folder (in my case) to be essentially copied on a different location on the router (through the UI).

So the script when run to completion currently does 387MB of expanding itself in my case to do the firmware flash

 

[ExtremeFiretop]

Going to try to just manually copy the .w to the home and then manually do the curl request, and see if it makes any difference, that should be 160MB instead of 387

 

[Yota]

Going to try to just manually copy the .w to the home and then manually do the curl request, and see if it makes any difference, that should be 160MB instead of 387

This is still too big! and 120% of the firmware size must be reserved in free RAM for the GUI to ensure a successful update. Want to try a USB drive? (/mnt/sdaX/XXXX)

 

[ExtremeFiretop]

This is still too big! and 120% of the firmware size must be reserved in free RAM for the GUI to ensure a successful update. Want to try a USB drive? (/mnt/sdaX/XXXX)

I'm going to have too, because it still failed for me again doing it manually as described.

Got to about 4% of the 80MB and then said, BYE! Kinda reminds me of what was happening when using Invoke-WebRequest on Powershell, it would start but eventfully complain and quit.

 

[dave14305]

I tried USB and the upgrade process seems to be trying to eject the USB before the upload is finished.

 

[ExtremeFiretop]

Whats the fundamental difference between doing the curl on our personal devices and the router itself? Storage and Memory I guess are probably the only real culprits?

 

[Yota]

I tried USB and the upgrade process seems to be trying to eject the USB before the upload is finished.

I had thought that ejecting the USB happened after a successful upload. It now appears that the upgrade program may have detected the lack of RAM and done something to free it up.

An idea, is it possible to prevent the router from ejecting the USB drive during this process? Or mount it in an abnormal place?

I remember seeing someone share eject and reconnect commands on the SNB forums a few years ago, I forget where. Might need some work.

I'm going to have too, because it still failed for me again doing it manually as described.

Got to about 4% of the 80MB and then said, BYE! Kinda reminds me of what was happening when using Invoke-WebRequest on Powershell, it would start but eventfully complain and quit.

View attachment 53486

That's weird, it shouldn't be exactly 80MB.

Whats the fundamental difference between doing the curl on our personal devices and the router itself? Storage and Memory I guess are probably the only real culprits?

You are right, the only problem with this is that it will rely on a second device, which means its use cases are limited.

 

[ExtremeFiretop]

That's weird, it shouldn't be exactly 80MB.

A fresh download is reporting as 80MB