What's new

[solved] AC66UB1 + 348.10_beta2 Reboot cycling from OpenVPN certs, aka nvram overflow

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

dugaduga

Senior Member
Had some issues with OpenVPN, after rebooting to see if this would rectify the issue, it went into an infinite boot loop; Factory default/reset button doesn't change that. I cannot access the router at all. Looks like the latest firmware bricked my AC66U B1 [nope, way off]


Anyone know how to stop the infinite boot cycle and re-flash this thing ?
 
Last edited:
Turn off the router by pressing the power button then push the reset button and power on the router both buttons needs to push at same time and reflash firmware using the Asus Restoration firmware tool or using mini web server forgot to tell you once both button have been pushed at Same time power led will keep blinking hold reset button for about 15 to 30 seconds

Sent from my SAMSUNG-SM-G920AZ using Tapatalk
 
Had some issues with OpenVPN, after rebooting to see if this would rectify the issue, it went into an infinite boot loop; Factory default/reset button doesn't change that. I cannot access the router at all. Looks like the latest firmware bricked my AC66U B1

If you want to save your device, consider re-flashing to an older version before you think about rebooting your device. I did not initially reboot the device a second time after installing the firmware, it was only after a second reboot this happened.

Anyone know how to stop the infinite boot cycle and re-flash this thing ?
Just rebooted my AC66U_B1 on 384.10 beta 2. Came right back up. No issues.

Recommend you use the firmware restore tool with the router in recovery mode. Try a reset using the WPS button from a power off first.
 
Reflashing will not change anything IMHO, since the router was succesfully running the firmware. He's most likely facing nvram corruption.

My own RT-AC66U_B1 had nearly full nvram when I tested it earlier today, so my guess is that's what caused his problem. He'll need to wipe out nvram to regain access.
 
My NVRAM usage 52611 / 65536 bytes

Then a reset using WPS button is the way to go... And reformat /jffs
 
RMerlin was absolutely 100% correct; I confused wps with reset, didn't even know it existed and hitting that I can see everything is good now! Sorry about that RMerlin, and thank you for all the support!
 
Cleared NVRam Cache, formatted jffs,

No other scripts at all, no openvpn clients,
NVRAM usage 52000 / 65536 bytes
With one openvpn client+cert (no other scripts)
NVRAM usage around ~57000 / 65536 bytes
With two openvpn clients+certs: (no other scripts)
NVRAM usage 62604 / 65536 bytes

That is a roughly ~5000 kb increase per opvn, exact size as the openvpn certificate authority.
Cache does not go down after disabling the second client, even after rebooting.
After deleting the certificate and rebooting Nvram showed:
NVRAM usage 62587 / 65536 bytes
Update: After formatting jffs again, NVRAM usage 62607 / 65536 bytes
I suspect trying more than 2 clients/ certs went over the nvram limits previously.
I was not able to to start a second client even within the NVRam limit.
 
Before adding 3rd client
NVRAM usage 62315 / 65536 bytes
After adding 3rd client (no cert yet)
NVRAM usage 62318 / 65536 bytes
After adding cert:
65534 / 65536 bytes

cert nvcache its passed on with cfg files even with no certs in jffs, the certs are not visible in the openvpn configuration gui or jffs. that aint going back down until i clear the nvcache with wps; unless you know of some command or openvpn directive to help that process to eliminate old unused certs from cache, would be nice to see compression here.

I'm going to do a nvclear reconfigure from scratch again and configure only one single openvpn client until this is fixed.
 
Looks like your certs are going to NVRAM. Had this issue some time ago with server certs which I solved by moving them to /jffs manually. I thought the newer firmware put the certs in /jffs automatically?

Sent from my SM-T380 using Tapatalk
 
Maybe its time to do a full M&M Config (see my signature for links below) and not use saved config files?

Even maybe using the WPS NVRAM erase steps, formatting the jffs on next reboot and re-flashing the latest firmware onto the router (even if it is the same version as what is currently installed). Followed, of course, by a minimal and manual configuration to secure the router and connect to your ISP.
 
It's a bug, as those key/certs should only end up on /jffs, not in nvram. I tracked it down to a section of code of the web server that was writing to nvram any parameter it received but didn't recognize as part of an indexed parameter. I just need to ensure the fix does not create any new problem.
 
Do take note on how to clear your NVcache of stagnant certs:

384.10 Beta 3 is now available. This release contains a couple of changes surrounding OpenVPN key/certs management, which should notably reduce nvram usage. The issue where key/certs would sometimes be left in nvram is fixed, and the unused key/cert var names are no longer wasting nvram space either, saving a few hundred bytes of nvram. Please make sure no new issue was introduced surrounding management of key/certs.

It is also now possible to remove a key/certs by clearing its field, rather than having to remove the file in /jffs/openvpn/ .

The following script will clear up your nvram:

Code:
#!/bin/sh

echo "Removing unused cert/key from nvram..."

for i in 1 2 3 4 5
do
    nvram unset vpn_crt_client$i\_ca
    nvram unset vpn_crt_client$i\_extra
    nvram unset vpn_crt_client$i\_crt
    nvram unset vpn_crt_client$i\_key
    nvram unset vpn_crt_client$i\_crl
    nvram unset vpn_crt_client$i\_static
done

for i in 1 2
do
    nvram unset vpn_crt_server$i\_ca
    nvram unset vpn_crt_server$i\_dh
    nvram unset vpn_crt_server$i\_ca_key
    nvram unset vpn_crt_server$i\_extra
    nvram unset vpn_crt_server$i\_client_crt
    nvram unset vpn_crt_server$i\_crl
    nvram unset vpn_crt_server$i\_crt
    nvram unset vpn_crt_server$i\_key
    nvram unset vpn_crt_server$i\_static
    nvram unset vpn_crt_server$i\_client_key
done

nvram commit

echo "done."

The Firefox stalls when using https with a router-generated certificate should also be resolved now (looks like an old Firefox bug came back when they added TLS 1.3 support), a workaround has been implemented - you might need to re-generate your router certificate.

Code:
314329e5c2 Updated documentation
99c64f99f8 Bumped revision to beta 3
a45ceea61c libvpn: allow erasing a key/cert by providing an empty one
2204f05a5e libvpn: resetting to default wasn't clearing client extra CA certificate
58c2fda137 shared: remove indexed vpn_crt_* entries from default nvram settings
708ee2bb7c httpd: webui: display client's bandwidth on wireless log page
c4583ee465 httpd: do not link with libletsencrypt when OpenSSL 1.1.x is enabled due to mismatched openssl versions
61380ae127 httpd: add emailAddress attribute to generated certificate
7225891383 (rtax88) Merge with 384_5640 GPL
7dbff248a1 webui: Classification page fixes: hide filters on empty list, remove undefined class popup in non-aQoS mode
 

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top