Seeking Feedback & Contributions: Merlin Auto Update Solutions

[glens]

No, I'm not suggesting my method is the only right method, nor that there are no benefits (as I already alluded to) in having routers be on a semi-current version either.

Just trying to make clear my perspective and the logic behind it.

To me, it is perplexing why anyone would want to have this script installed. Because, as you said, a higher level of user is required to even know about this script on firsthand. But that may just be me. I know it takes all kinds to make the world turn, but if I didn't believe I was 'right', I'm not true to myself, and others.

Kudos

 

[glens]

Yota, I haven't fleshed it out any at all (apologize here and now for not yet having fetched your script), but the notion occupied some of my internal "fronthaul" recently that you could possibly do some more with the script, succeeding the curl upload directive, by inserting as the first line of code

nohup bash -c "

and closing with

" &

Or " ' "s instead (ref. above apology). Whichever, may require "escaping" things...

Naturally, you could then drop curl's "nohup" (and let it block by staying in the foreground too?).

May allow continued operation until the reboot...

 

[Yota]

Yota, I haven't fleshed it out any at all

No, you don't have to apologize, in fact I'm happy to help you understand, that's the purpose of this whole project, to open it up so more people can get involved, contribute their ideas and make it grow, if there's anything there I can explain further please tell me.

your script

In fact, I haven't contributed any code to this project so far. Hahaha. Strictly, most of the script was written by the OP.

Or " ' "s instead (ref. above apology). Whichever, may require "escaping" things...

Naturally, you could then drop curl's "nohup" (and let it block by staying in the foreground too?).

May allow continued operation until the reboot...

This is a good idea! That's exactly what this project needs, join in with ideas and suggestions, build it together!

I'm not sure sh will run in the background though, since the nohup bug that can't run scripts in the background has been going on for at least 5 years. On Asuswrt, sh/bash is linked to busybox, and nohup is also a small program of busybox. This may be the reason why it does not work.

But it does require further testing.

It's a good idea anyway! Thanks!

 

[glens]

I'm not sure sh will run in the background though, since the nohup bug that can't run scripts in the background has been going on for at least 5 years. On Asuswrt, sh/bash is linked to busybox, and nohup is also a small program of busybox. This may be the reason why it does not work.

Huh? If one thing will run in the background from within a script, with nohup, another should all the same. What I proposed wouldn't be THE SCRIPT ITSELF running background nohup, but a command called from within. Much the same as with curl.

I've got an NAD amplifier with DLNA/Chromecast on a module built in. I can telnet in to it, but the "interactive shell" really isn't. If I want to approach decent usability I've got to

mksh -c "...."

stuff.

There, mksh is a standalone executable while what/how-ever telnet is calling is a busybox sh. I don't get the feeling that's the reason it doesn't work "right", rather the way the "interactive" "shell" is parented. Maybe that doesn't make proper sense, but I've a gut feeling what I suggested above will work admirably.

 

[glens]

In fact, I haven't contributed any code to this project so far. Hahaha. Strictly, most of the script was written by the OP.

I know that... Can't figure how I'd addressed YOU as the OP except maybe I'd slept since. Hahaha

 

[sfx2000]

In the sense of open debate - automatic FW updates have a lot of history over in Carrier Space as managed platforms...

A couple of approaches below

AVSystem - Shaping the world of connected devices

AVSystem is an expert in large scale device management and monitoring systems for Telcos, ICT service providers and device manufacturers.

www.avsystem.com

This is mostly directed towards the TR-069 ACS space from Broadband forum - it's a mature specification and the methods are well thought out and proven...

Another view is from the Lightweight M2M groups...

Remote Firmware Updates for IoT Devices using LwM2M and Zephyr RTOS - Zephyr Project

www.zephyrproject.org

Again, many of the concepts are similar - security, robustness...

Any automagic firmware update needs to be QA'ed - not just for the core code functionality, but also for the upgrade and fallback procedures...

we've discussed what to do if there's a significant change that could result in a factory reset - which isn't good, and should never happen in proper firmware, unless there is a script that would only do the appropriate userdata changes...

It's also the fallback if the upgrade fails - you cannot leave the device in an unknown state for a couple of reasons - first being it's not your device, and second being that the end-user needs this for internet access - if you leave the device in a bad state, this is very much a negative end-user and paying customer (in this case, paying to Asus).

Again - it's fun to explore, but when it comes to actually deploying - beware of dragons out there...

 

[glens]

... Might have to call ' busybox sh -c "..." ' instead, but I don't think that'd be functionally different since busybox itself behaves according to how (which name) it was invoked.

 

