Solved High nvram usage

[mad_ady]

I was playing with my RT-AC56U running RMerlin 384.5 and I noticed by accident that the nvram usage is a bit high:

NVRAM usage: 65545 / 65536 bytes

It seems I am 9 bytes over the limit and yet the router *appears* to be running fine. I do use long wifi passwords, have 30+ static dhcp bindings and about 10 openvpn accounts with long random passwords as well.

Should I attempt to do some manual cleanup? Does my unit have more than 64k NVRAM?

Also on an unrelated note the CPU is about 90C when doing heavy transfers over openvpn. Is it a problem for occasional 10h transfers?

Thanks

 

[martinr]

Have a look here and read on for the next few posts.
Does that help at all? Is it valid for the RT-AC56U?

Backup first if you do anything drastic.

 

[WuTang LAN]

Try running the following script.
It clears out unused OpenVPN certificates stored in the NVRAM:

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

 

[dave14305]

Also try the one-line command to see what your largest variables are.

Approved ways to free up NVRAM space...

 

[mad_ady]

Thank you both for the suggestion. However, since I'm running an old version 384.5 and my router is no longer supported - I'm not sure whether deleting those entries from nvram is safe (the fix was proposed in a 384.10 post).
Any ideas when the certificates were moved out of the nvram?
Edit: It seems I still have 50 bytes left:

size: 65478 bytes (58 left)

Something must have been deleted from it...

 

[mad_ady]

Here are my top variables:

size: 65429 bytes (107 left)
1147 dhcp_staticlist
1089 sshd_hostkey
991 custom_clientlist
810 nc_setting_conf
655 client_info_tmp
624 sshd_dsskey
454 rc_support
412 sshd_authkeys
400 vpn_serverx_clientlist
338 sshd_ecdsakey
168 vpn_client1_custom2
167 vpn_client_custom2
120 qos_rulelist
117 wps_env_buf
106 ipv6_fw_rulelist
92 1:pa5ga1
92 1:pa5ga0
87 asus_device_list
77 wl0.2_wpa_psk
75 wl0_wpa_psk

I need to cleanup my dhcp list, it seems...

 

[kernol]

Thank you both for the suggestion. However, since I'm running an old version 384.5 and my router is no longer supported - I'm not sure whether deleting those entries from nvram is safe (the fix was proposed in a 384.10 post).
Any ideas when the certificates were moved out of the nvram?
Edit: It seems I still have 50 bytes left:

size: 65478 bytes (58 left)

Something must have been deleted from it...

You might try this command - not destructive as far as I know - just clears nvram var lines with = "blank" entries ...

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

Has worked for me without issues on AC-5300 and DSL-AC68U

 

[martinr]

....
Any ideas when the certificates were moved out of the nvram?
Edit: It seems I still have 50 bytes left:

size: 65478 bytes (58 left)

Something must have been deleted from it...

Ages ago: 378.55
https://www.snbforums.com/threads/approved-ways-to-free-up-nvram-space.27591/#post-210656

 

[mad_ady]

Thank you!

 

[mad_ady]

Ok, I ran the cleanup script and it freed about 5000 bytes from nvram, which I guess it's plenty Rebooted and vpn is working fine.
Thanks again for the assistence!

 

[martinr]

Ok, I ran the cleanup script and it freed about 5000 bytes from nvram, which I guess it's plenty Rebooted and vpn is working fine.
Thanks again for the assistence!

Good work. Thanks for the feedback. Was that kernol’s clean-ip script?
https://www.snbforums.com/threads/solved-high-nvram-usage.56848/#post-494600

 

[gattaca]

^^^ All of the above seems like good (and very useful) amtm candidates?

 

[WuTang LAN]

^^^ All of the above seems like good (and very useful) amtm candidates?

They would be more suited for scMerlin than amtm.

Tagging @Jack Yaz

 

[martinr]

They would be more suited for scMerlin than amtm.

Tagging @Jack Yaz

And scMerlin is, of course accessible in amtm. Great ideas.

 

[sbsnb]

I need to cleanup my dhcp list, it seems...

You can put all of that junk in a /jffs/configs/dnsmasq.conf.add with the format:

dhcp-host=DE:AD:BE:EF:CA:FE,hostname,192.168.1.2,12h

Then you can clear all of the DHCP host out of NVRAM.

 

[sbsnb]

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

Careful. That one will catch any NVRAM with an equal sign at the end of the value (like base64 encoded values). It will fail at the unset command, but it triggers my OCD. The following works for me:

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

 

[kernol]

Careful. That one will catch any NVRAM with an equal sign at the end of the value (like base64 encoded values). It will fail at the unset command, but it triggers my OCD. The following works for me:

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

Thanks for that - more tidy I guess ... but in my "before" and "after" comparison of the nvram on my router - the ONLY lines which the code I originally posted removed were those with a blank value [null value of you wish] following the = sign.

 

[garysteel]

Thanks you all......Used the one liner to clear up and moved from 65k to 55k not sure what was pete tong in my nvram but that worked before anf after:-

ASUSWRT-Merlin RT-AC68U 384.14-0 Sat Dec 14 00:39:28 UTC 2019

admin@RT-AC68U-5B18:/tmp/home/root# nvram show | awk '{print length(), $0 | "sor

t -n -r"}' | cut -d"=" -f 1 | head -n 20

size: 65031 bytes (505 left)

3157 custom_clientlist

1805 dhcp_staticlist

1611 dhcp_hostnames

810 nc_setting_conf

662 wl0_maclist_x

659 wl0_maclist

644 wl1_maclist_x

641 wl1_maclist

607 wl_maclist_x

604 wl_maclist

516 rc_support

436 sr_rulelist

226 vpn_client2_cust2

226 vpn_client1_cust2

225 vpn_client_cust2

205 wl1_chansps

120 qos_rulelist

96 rstats_data

92 1a5ga2

92 1a5ga1



admin@RT-AC68U-5B18:/tmp/home/root# nvram show | awk '{print length(), $0 | "sor

t -n -r"}' | cut -d"=" -f 1 | head -n 20

size: 55826 bytes (9710 left)

3157 custom_clientlist

1805 dhcp_staticlist

1611 dhcp_hostnames

810 nc_setting_conf

662 wl0_maclist_x

659 wl0_maclist

644 wl1_maclist_x

641 wl1_maclist

607 wl_maclist_x

604 wl_maclist

516 rc_support

436 sr_rulelist

225 vpn_client2_cust2

225 vpn_client1_cust2

224 vpn_client_cust2

205 wl1_chansps

120 qos_rulelist

95 rstats_data

92 1a5ga2

92 1a5ga1

 

[CRossi]

You can put all of that junk in a /jffs/configs/dnsmasq.conf.add with the format:

dhcp-host=DE:AD:BE:EF:CA:FE,hostname,192.168.1.2,12h

Then you can clear all of the DHCP host out of NVRAM.

Hello everyone and sorry for my late question, but my NVRAM is quite full due to static DHCP list and WiFi MAC permissions list.
I read your tip about moving these configs to jffs, but is there any method to do so without losing the capacity to manage these configs with the web UI?
And if not, is there any plan in the future firmware, to officially move these data from nvram to jffs?
I think that many user will be happy to free the small nvram, moving data to the large (~60MB) jffs partition.
Thanks for any help

 

[RMerlin]

And if not, is there any plan in the future firmware, to officially move these data from nvram to jffs?

Out of my control.