Seeking Feedback & Contributions: Merlin Auto Update Solutions
- Thread starter ExtremeFiretop
- Start date
- Status
ExtremeFiretop
Very Senior Member
Jokes aside, I fully agree.
I'll be the first to admit that due to x.y.z this can't be accomplished, but until I have the x.y.z technical reasons, I am challenging myself trying.
Saying "just don't do it" or "just don't try it" isn't enough of a deterrent for me.
If the project dies, you'll still see me giving applause and a pat on the back to everyone involved, saying thank you for your work bringing this the furthest it's ever gone. I'll be happy.
I will able to sleep at night knowing the x.y.z roadblocks. It's closure. Plus the bonus is we still get to walk away with extra knowledge and ideas for a future scripts due to this Web UI discovery as dave said.
If somehow we do manage to find a way for most models that is safe and works, even more double bonus, you'll find me doing a much happier version of that applause lol.
To be honest finding a way for my models through this method is already a huge win.
Edit: As toby once said, flying used to be considered dangerous and insane, now today it's considered one of the safest methods of travel in the world.
It's only through the plane crashes and trials and errors that flying went from a crazy thought to something that happens thousands of times a day successfully.
I expect to crash and burn a few times here, but I also expect to take something away from this, I have assumed the risks.
Last edited:
Yota
Very Senior Member
Sorry, I was too busy yesterday to finish my test.
But I tested it several times this morning and I couldn't even upload the unzipped firmware to the router.
Testing the router, I cold rebooted each time to make sure the RAM didn't contain the previous firmware.
When I upload using scp it immediately tells me "No space left on device" and then everything crashes.
At the time of the crash I was unable to get any information on available memory via GUI/SSH because the shell also crashed. After the reboot nothing was logged and I had no idea what was going on, the only useful message was "No space left on device".
In order to identify the problem, I provide the following screenshot, but it doesn't give a lot of useful information.
Before uploading firmware to $HOME, the router’s available memory status:
Because after uploading, I lost the valid response to the ssh commands, so I don't get any useful information about the memory status. So I had to do a cold reboot, and after the reboot, as I said, nothing was logged.
I tested the zip file again today and I got the same error when uploading, "No space left on device". I don't understand why at all since there was clearly over 100MB of /tmp storage available before uploading.
Curl gets the cookie, and openssl generates the base64 encoding of the password. There is no problem with these. But I can't test updating the firmware using curl because I don't have a chance to upload the firmware to /tmp/home/root at all, nor is it possible with jffs since jffs is only 62MB.
Last edited:
ExtremeFiretop
Very Senior Member
I just don't understand why your getting insufficient space when you said the .zip worked via SCP before.
I know you said you rebooted to clear anything on there, but it makes no sense why you would still have not enough space to me.
Can you confirm the .zip still works via SCP? if not maybe the router needs a full factory reset to test again from scratch?
Naturally we cannot test any further of the script or manually, if we can't even find a way to manually get the firmware to the router.
That seems like a pretty big issue to me, anyone have any ideas or opinions not listed here?
Yota
Very Senior Member
No, no luck.
I will reset it, but before that I want to update the router to avoid this is a bug in the 386.7 firmware.
The screenshot below is the memory usage status when updating firmware using GUI (user manual firmware upgrade method).
I repeated the free command before rebooting to get as much status as possible.
Of course, the update ended normally without any errors.
ExtremeFiretop
Very Senior Member
Very good discovery, please keep me/us informed as you re-run the tests on the newer firmware
Yota
Very Senior Member
I just did a factory reset on 386.12.
Then did a minimal setup: turned off WiFi, turned on SSH and WAN access (since I could access the debug router from WAN)
Debugging the router is the same as before, its WAN is connected to my home LAN using a dynamic IP.
Then I tried to upload the unzip firmware to the router using scp this time, without any errors.
This is the memory status of uploading firmware to /tmp/home/root.
Although I can now test updates using curl in SSH, I want to continue to reproduce the "No space left on device" error because it is a serious error and can completely disable the functionality of all programs on the router.
My next step would be to cold reboot the router (clear the RAM), then upload the zip file and try to unzip it on the router. because /tmp effective size (125MB) cannot store two 90MB firmwares (one firmware and one unziped).
I hope I can reproduce the error.
Yota
Very Senior Member
The strangest thing happened. Despite insufficient /tmp storage space, I still cannot reproduce the error that occurred on 386.7.
During the decompression process, although I was told "No space left on device" again, everything worked normally, I could run any command normally, and the GUI did not crash.
"df: /tmp: Value too large for defined data type" in the screenshot above is not a real error. After using the rm command to delete the firmware file, the df command returns to normal.
Any ideas for future testing?
If that's just a bug with 386.7, what if the same bug happens with future firmware?
At 386.7, /tmp has enough space, but cannot store 90MB of firmware, and everything crashes after a "No space left on device" error, which can only be solved by powering off and cold rebooting.
Next I will test putting the firmware zip on a USB drive and unzip it on the USB drive then copy to /tmp/home/root and if all is ok I will downgrade to 386.7 to investigate further.
Last edited:
Yota
Very Senior Member
Frankly I'm tired of trying to convince people who will never use this script. I'm tired of replying to their points.
The flash process will be as safe as the user did it. Their objection was BS and I guess they didn't even look at the source code.
If they looked at the source code they would know that, as we talk about publicly, the biggest security risk is the clear text password.
Of course, that could also include the weird memory issue I'm currently having on the 386.7, but I'm trying to understand the cause and provide a solution.
I think we should ignore their posts and focus on what we should do.
L&LD
Part of the Furniture
This method will never be as 'safe' as if doing it via the GUI. You're assuming the source code/internal workings will stay the same indefinitely.
The points brought up are valid, including the ones by RMerlin. Ignore at your own risk.
Given the above, and as I've already stated a few times before in this thread, I still would like to see further development here. This particular script may never become mainstream (at least, not without Asus' direct involvement), but I have no doubt what is learned here will be applicable to future endeavors.
The 'learning' is what is important here, not the completion of this script (which will always be iffy, without Asus support and blessing).
The points brought up are valid, including the ones by RMerlin. Ignore at your own risk.
Given the above, and as I've already stated a few times before in this thread, I still would like to see further development here. This particular script may never become mainstream (at least, not without Asus' direct involvement), but I have no doubt what is learned here will be applicable to future endeavors.
The 'learning' is what is important here, not the completion of this script (which will always be iffy, without Asus support and blessing).
ExtremeFiretop
Very Senior Member
Sorry, which method is this? the hnd-write or the current method literally logging into the web GUI and uploading it like a user? (We no longer use hnd-write since somewhere in page 7)
If something fails, it's likely the login and upload due a change on the GUI, etc, not the flash.
Yota
Very Senior Member
I think I have just fully verified the update of RT-AC68U on 386.12. The update went smoothly. I saw that the router automatically restarted during the update process, and the output of curl was also normal.
Below are the complete terminal commands and output without personal information:
Below are the complete terminal commands and output without personal information:
Bash:
ASUSWRT-Merlin RT-AC68U 386.12_0 Mon Sep 4 15:47:31 UTC 2023
admin@RT-AC68U-****:/tmp/home/root# free
total used free shared buffers cached
Mem: 255716 61968 193748 0 860 10124
-/+ buffers/cache: 50984 204732
Swap: 0 0 0
admin@RT-AC68U-****:/tmp/home/root# df -h
Filesystem Size Used Available Use% Mounted on
/dev/root 32.8M 32.8M 0 100% /
devtmpfs 124.8M 0 124.8M 0% /dev
tmpfs 124.9M 768.0K 124.1M 1% /tmp
/dev/mtdblock4 62.8M 1.7M 61.0M 3% /jffs
/dev/sda 7.5G 91.3M 7.4G 1% /tmp/mnt/sda
admin@RT-AC68U-****:/tmp/home/root# cd /tmp/mnt/sda
admin@RT-AC68U-****:/tmp/mnt/sda# ls -lah
drwxrwxrwx 1 admin root 4.0K Dec 31 1969 .
drwxrwxrwx 3 admin root 60 May 5 01:09 ..
-rwxrwxrwx 1 admin root 6 May 5 01:09 .___var.txt
-rwxrwxrwx 1 admin root 0 May 5 01:09 .___var.txt.6
-rwxrwxrwx 1 admin root 6 May 5 01:09 .__admin_var.txt
-rwxrwxrwx 1 admin root 0 May 5 01:09 .__admin_var.txt.6
-rwxrwxrwx 1 admin root 9 May 5 01:09 .__folder_list.txt
-rwxrwxrwx 1 admin root 0 May 5 01:09 .__folder_list.txt.9
-rwxrwxrwx 1 admin root 91.3M Oct 7 2023 RT-AC68U_386.12_0.zip
drwxrwxrwx 1 admin root 4.0K Oct 7 2023 System Volume Information
admin@RT-AC68U-****:/tmp/mnt/sda# unzip -o "RT-AC68U_386.12_0.zip" -d "/home/root/" -x README*
Archive: RT-AC68U_386.12_0.zip
inflating: RT-AC68U_386.12_0.trx
inflating: Changelog-386.txt
inflating: sha256sum.sha256
admin@RT-AC68U-****:/tmp/mnt/sda# free
total used free shared buffers cached
Mem: 255716 223468 32248 0 912 171484
-/+ buffers/cache: 51072 204644
Swap: 0 0 0
admin@RT-AC68U-****:/tmp/mnt/sda# df -h
Filesystem Size Used Available Use% Mounted on
/dev/root 32.8M 32.8M 0 100% /
devtmpfs 124.8M 0 124.8M 0% /dev
tmpfs 124.9M 94.8M 30.0M 76% /tmp
/dev/mtdblock4 62.8M 1.7M 61.1M 3% /jffs
/dev/sda 7.5G 91.3M 7.4G 1% /tmp/mnt/sda
admin@RT-AC68U-****:/tmp/mnt/sda# cd /home/root/
admin@RT-AC68U-****:/tmp/home/root# ls -lah
drwx------ 3 admin root 140 May 5 01:53 .
drwxr-xr-x 3 admin root 60 Dec 31 1969 ..
-rw------- 1 admin root 130 May 5 01:53 .ash_history
drwx------ 2 admin root 60 May 5 01:05 .ssh
-rw-rw-rw- 1 admin root 91.7K May 5 01:53 Changelog-386.txt
-rw-rw-rw- 1 admin root 93.9M May 5 01:53 RT-AC68U_386.12_0.trx
-rw-rw-rw- 1 admin root 88 May 5 01:53 sha256sum.sha256
admin@RT-AC68U-****:/tmp/home/root# openssl sha256 RT-AC68U_386.12_0.trx
SHA256(RT-AC68U_386.12_0.trx)= a07830f1dd3fa816c25c7b76263cbb13e4268fac3447fe623b048f66067deaf4
admin@RT-AC68U-****:/tmp/home/root# cat sha256sum.sha256
a07830f1dd3fa816c25c7b76263cbb13e4268fac3447fe623b048f66067deaf4 RT-AC68U_386.12_0.trx
admin@RT-AC68U-****:/tmp/home/root# pass="$(echo -n '*********' | openssl base64)"
admin@RT-AC68U-****:/tmp/home/root# curl "http://192.168.50.1/login.cgi" \
> --referer http://192.168.50.1/Main_Login.asp \
> --user-agent 'Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0' \
> -H 'Accept-Language: en-US,en;q=0.5' \
> -H 'Content-Type: application/x-www-form-urlencoded' \
> -H "Origin: http://192.168.50.1/" \
> -H 'Connection: keep-alive' \
> --data-raw "group_id=&action_mode=&action_script=&action_wait=5¤t_page=Main_Login.asp&next_page=index.asp&login_authorization=${pass}" \
> --cookie-jar /tmp/home/root/cookie.txt
<HTML><HEAD>
<meta http-equiv="refresh" content="0; url=index.asp">
</HEAD></HTML>
admin@RT-AC68U-****:/tmp/home/root# nohup curl "http://192.168.50.1/upgrade.cgi" \
> --referer http://192.168.50.1/Advanced_FirmwareUpgrade_Content.asp \
> --user-agent 'Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0' \
> -H 'Accept-Language: en-US,en;q=0.5' \
> -H "Origin: http://192.168.50.1/" \
> -F 'current_page=Advanced_FirmwareUpgrade_Content.asp' \
> -F 'next_page=' \
> -F 'action_mode=' \
> -F 'action_script=' \
> -F 'action_wait=' \
> -F 'preferred_lang=EN' \
> -F 'firmver=3.0.0.4' \
> -F "file=@/tmp/home/root/RT-AC68U_386.12_0.trx" \
> --cookie /tmp/home/root/cookie.txt > /jffs/upload_response.txt 2>&1 &
#############
After reboot
#############
admin@RT-AC68U-****:/jffs# cat upload_response.txt
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 93.8M 0 1735 100 93.8M 78 4350k 0:00:22 0:00:22 --:--:-- 4664k
<html>
<head>
<title>ASUS Wireless Router Web Manager</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta HTTP-EQUIV="Pragma" CONTENT="no-cache">
<meta HTTP-EQUIV="Expires" CONTENT="-1">
<link rel="shortcut icon" href="images/favicon.png">
<link rel="icon" href="images/favicon.png">
</head>
<body>
<script>
var reboottime = eval("140");
var upgrade_fw_status = '4';
if(upgrade_fw_status == 2 || upgrade_fw_status == 4){
parent.document.getElementById("hiddenMask").style.visibility = "hidden";
parent.document.getElementById('loading_block2').innerHTML = "Firmware upgrade unsuccessful. This may result from incorrect image or error transmission. Please check the version of firmware and try again.";
parent.document.getElementById('loading_block3').style.display = "none";
parent.showLoadingBar(reboottime);
setTimeout("parent.detect_httpd();", reboottime*1000);
}
else if(upgrade_fw_status == 6){
parent.document.getElementById("hiddenMask").style.visibility = "hidden";
parent.document.getElementById('loading_block2').innerHTML = "To comply with regulatory amendments, we have modified our certificate rule to ensure better firmware quality. This version is not compatible with all previously released ASUS firmware and uncertified third party firmware. Please check our official websites for the certified firmware.";
parent.document.getElementById('loading_block3').style.display = "none";
parent.showLoadingBar(reboottime);
setTimeout("parent.detect_httpd();", reboottime*1000);
}
else{
aler("Firmware upgrade unsuccessful. This may result from incorrect image or error transmission. Please check the version of firmware and try again.");
parent.location.reload();
}
</script>
</body>
</html>ExtremeFiretop
Very Senior Member
Right.. But any change to the GUI would just fail on the curl request and we would update the curl request. It wouldn't be dangerous. It would just fail like a failed http web request. I don't know many failed web requests that are "dangerous" do you? Usually the page just refreshes or times out? etc?
So the safety argument doesn't hold much fruit here anymore too the remaining testing this.
If something failed with old hnd-write, then you had a more serious concern. This method is easy to work with, since we are just scripting the Web GUI process and still invoking all the same safety measures as the GUI normally does.
ExtremeFiretop
Very Senior Member
Yessir that is a successful update it seems!
So can we narrow down the original cause of your storage issues?
ExtremeFiretop
Very Senior Member
Keep in mind that 386.7 is below our hard coded check for 386.11, so if this is a firmware bug as you suspect, the script wouldn't encounter this, you did running the commands manually to test the update on 386.7
Yota
Very Senior Member
Yes, I would downgrade to 386.7 and see what's going on, and upgrade the firmware one by one to see in which version the issue is fixed.
In the meantime, I was looking at the changelog and didn't see anything special, the only interesting thing was a bug fix for 386.7_2:
Code:
- FIXED: Some SSH clients would end up with an incorrect PATH
value for the default search path.Not sure if relevant, further testing will be done.
If you have time, would you mind trying to understand the specific symptoms of the SSH issue fixed by 386.7_2 while I'm testing it?
You can find it in this thread, thank you.
EDIT:
Okay, sorry, gotta work now, I'll test it later, or if it's too late I might have to wait until tomorrow. But those previous tests were not random results, but the same results for multiple tests.
Last edited:
Yota
Very Senior Member
Yes, while this error may not affect us, I would like to know more about it to ensure we know how to respond if something like this happens in the future.
Viktor Jaep
Part of the Furniture
Incoming curl patches hopefully very soon to shore up some critical bugs...
www.securityweek.com
Patches Prepared for 'Probably Worst' cURL Vulnerability
A high-severity vulnerability in the data transfer project cURL will be addressed with libcurl and curl updates this week.
- Status
Similar threads
Similar threads
| Thread starter | Title | Forum | Replies | Date |
|---|---|---|---|---|
| F | seeking help with bridge mode | Asuswrt-Merlin | 28 |
Similar threads
Latest threads
-
RT-AX86U Pro limiting upload speed.
- Started by Sintek
- Replies: 1
-
-
WireGuard starts failing, anyone else with 3004.388.8_2?
- Started by meruserasus
- Replies: 4
-
-
RT-AX86U Pro / ASUS RT-BE86U question
- Started by freddyjuarez
- Replies: 1
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!
Staff online
-
RMerlinAsuswrt-Merlin dev