[glens]

Again - it's fun to explore, but when it comes to actually deploying - beware of dragons out there...

I hate dragons, which is why for this very specific task I prefer being present and available.

 

[ExtremeFiretop]

Testing confirmed that even for extreme models such as the RT-AC68U, automatic updates work smoothly with the aid of a USB drive.

The firmware of RT-AC68U consists of two files, and the appropriate version will be selected when updating, so its firmware has a size of more than 90MB, and its RAM is only 256MB, leaving us with /tmp space, as you said, just half the RAM, only 128MB. It is impossible to download the zip in /tmp of RT-AC68U and unzip the firmware in place. For such an extreme model, a USB drive must be used to complete the automatic update.

In previous testing, since it was not filled (93MB/128MB), but the error was triggered, filled it just to reproduce the error.

This is good information to know, we can start to work on a USB implementation where the firmware isn't downloaded and extracted all in-place in the same directory.

As for new Implementations, I've implemented the LED controller, basic memory management and some cleanup. So far it's actually mostly been lots of cleanup. .. But it was required. (Thanks Martinski for all the help, where ever you are)

What would be the suggested logic for those models?
Can we download the .zip directly to the the USB? And Unzip to temp?

Or would we need to break it down much more you think?
Something like:

1. Download .zip to tmp,
2. Copy zip to USB,
3. Delete zip from temp
4. Then extract from USB to temp?

Will experiment a bit and report back, I have a feeling the steps will need to be broken down for a router shell with limited resources anyways.

 

[Yota]

Can we download the .zip directly to the the USB? And Unzip to temp?

Since the script has root access to the USB drive, yes we should have no problem downloading the zip from SF to the USB drive. Then extract it to /tmp. Then flash it.

Will experiment a bit and report back, I have a feeling the steps will need to be broken down for a router shell with limited resources anyways.

For models where /tmp free space is less than firmware size + zip size, one must rely on the USB drive as there is no extra space there for unzip the firmware.

As far as I know, currently only RT-AC68U will experience insufficient /tmp available space. But we have to assume that if there are other scripts filling /tmp it may cause the firmware to fail to download or be unzip in /tmp. So the script may have to perform a check of /tmp free space.

 

[Yota]

it's a mature specification and the methods are well thought out and proven...

Regarding the auto-update aspect, I don't know about anyone else, but I must admit I don't have any experience with it.

I had some ideas and mitigations for foreseeable problems, but I knew it wasn't enough. A reliable auto-update solution had to be extensively tested, and even for a company like Asus with a well-established testing process, they screwed up once too.

However, I'm not afraid of failure, in fact I'm hoping that experienced people can share their experiences and help with this project, that's how I came to this thread, I saw that the OP was having some trouble and I had some ideas that I shared with OP and hope these ideas will help this project.

I read the two links you shared and there are indeed some interesting ideas there, but I think it's more of a promotional brochure of some kind and not designed to teach people how to design a reliable automatic update process. If you have relevant experience, why not try to share it? You can help this project avoid mistakes that professionals like you might consider silly.

I know you may have a contract with your employer that prohibits you from contributing code, and I haven't shared a single line of code for this project yet, but I do think I'm helping the project in some way. So, you can too.

We can join OP to improve it together, after all, success without failure is no fun. In the early days of this project, I figured only developers who enjoyed failing would use it, so don't worry, we wouldn't force anyone to brick their routers.

So how about join us and find out how to deal with dragons?

 

[Yota]

we've discussed what to do if there's a significant change that could result in a factory reset - which isn't good, and should never happen in proper firmware, unless there is a script that would only do the appropriate userdata changes...

To be honest, I can't even remember when was the last time I did a factory default reset on one of my routers... Personally I just flash new firmware on top of it, and everything keeps working just fine.

RMerlin has stated many times that factory reset after updating is unnecessary unless you jump to multiple versions. In my opinion, this is just a suggested action for this forum to troubleshoot, and is unnecessary if there are no user-perceivable problems there.

If there is a user-perceivable problem, I'm sure they will come here and do it the suggested way.

There is also only a very, very small chance that users will be required to factory reset after updating new firmware, and if that were the case, I think the blocklist I mentioned earlier would be a mitigation.

 

[Yota]

After many tests, here is my understanding of the "No space left on device" crash on RT-AC68U:


Affected models: Asus RT-AC68U, RT-AC1900P and RT-AC66U_B1
Affected firmware: 386.7_2 and earlier versions
Fixed firmware: 386.9
Tested firmware: 386.7 to 386.12


