Solved High nvram usage

[automaton]

DHCP doesn't use NVRAM, it uses memory.

The static list is certainly in NVRAM, but I will print the same NVRAM dump as above the next time it happens so we can see.

 

[ColinTaylor]

The static list is certainly in NVRAM...

Yes, but it's.... static. In other words, dnsmasq is only reading the existing data at startup, it's not writing anything to nvram. I'm not saying you don't have an nvram problem, but so far everything you've posted has pointed to memory issues.

 

[maxbraketorque]

386.10 has caused an ~200 byte increase in nvram usage. I'm now within 200 bytes of the 65536 byte limit. Ready for Merlin to toss settings for three VPN clients for the AC68U.

 

[bennor]

386.10 has caused an ~200 byte increase in nvram usage. I'm now within 200 bytes of the 65536 byte limit. Ready for Merlin to toss settings for three VPN clients for the AC68U.

Meh not having an 386.10 NVRAM issue here on a RT-AC68U (no VPN, no AiProtection, or anything special besides YazDHCP and YazFi).

 

[Tech9]

What you use YazFi for with no VPN? Custom DNS filtering on Guest Network?

 

[bennor]

What you use YazFi for with no VPN? Custom DNS filtering on Guest Network?

If this was directed at my post, yes primarily so I could set the DNS servers. Ran into problems with certain guest WiFi IoT devices failing to work properly because they couldn't reach my main LAN's Pi-Hole's using just Asus's Guest WiFi. Also use a few other features of YazFi as well (like client isolation for example).

 

[maxbraketorque]

Meh not having an 386.10 NVRAM issue here on a RT-AC68U (no VPN, no AiProtection, or anything special besides YazDHCP and YazFi).
View attachment 48700

I've been wanting to see proof that a router hard reset would take care of the nvram issue. This is the first I've seen of anyone showing clear proof, so this is helpful. How long has it been since you've done a full reset, and have you seen the nvram usage increase over time?

 

[bennor]

I've been wanting to see proof that a router hard reset would take care of the nvram issue. This is the first I've seen of anyone showing clear proof, so this is helpful. How long has it been since you've done a full reset, and have you seen the nvram usage increase over time?

Not a hard reset in my case, although that is where to start. Rather a running of various scripts mentioned in other threads. Currently, a day after posting that screen shot by NVRAM hasn't changed. Still at 47831 / 65536 bytes. Router has been up for over 6 days.
Scripts that I've been using. YMMV with them. RMerlin's script at the following post:
https://www.snbforums.com/threads/asus-rt-ac68u-386-2_6-low-on-free-nvram.73158/#post-695283

#!/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

# SSH also migrated host keys to jffs a while back
nvram unset sshd_dsskey
nvram unset sshd_ecdsakey
nvram unset sshd_hostkey

nvram commit

echo "done."

Running sbsnb's code line in this post:
https://www.snbforums.com/threads/solved-high-nvram-usage.56848/#post-494736

for line in `nvram show | grep ^[^=]*=$ `; do var=${line%*=}; nvram unset $var; done; nvram commit

Running Martinski's script (./CleanupNVRAMvars.sh -unset) in this post:
https://www.snbforums.com/threads/3...uild-s-for-ac-models.83565/page-2#post-824457

#!/bin/sh
####################################################################
# CleanupNVRAMvars.sh
# To remove deprecated NVRAM entries for VPN & SSH keys.
# Last Modified: Martinski W. [2023-Feb-23]
####################################################################
set -u

