What's new
  • 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!

Status
Not open for further replies.
I think the real win from this endeavor will be to prove that we can interact with the GUI-only features via script and imagine new features from there. iOS shortcuts, PowerShell scripts, shell scripts, or even an unofficial Merlin app.
 
I think the real win from this endeavor will be to prove that we can interact with the GUI-only features via script and imagine new features from there. iOS shortcuts, PowerShell scripts, shell scripts, or even an unofficial Merlin app.

1696771502449.png


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:
Start by unzipping at your computer, and copy it via SCP to home/root. The same way you did with the zip the first time successfully. Make sure there is no zip, if there is delete it first.
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.

0.PNG


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:

1.PNG

3.PNG

4.PNG


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.

The different between the two in size is negligible (91MB vs 93MB)
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.


Put the firmware file as the only file in home/root and test the curl commands manually?
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:
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.

View attachment 53537

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:

View attachment 53538

View attachment 53540
View attachment 53541

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.

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?
 
Can you confirm the .zip still works via SCP? if not maybe the router needs a full reset to test again.
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.

6.PNG


Of course, the update ended normally without any errors.
 
After updating to 386.12, before I did a factory reset, I then tested uploading the same .zip to the router, and this time it worked. I will restore the settings next and conduct more tests. I cannot rule out that this is a bug of 386.7.

7.PNG
 
After updating to 386.12, before I did a factory reset, I then tested uploading the same .zip to the router, and this time it worked. I will restore the settings next and conduct more tests. I cannot rule out that this is a bug of 386.7.

View attachment 53543

Very good discovery, please keep me/us informed as you re-run the tests on the newer firmware
 
Very good discovery, please keep me/us informed as you re-run the tests on the newer firmware
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.

7.PNG


This is the memory status of uploading firmware to /tmp/home/root.
8.PNG


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.
 
I hope I can reproduce the error.
The strangest thing happened. Despite insufficient /tmp storage space, I still cannot reproduce the error that occurred on 386.7.

9.PNG


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.

10.PNG


"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.

11.png

12.png



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:
There is a lot of overreaction in this thread. I may be under reacting myself, but where is the forum’s sense of adventure and “let’s try it” mentality?

Does anyone wonder why it gets so dull around here these days? Not many people want to take risks or have fun trying new things.

Odds are very high that this project will die for one valid reason or another. But “not trying” shouldn’t be one of them.
So so so agreed with every single line.
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.
 
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).
 
This method will never be as 'safe' as if doing it via the GUI.

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.
 
Yes, you're proving the point.
 
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:

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&current_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>
 
Yes, you're proving the point.

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.
 
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:

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&current_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>

Yessir that is a successful update it seems!

So can we narrow down the original cause of your storage issues?
 
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.

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
 
So can we narrow down the original cause of your storage issues?
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:
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
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.
 
Status
Not open for further replies.
Similar threads

Similar threads

Latest threads

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