Test environment:
One RT-AC68U
Restore factory settings every time when testing, only turn off wifi and turn on SSH, no other settings.


Problem Description:
The RT-AC68U series models have 256MB of RAM, like most models, 50% of the RAM is dynamically divided into /tmp storage, so there should be 128MB of /tmp storage space on the RT-AC68U.

Although /tmp reports more than 120MB free space before uploading, it returns "No space left on device" error after uploading or writing more than 90MB files to /tmp, after which the shell crashes and a GUI (httpd) crash is observed.

Crash manifests itself in the following two situations:
1) Entering any command in SSH will return "-sh: can't fork" and the command will not be executed,
2) Sometimes the GUI can be logged in, but in some tests it cannot be logged in. The browser reports that the website is damaged or currently unavailable. In cases where the GUI can be successfully logged in, the CPU, RAM and other information on the website map cannot be loaded, but the reboot button works.


Steps to reproduce:
On 386.7 and 386.7_2 firmware (earlier versions not tested yet) you can reproduce this way:
1) Use scp to upload files larger than 90MB to the /tmp directory of the router
2) It can be observed that the "No space left on device" error is returned during the upload process
3) Log into SSH (if this is possible at this time)
4) Entering any command will return "-sh: can't fork"

Or use this method:
1) Copy files larger than 90MB to a USB drive and plug the drive into the RT-AC68U USB port
2) Log in to SSH and use the cp command to copy the file to the /tmp directory
3) "No space left on device" error will be returned during the copy process
4) After returning this error, entering any command will return "-sh: can't fork".


Problem causes:
Unknown
Checked RMerlin's change log, and checked Asuswrt's change log, there is no information mentioning that this error is fixed. What is currently known is that the error does not affect Asuswrt-Merlin 386.9 and Asuswrt 386_50757 versions and above.


Influence level:
High. It will affect the normal operation of the router.
This error can only be fixed by rebooting the router (freeing up RAM) since rm and any delete commands cannot be executed. If passed through a script, note that the reboot command will also fail, in which case the user will be required to perform a cold reboot via the power button.
Please note that wifi and internet access were not tested in the test.


Mitigation measures:
When the error occurs, reboot the router. As mentioned above, the reboot command may not be available, but the GUI reboot button will be available, It's worth pointing out that the GUI itself is not always available.
Or:
Update to 386.9 and later versions. 386.9 to 386.12 (the latest versions so far) have fixed this error.


Some screenshots:

Screenshot of unsuccessful login to the router via SSH after the "No space left on device" occurred.

In another test, no commands could be executed after successfully logging in via SSH.


For more information see earlier tests:
https://www.snbforums.com/threads/s...ns-merlin-auto-update-solutions.87044/page-12



References:
https://www.downtowndougbrown.com/2023/05/what-happened-with-asus-routers-this-morning/
https://www.snbforums.com/threads/router-lockup-cant-fork-on-command-line.32097/

https://www.reddit.com/r/ASUS/comments/13k3wil/_/jkisbml

 

[glens]

High five for the effort!

 

[glens]

Is there enough room to fetch the zip file, "unzip -l" it, choose which (only) image to extract, rm the zip file, and proceed?

case `nvram get productid` in
      whatever|list|of|common|targets) ... ;;
      whatever-else-specific) ... ;;
      *) ... everyone-else ;;
esac

 

[Yota]

Is there enough room to fetch the zip file, "unzip -l" it, choose which (only) image to extract, rm the zip file, and proceed?

Don't understand the context of your question.

If you are referring to what the script does on most models, yes, in fact most models have 512MB or more of RAM, their /tmp effective space is at least 250MB, and firmware and zip combined usually don't It will be over 200MB, so there is plenty of space without deleting it.

For a model like the RT-AC68U, it only has 128MB of /tmp, and the zip file itself is over 90MB, so there's no extra space for unzip. Such a model must adopt the approach discussed in #269 and #270: a USB drive will be required.

If your context is about the above error (#273), no, it is simply not possible to upload/download/copy a 93MB zip to the router, even if there is plenty of space there. there is no solution for that error other than updating the firmware. since it's a error in the firmware, the effort to fix it is not part of this project, I'm just trying to understand it and try to provide more experience for the future if something like this happens.

 

[Yota]

Today I wanted to test out a full update process. From downloading the firmware from SourceForge to the update is complete. but I never updated successfully.

After rebooting the router, the firmware version is still 386.11 before the upgrade (In the previous post, I said it was successful, which was a misjudgment. At that time, the firmware was 386.12, and I tried to update to 386.12, and it would reboot, so I mistakenly thought it was updated successfully).

I used these commands to update, please check them for errors:

1) USB drive is in place
2) Download firmware from SourceForge