_UnsetNVRAMvars_()
{
   if [ $# -eq 0 ] || [ -z "$1" ] ; then return 1 ; fi

   local Count="$(nvram show 2>/dev/null | grep -c "^$1")"
   if [ $Count -gt 0 ]
   then
       if [ $# -eq 2 ] && [ -n "$2" ] && \
          $doNVRAM_unset && echo && ! _PromptForYesOrNo_ "$2"
       then return 10 ; fi

       if "$firstRun" ; then firstRun=false ; echo "$SEPstr1" ; fi

       for KeyStr in $(nvram show 2>/dev/null | grep "^$1")
       do
           if ! echo "$KeyStr" | grep -qE ".*[=]+.*"
           then Count=$((--Count)); continue ; fi
           echo "KeyName: [${KeyStr%%=*}]"
           $doNVRAM_unset && nvram unset "${KeyStr%%=*}"
       done

       echo "VARs COUNT: [$Count]"
       $doNVRAM_unset && \
       echo "COUNT AFTER: [$(nvram show 2>/dev/null | grep -c "^$1")]"
       echo "$SEPstr1"
       doNVRAM_commit=$doNVRAM_unset
       return 0
   else
       echo "NVRAM variables [${1}.*] NOT FOUND."
       return 1
   fi
}

_PromptForYesOrNo_()
{
   read -n 1 -p "$1 [Y|N] N?" YESorNO
   if [ -z "$YESorNO" ] ; then return 1 ; fi
   echo
   if [ "$YESorNO" = "Y" ] ; then return 0 ; fi
   return 1
}

firstRun=true
doNVRAM_unset=false
doNVRAM_commit=false
SEPstr0="=================================================="
SEPstr1="--------------------------------------------------"

if [ $# -gt 0 ]
then
   if [ "$1" = "-unset" ]
   then doNVRAM_unset=true
   else echo "*UNKNOWN* Parameter [$1]." ; exit 1
   fi
fi

echo -n "NVRAM " ; nvram show | grep "^size: "
echo "$SEPstr0"
_UnsetNVRAMvars_ "vpn_crt_client"
_UnsetNVRAMvars_ "vpn_crt_server"
_UnsetNVRAMvars_ "sshd_.*.key="

for VPNnum in 5 4 3
do
   _UnsetNVRAMvars_ "vpn_client${VPNnum}_" "Remove ALL OpenVPN Client${VPNnum} variables?"
   [ $? -eq 10 ] && echo "Skipping OpenVPN Client${VPNnum} variables."
done
echo "$SEPstr0"
echo -n "NVRAM " ; nvram show | grep "^size: "

if ! "$doNVRAM_commit"
then echo "NOTHING to commit."
else nvram commit ; echo "Completed successfully."
fi

#EOF#

Probably some redundancy being performed by all three but that's what I've been using to free up the NVRAM on an RT-AC68U. Also run YazDHCP which helps due to 19 or so manual IP reservations. No VPN in use. No issues or problems, that I've noticed, with the router since running those commands/scripts after installing the Alpha 386.9 firmware and every time the firmware is updated or router is rebooted since. Again it's YMMV and all that.

 

[maxbraketorque]

Not a hard reset in my case, although that is where to start. Rather a running of various scripts mentioned in other threads. Currently, a day after posting that screen shot by NVRAM hasn't changed. Still at 47831 / 65536 bytes. Router has been up for over 6 days.
Scripts that I've been using. YMMV with them. RMerlin's script at the following post:
https://www.snbforums.com/threads/asus-rt-ac68u-386-2_6-low-on-free-nvram.73158/#post-695283

 1st script...

Running sbsnb's code line in this post:
https://www.snbforums.com/threads/solved-high-nvram-usage.56848/#post-494736

for line in `nvram show | grep ^[^=]*=$ `; do var=${line%*=}; nvram unset $var; done; nvram commit

 3rd script...

Probably some redundancy being performed by all three but that's what I've been using to free up the NVRAM on an AR-AC68U. Also run YazDHCP which helps due to 19 or so manual IP reservations. No VPN in use. No issues or problems, that I've noticed, with the router since running those commands/scripts after installing the Alpha 386.9 firmware and every time the firmware is updated or router is rebooted since. Again it's YMMV and all that.

Ah, I see. I ran the 1st script around when Merlin posted it, so that one gets me nothing.

The 3rd script removes all variables associated with VPN clients 3, 4, and 5 and is apparently good for removing ~2500 bytes which is very helpful. This is equivalent to what Merlin has proposed to mitigate the low nvram issue with the AC68U, but Martinski's script does not make a permanent change, i.e., the variables that are eliminated come back when the router is rebooted. I see that Martinski has a script to delete the variables on router boot-up, but IMHO, better if Merlin just eliminates VPN clients 3, 4, and 5 because that approach requires no special knowledge to more easily avoid the low nvram issue.

The second script that you posted is making the lion's share of the difference for your AC68U, but unfortunately this is not an ideal script to run because it can cause issues down the road if people change router settings associated with the variables that have been removed.

So I still contend that the best way to combat the low nvram issue with Merlin's AC68U firmware is for Merlin to eliminate VPN clients 3, 4, and 5.

 

[bennor]

So I still contend that the best way to combat the low nvram issue with Merlin's AC68U firmware is for Merlin to eliminate VPN clients 3, 4, and 5.

It will likely take some time for RMerlin to make such a change and test it if he ultimately decides to make the change for the RT-AC68U. In the mean time one can try the various suggestions (even if they have draw backs) to deal with low NVRAM right now. And yes some or all of the methods have to be run after each router reboot. Indicated as much in my post. It is what it is if one wants to deal with the the issue right now on a RT-AC68U.

 

[Tech9]

No issues or problems, that I've noticed, with the router since running those commands/scripts after installing the Alpha 386.9 firmware and every time the firmware is updated or router is rebooted since.

That's a lot of "maintenance" to keep this router going. What happens after reboot without running the scripts?

 

[bennor]

That's a lot of "maintenance" to keep this router going. What happens after reboot without running the scripts?

Lot of "maintenance"? Not really. Literally takes a minute or so to run the two scripts (already saved to the router) and one line of code if or when I reboot that route which usually is not often. That router will eventually be replaced, but for now it still chugges along. Don't remember the exact NVRAM usage post reboot but it was significantly higher.

 

[Tech9]

Meh not having an 386.10 NVRAM issue here

Okay, but don't say "not having NVRAM issue here" when you fight the NVRAM issue on every reboot.

 

[RMerlin]

If your router is almost out of nvram, you save some nvram by using the script that removes some VPN variables, and then fill up that recovered nvram with, say, more DHCP reservations. Next boot, the router may try to readd the missing VPN variables, run out of free nvram, and leave you with completely corrupted settings and/or a router no longer booting.

You can't rely on that script as a solution.

 

[bennor]

Okay, but don't say "not having NVRAM issue here" when you fight the NVRAM issue on every reboot.

My post (that you quoted) was a bit tongue-in-cheek. I personally am not having to "fight the NVRAM issue on every reboot". For my use the router runs fine with the NVRAM at approx 59325 / 65536 bytes post reboot. I choose to experiment to find ways to lower the NVRAM, because why not. Its fun to tinker at times.

RMerlin is absolutely correct, the script (various scripts or lines of code) mentioned in these NVRAM threads are not "solutions" to the low NVRAM some may face with the RT-AC68U.

RT-AC68U users who are having the low NVRAM warning message should start by doing a hard factory reset and manually configure their router. That seems to clear the Low NVRAM warning message based on various posts here. It seems that the next basic step, if low NVRAM is still an issue, is to look at the DHCP manual IP reservations and deal with those by either; removing them, or use YazDHCP or similar methods. If one still has NVRAM issues they can review the various NVRAM threads for other options (some temporary until reboot) to see if those options are something they want to try, at their own risk. As with more than a few things discussed here it's "your mileage may vary" on the results. Or one can choose to update to a newer router and not have to worry about the NVRAM on the RT-AC68U.

 

[Tech9]

My post (that you quoted) was a bit tongue-in-cheek.

Probably, but posting screenshots like the one above with no explanation is a bit misleading to others:

I've been wanting to see proof that a router hard reset would take care of the nvram issue.

 

[bennor]

Probably, but posting screenshots like the one above with no explanation is a bit misleading to others:

Not misleading at all, that person assumed I had done a hard reset when I never indicated such in that post. Look at the post I replied to, they posted:

386.10 has caused an ~200 byte increase in nvram usage. I'm now within 200 bytes of the 65536 byte limit. Ready for Merlin to toss settings for three VPN clients for the AC68U.

They make no mention of doing a hard reset either. Should we automatically assume they did one?

 

[Tech9]

It was similar to posting this image to people using Samba with 97% RAM utilization:

...but without telling them I just dropped the caches in SSH to make the screenshot look nice.

 

[bennor]

Guess we'll just agree to disagree. In any event this repeated back and forth over Tech9's issue with my prior post and it's screen capture is just dragging this thread off topic. To bring the thread back on topic: For those who are having NVRAM issues read through this and other NVRAM threads for various suggestions and ideas on how to potentially deal (even if only temporarily) with your specific NVRAM issue. Good Luck.

 

[Tech9]

Guess we'll just agree to disagree.

You already agreed with Like the script(s) you use is(are) not a solution:

You can't rely on that script as a solution.

What I don't agree with is posting "manipulated" screenshots misrepresenting the real situation. The real NVRAM situation with your minimum configuration RT-AC68U is 59325/65536 after boot and not 47831/65536. @maxbraketorque was the first one to believe you solved the issue.