What's new

Asus branded RT-AC68U. Installed latest firmware (386.10) and after rebooting it doesn't accept my credentials via web interface or SSH

  • 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!

My RT-AC68U

New Around Here
After the update I lost access but the router appears to operate normally.

I used the 5 second reset button option and reloaded a saved configuration file and I regained access.
After modifying a few settings I ignored the update prompt but when I rebooted it it re-installed the update.
This seems like an NVRAM capacity issue.

How can I prevent the firmware update from running again once I repeat the steps above?

Thanks.
 
After the update I lost access but the router appears to operate normally.

I used the 5 second reset button option and reloaded a saved configuration file and I regained access.
After modifying a few settings I ignored the update prompt but when I rebooted it it re-installed the update.
This seems like an NVRAM capacity issue.

How can I prevent the firmware update from running again once I repeat the steps above?

Thanks.

If you're still running 386.10 factory reset with WPS button and reconfigure from scratch by hand, not from a backup.

It should not auto update firmware. My guess is you just got corrupted again after rebooting since you restored a backup.

If you didn't downgrade the firmware you're still on 386.10.
 
If you're still running 386.10 factory reset with WPS button and reconfigure from scratch by hand, not from a backup.

It should not auto update firmware. My guess is you just got corrupted again after rebooting since you restored a backup.
After resetting it goes back to 386.9 which is the same version under which I saved the config file.
I was able to disable auto update but getting the low on NVRAM space message again.
So I ran my NVRAM cleaning script and I am good to go.
 
After resetting it goes back to 386.9 which is the same version under which I saved the config file.
I was able to disable auto update but getting the low on NVRAM space message again.
So I ran my NVRAM cleaning script and I am good to go.

386.9 and 386.10 both require factory reset and configure from scratch on the 68U. Even then NVRAM is very limited (most of the stuff cleaned by the script comes back when you reboot) so you can't have too many static DHCP, custom client names, VPN profiles, etc. I'd stick with 386.7_2 unless you have a specific need for something introduced in 9 or 10.

If you didn't specifically downgrade to 386.9 that means the upgrade failed, you never had 386.10, not completely anyway. Resetting does not change the firmware version. In fact at this point who knows what state it is in, re-flash firmware (like I said, probably 386.7_2) and then factory reset using WPS button and completely reconfigure by hand. In fact to make sure the flash completes properly I'd factory reset before doing it too, then just configure enough to get in and do the flash, then when it completes reset again.

But considering you've posted in the Merlin forum, and Merlin does not support auto update, I'm a bit confused, where did you disable auto update?
 
386.9 and 386.10 both require factory reset and configure from scratch on the 68U. Even then NVRAM is very limited (most of the stuff cleaned by the script comes back when you reboot) so you can't have too many static DHCP, custom client names, VPN profiles, etc. I'd stick with 386.7_2 unless you have a specific need for something introduced in 9 or 10.

If you didn't specifically downgrade to 386.9 that means the upgrade failed, you never had 386.10, not completely anyway. Resetting does not change the firmware version. In fact at this point who knows what state it is in, re-flash firmware (like I said, probably 386.7_2) and then factory reset using WPS button and completely reconfigure by hand. In fact to make sure the flash completes properly I'd factory reset before doing it too, then just configure enough to get in and do the flash, then when it completes reset again.

But considering you've posted in the Merlin forum, and Merlin does not support auto update, I'm a bit confused, where did you disable auto update?
I spoke too soon. When rebooting it goes through the upgrade process again.

I installed the update by clicking the notification bell, same place where NVRAM notifications show, then clicking the link to upgrade/update
Been running 386.9 since Jan 18 without problems.
The radio button is for automatic update CHECK not auto install, I misspoke.

Would the system allow me to re-up 386.9 without having to reset everything?
 
I spoke too soon. When rebooting it goes through the upgrade process again.

I installed the update by clicking the notification bell, same place where NVRAM notifications show, then clicking the link to upgrade/update
Been running 386.9 since Jan 18 without problems.
The radio button is for automatic update CHECK not auto install, I misspoke.

Would the system allow me to re-up 386.9 without having to reset everything?

Sounds like you're stuck in upgrade loop and it is failing. If your backup was from 386.9 and that was working fine, then do a factory reset, let it finish its upgrade to 386.10 (if it still tries), then re-flash 386.9, factory reset again, and restore your backup.
 
I think my loss of access issue is due to modifications made to the NVRAM.
The script I have created removes all variables with no set value but this doesn't seem to be working for ASUS stock firmware either as I keep getting locked out, can't even use SSH key with puTTY
Is there another way to "optimize" the NVRAM?

This is my script:

Bash:
nvram show > /tmp/nvram_before.txt
infile="/tmp/nvram_before.txt"
outfile="/tmp/nvram_unset.txt"
> "$outfile"
grep -E '^[^#]*[[:space:]]*=[[:space:]]*$' "$infile" | while read -r line; do
    var=$(echo "$line" | awk -F'=' '{print $1}')
    echo "nvram unset $var" >> "$outfile"