curl -fvL --output-dir "/tmp/mnt/sda/" -O "https://deac-ams.dl.sourceforge.net/project/asuswrt-merlin/RT-AC68U/Release/RT-AC68U_386.12_0.zip"

3) Unzip to /tmp

unzip -o "/tmp/mnt/sda/RT-AC68U_386.12_0.zip" -d "/tmp/home/root/" -x README*

4) Check hash
5) Save the cookie

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&current_page=Main_Login.asp&next_page=index.asp&login_authorization=${pass}" \
--cookie-jar /tmp/home/root/cookie.txt

5) To flash it

nohup curl -fvL "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 &

None of the above commands have any error output, I tested it 5 times and I don't understand why it can't be updated, maybe there is a lack of RAM? Because the /tmp partition only has 30MB available.

# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                33.4M     33.4M         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.0M   3% /jffs
/dev/sda                  7.5G     91.3M      7.4G   1% /tmp/mnt/sda

This is the output of /jffs/upload_response.txt, I have curl's verbose logging enabled to try to understand what is going on:

Spoiler

# cat /jffs/upload_response.txt
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 192.168.50.1:80...
* Connected to 192.168.50.1 (192.168.50.1) port 80 (#0)
> POST /upgrade.cgi HTTP/1.1
> Host: 192.168.50.1
> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0
> Accept: */*
> Referer: http://192.168.50.1/Advanced_FirmwareUpgrade_Content.asp
> Cookie: asus_token=****************************
> Accept-Language: en-US,en;q=0.5
> Origin: http://192.168.50.1/
> Content-Length: 98448338
> Content-Type: multipart/form-data; boundary=------------------------f5646cae0766d4c2
> Expect: 100-continue
>
* Done waiting for 100-continue
  0 93.8M    0     0    0     0      0      0 --:--:--  0:00:01 --:--:--     0} [65536 bytes data]
 95 93.8M    0     0   95 89.3M      0  4421k  0:00:21  0:00:20  0:00:01 5841k* We are completely uploaded and fine
* HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
< Server: httpd/2.0
< x-frame-options: SAMEORIGIN
< x-xss-protection: 1; mode=block
< Date: Thu, 12 Oct 2023 09:04:05 GMT
< Cache-Control: no-cache, no-store, must-revalidate
< Pragma: no-cache
< Expires: 0
< Content-Type: text/html
< Connection: close
<
{ [367 bytes data]
100 93.8M    0  1735  100 93.8M     77  4292k  0:00:22  0:00:22 --:--:-- 4726k
* Closing connection 0
<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>

The only thing that caught my attention was the update status returned by the GUI:
var upgrade_fw_status = '4';
And 4 equals update failure:

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);
}

There are no errors in the system log and it looks quite normal. I again suspect it is a RAM problem, assuming that the firmware is also cached in /tmp after being uploaded from the GUI to the router. As we know, /tmp only has 30MB of space and cannot store firmware.

By observing the GUI update process, I found that after uploading 93MB of firmware, it will immediately start splitting the firmware. In fact, only 33MB of firmware is stored on /tmp (because this is the actual size of the firmware of my RT-AC68U, the other parts belong to RT-AC68Uv4), but my /tmp cannot store files exceeding 30MB, so maybe this is Is it the reason?

Any ideas?

 

[glens]

How much space available in jffs?

 

[Yota]

How much space available in jffs?

# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                33.4M     33.4M         0 100% /
devtmpfs                124.8M         0    124.8M   0% /dev
tmpfs                   124.9M    500.0K    124.4M   0% /tmp
/dev/mtdblock4           62.8M      1.7M     61.1M   3% /jffs

There's not enough space to store the 2-in-1 RT-AC68U firmware (93MB), but there's enough to store the RT-AC68U firmware split in half (but splitting it is a long story and requires reverse engineering).

 

[Yota]

I just realized that /dev is also RAM and is writable. Let's try to see if the firmware can be upgraded successfully by placing it there.

mkdir /dev/auto-update
unzip -o "/tmp/mnt/sda/RT-AC68U_386.12_0.zip" -d "/dev/auto-update" -x README*

# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                33.4M     33.4M         0 100% /
devtmpfs                124.8M     94.1M     30.7M  75% /dev
tmpfs                   124.9M    744.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

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&current_page=Main_Login.asp&next_page=index.asp&login_authorization=${pass}" \
--cookie-jar /tmp/home/root/cookie.txt

nohup curl -fvL "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=@/dev/auto-update/RT-AC68U_386.12_0.trx" \
--cookie /tmp/home/root/cookie.txt > /jffs/upload_response.txt 2>&1 &

EDIT:
No luck, not even uploading successfully. But the router did reboot.

Spoiler

# cat /jffs/upload_response.txt
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 192.168.50.1:80...
* Connected to 192.168.50.1 (192.168.50.1) port 80 (#0)
> POST /upgrade.cgi HTTP/1.1
> Host: 192.168.50.1
> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0
> Accept: */*
> Referer: http://192.168.50.1/Advanced_FirmwareUpgrade_Content.asp
> Cookie: asus_token=****************************
> Accept-Language: en-US,en;q=0.5
> Origin: http://192.168.50.1/
> Content-Length: 98448338
> Content-Type: multipart/form-data; boundary=------------------------85420e7a9428aa76
> Expect: 100-continue
>
* Done waiting for 100-continue
  0 93.8M    0     0    0     0      0      0 --:--:--  0:00:01 --:--:--     0} [65536 bytes data]
 95 93.8M    0     0   95 89.9M      0  4500k  0:00:21  0:00:20  0:00:01 5912k* We are completely uploaded and fine