done
echo "nvram commit" >> "$outfile"
while read -r command; do
    if [[ $command == \#* ]] || [[ -z "$command" ]]; then
        continue
    fi
    echo "Executing: $command"
    eval "$command"
done < "$outfile"
echo "Finished executing commands from: $outfile"
rm "$infile" "$outfile"
echo "Deleted input and output files: $infile $outfile"
 
Is there another way to "optimize" the NVRAM?
Use the forum search to find the other recent threads discussing various methods for dealing with the NVRAM on the RT-AC68U. For example this discussion. Most of the code and scripts for clearing NVRAM don't survive reboot and may introduce other issues. The first step should be a hard factory reset followed by manual reconfiguration without importing or loading a saved router cfg file.
 
Solved this issue by selectively unsetting certain variables, mainly wlan and vpn related, instead of indiscriminately running the script.
I still think this router model, while wildly popular, may have run its course.
I am now running 386.10
 
Solved this issue by selectively unsetting certain variables, mainly wlan and vpn related, instead of indiscriminately running the script.
I still think this router model, while wildly popular, may have run its course.
I am now running 386.10

That's been confirmed by Asus and @RMerlin - this router is end of support. Unless there is some pressing need like a vulnerability, I see no reason to go beyond 386.7_2.
 
It's not. I already know Asus' timetable for their next firmware release for it.

Maybe EOS is the wrong term but you did confirm it won't be getting 388 and is no longer under development, so the assumption is security and major bug fixes only? EOS can't be that far away regardless though?

Is Asus aware of the NVRAM issues that these releases are causing on those routers, do they plan to clean up some unused variables?
 
Is Asus aware of the NVRAM issues that these releases are causing on those routers
The issue is specific to Asuswrt-Merlin, which uses a lot more nvram due to supporting 5 OpenVPN clients, DNS Director, SNMP, Tor, and so on.
 
The issue is specific to Asuswrt-Merlin, which uses a lot more nvram due to supporting 5 OpenVPN clients, DNS Director, SNMP, Tor, and so on.

Ah, yeah I remember you mentioning possibly a "lite version". But obviously their code increased NVRAM usage, as 386.7_2 Merlin doesn't have any issues....
 
this router is end of support.
According to who? Asus only has the RT-AC68U_V4 as end of life. Asus recently (2023/03/02) released new stock firmware 3.0.0.4.386.51255 for the RT-AC68U.

Asus will eventually End of Life the wildly popular RT-AC68U but haven't appear to have officially done so yet.

Edit to add: RT-AC68U with 386.10 working fine (knock on wood) after doing a hard factory reset and manually configuring the router plus using YazDHCP for offloading manual DHCP IP reservations. YMMV and all that.

RMerlin recent comments on the NVRAM issue(s) in past posts, here are a few of them:
https://www.snbforums.com/threads/a...t-ac68u-and-rt-ac86u.82209/page-2#post-808313
https://www.snbforums.com/threads/d...uce-high-nvram-usage.84015/page-2#post-832743
https://www.snbforums.com/threads/d...uce-high-nvram-usage.84015/page-2#post-832764
And on future 386.x code base support:
https://www.snbforums.com/threads/a...ilable-for-all-supported-wifi-6-models.82084/
388.1 Release notes
This code base is only available for AX models, AC models will stay on the 386.x code base. Asus hasn't added any of these to their End-of-Life list as of now, so that means they will still get updates, just not as frequently. Most of these models being 5-7 years old now, having reduced support isn't unreasonable (as opposed to competitors typically completely dropping ALL support within 2-4 years). On my end, I currently don't plan to drop support for these AC models for the time being, but as with upstream updates, these older models will get less frequent updates from me as well.
 
Last edited:
According to who? Asus only has the RT-AC68U_V4 as end of life. Asus recently (2023/03/02) released new stock firmware 3.0.0.4.386.51255 for the RT-AC68U.

Asus will eventually End of Life the wildly popular RT-AC68U but haven't appear to have officially done so yet.

Edit to add: RT-AC68U with 386.10 working fine (knock on wood) after doing a hard factory reset and manually configuring the router plus using YazDHCP for offloading manual DHCP IP reservations. YMMV and all that.

RMerlin recent comments on the NVRAM issue(s) in past posts, here are a few of them:
https://www.snbforums.com/threads/a...t-ac68u-and-rt-ac86u.82209/page-2#post-808313
https://www.snbforums.com/threads/d...uce-high-nvram-usage.84015/page-2#post-832743
https://www.snbforums.com/threads/d...uce-high-nvram-usage.84015/page-2#post-832764
And on future 386.x code base support:
https://www.snbforums.com/threads/a...ilable-for-all-supported-wifi-6-models.82084/

I think no 388 code and declaring at least one revision of it EOL is basically writing on the wall. I would not expect any new features etc. I mean, they haven't even released manuals for their new routers so I'm not expecting official EOL notices for every model they aren't actively developing anymore.
 

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