100 93.8M    0     0  100 93.8M      0  4339k  0:00:22  0:00:22 --:--:-- 4864k* HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
< Server: httpd/2.0
< x-frame-options: SAMEORIGIN
< x-xss-protection: 1; mode=block
< Date: Thu, 12 Oct 2023 10:16:24 GMT
< Cache-Control: no-cache, no-store, must-revalidate
< Pragma: no-cache
< Expires: 0
< Content-Type: text/html
< Connection: close
<
{ [367 bytes data]
100 93.8M    0   962  100 93.8M     42  4240k  0:00:22  0:00:22 --:--:-- 3775k
* Closing connection 0

EDIT 2:
The second test returned something different:

Spoiler

# cat /jffs/upload_response.txt
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 192.168.50.1:80...
* Connected to 192.168.50.1 (192.168.50.1) port 80 (#0)
> POST /upgrade.cgi HTTP/1.1
> Host: 192.168.50.1
> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0
> Accept: */*
> Referer: http://192.168.50.1/Advanced_FirmwareUpgrade_Content.asp
> Cookie: asus_token=***************************
> Accept-Language: en-US,en;q=0.5
> Origin: http://192.168.50.1/
> Content-Length: 98448338
> Content-Type: multipart/form-data; boundary=------------------------778b2b23e1d38cc3
> Expect: 100-continue
>
  0 93.8M    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* Done waiting for 100-continue
} [65536 bytes data]
 96 93.8M    0     0   96 90.6M      0  4625k  0:00:20  0:00:20 --:--:-- 5683k* We are completely uploaded and fine
100 93.8M    0     0  100 93.8M      0  4441k  0:00:21  0:00:21 --:--:-- 4766k* HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
< Server: httpd/2.0
< x-frame-options: SAMEORIGIN
< x-xss-protection: 1; mode=block
< Date: Thu, 12 Oct 2023 10:22:18 GMT
< Cache-Control: no-cache, no-store, must-revalidate
< Pragma: no-cache
< Expires: 0
< Content-Type: text/html
< Connection: close
<
{ [367 bytes data]
100 93.8M    0   962  100 93.8M     43  4354k  0:00:22  0:00:22 --:--:-- 3759k
* Closing connection 0
<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 knv = "2.6.36.4brcmarm";
var knv_threshold = (parseInt(knv[0])=="")?0:parseInt(knv[0]);
var reboot_needed_time = eval("140");
parent.document.getElementById("hiddenMask").style.visibility = "hidden";
if(parent.Bcmwifi_support && knv_threshold >= 4){
reboot_needed_time += 40;
parent.showLoadingBar(reboot_needed_time);
setTimeout("parent.detect_httpd();", (reboot_needed_time+2)*1000);
}
else if(parent.based_modelid == "RT-N11P"){
parent.showLoadingBar(160);
setTimeout("parent.detect_httpd();", 162000);
}
else{
parent.showLoadingBar(270);
setTimeout("parent.detect_httpd();", 272000);
}
</script>
</body>
</html>

However, the test results are the same. It is observed that the router reboots. After the reboot, it is not updated to 386.12, and the firmware version is still 386.11.


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.