[Discussion] Remove several OpenVPN clients from RT-AC68U to reduce high nvram usage

[RMerlin]

I can't think of a way to save up more NVRAM usage.

Hence it has to be done at the firmware level. Removing OVPN clients 3 through 5 alone will save 2.7 KB, which is a lot.

 

[Almilcar]

Hence it has to be done at the firmware level. Removing OVPN clients 3 through 5 alone will save 2.7 KB, which is a lot.

I´ll wait then for the next update.

Thank you.

 

[bengalih]

Just chiming in here as I was recently made aware of this issue. My 68U is fairly heavily customized and someone pointed out NVRAM may be an issue. I checked and actually have about 3.4K free which, while not a lot, is far enough away not to be causing me an issue and I can't believe that I will have to do much to increase it more.

Note however I am on 386_3.2 and while I don't actually know of a need to update to the latest FW based on release notes (although I tend to only update once every 1-2 year when I've had to rebuild a drive or something, barring a known issue I needed to fix) I am concerned that I should not upgrade to 386_9+ due to it sounding like those versions may take up even more NVRAM and leave me in a problematic state.

It sounds like there really isn't a solution without some change. Some people may have old certificates, etc, cached and if so they might be able to free that up. But, assuming you are running optimally for your configuration it looks like there isn't an alternative. Everything I see discusses freeing up move NVRAM by removing variables that are unset, but as RMerlin stated in another thread this is problematic because it only creates the illusion of free space which if you fill up with more data may cause an error on reboot before the scripts can clean up the unused variables.

Right now my largest variables are:

size: 62149 bytes (3387 left)
1345 custom_clientlist
931 nc_setting_conf
761 sshd_authkeys
549 rc_support
375 wl1_chansps
362 vts_rulelist
229 vpn_client_cust2
166 subnet_rulelist
120 qos_rulelist
112 vlan_rulelist
102 wl1_chlist

While I could completely remove my custom_clientlist, it would be annoying not to have the friendly names there. The only thing I think I can move out is my vts_rulelist and possibly manage these directly via iptables instead of the GUI. But for the paltry ~350 bytes it doesn't seem worth it.

While increasing the NVRAM size isn't possible, I haven't been able to find a clear answer on getting the AC68U to utilize the /jffs/nvram location.
I see that location exists on my router, but it is empty. If my custom_clienlist and sshd_authkeys could be moved there it would free up another ~2.5KB. I'm assuming that implementing this into the AC68U is either impossible based on architecture or much much more time consuming then simply removing the extra VPN clients?

I for one only use a single VPN client, and really it is mostly there for testing. I could easily live with only 2. Especially since, as has been noted you can always just keep your .ovpn files on a drive an toggle them. Sure it takes a minute or two to switch, but even for those who use multiple, how often are you actually switching and how many clients are you actually using simultaneously?

There are bound to be some people out there who the reduction will inconvenience, but I think both the number and severity of the inconvenience pales to the number of people that would benefit from the additional NVRAM. Having to manually toggle between 4 .ovpn files is much less than an issue than a router that won't function or gets corrupted because the implemented features might overrun the NVRAM.

So my vote is to offload somethings to /jffs if that is possible. I think that would help a large subset of these people (We'd have to know what all we could get offloaded there, if any, to know the extent it could help). Barring that (or in addition), I'm good with getting rid of the additional VPN clients if that is the only other reasonable choice.

Might there be other options as well in terms of removing some thing from NVRAM that not everyone uses? For example, I note the following 4KB of data:

lan1_ipaddr=192.168.2.1
vpn_server2_r1=192.168.1.50
vpn_server2_r2=192.168.1.55
vpn_server1_r1=192.168.1.50
vpn_server1_r2=192.168.1.55
vpn_server_r1=192.168.1.50
vpn_server_r2=192.168.1.55
subnet_rulelist=<192.168.101.1>255.255.255.0>1>192.168.101.2>192.168.101.254>86400>>>>0>>1><192.168.102.1>255.255.255.0>1>192.168.102.2>192.168.102.254>86400>>>>0>>1>
lan1_gateway=192.168.2.1
pptpd_clients=192.168.10.2-11
size: 62149 bytes (3387 left)
ipv61_relay=192.88.99.1
wgn_brif_rulelist=<br1>192.168.101.1/24><br2>192.168.102.1/24>
dhcp1_start=192.168.2.2
dhcp1_end=192.168.2.254
ipv6_relay=192.88.99.1
atcover_sip_ip=192.168.1.1
vlan_rulelist=<1>501>0>0>FFFF>0002>0000>192.168.101.1/24>1>0>1><1>502>0>0>FFFF>0000>0002>192.168.102.1/24>1>0>1>

I'm not sure what all of these are for, but I think that for instance dhcp1_start/dhcp1_end is the range that gets loaded for the default dhcp-range in dnsmasq for the guest-wifi. If you aren't using this, you don't need this value. I know on my device I'm not using 192.x ranges for anything.
This particular option example may not be the best, but my thought is this: Would it be possible to remove some of these built-in values for features that are not core/critical/enabled by default and only add them back when a feature is actually used? This might require some changes/additions in the GUI to add fields that the user would have to populate, and this would mean a bit more configuration by typing in some IP ranges here and there. It should be simple enough if this is possible to just add the text to the GUI page as to what the suggested/default range/option would be.

That idea might be too far afield (I may be overlooking something in the architecture that makes this impossible), or the effort to do this may be tedious for RMerlin. But, if possible it could present an option that doesn't take anything away other than perhaps a minute or two more during initial configuration of a feature.

thanks.

 

[k2kx]

Another vote for reducing VPN client to 2. I see no benefits for more when the router is unstable. You wouldn't be able to use it anyway if you having stability issue.

 

[Iko]

Hi! I am one of the people whose router was misfiring because the NVRAM was full. A hard factory reset did fix that by taking me from 100% back to about 85% usage (before further manual setup). I was actually using all five VPN client slots, as a quick means of swapping the household between different Proton VPN settings and server locations, but that was not really essential. I am wholeheartedly thankful to @RMerlin for the attention to this issue, reduction to 2 clients totally worth it in order to keep the hardware going for a while longer with enhanced functionality. Happy to be saving $$, mining waste and landfill space!

 

[bennor]

I am wholeheartedly thankful to @RMerlin for the attention to this issue, reduction to 2 clients totally worth it in order to keep the hardware going for a while longer with enhanced functionality.

If you haven't already updated to 386.11, you should. It incorporates the reduction of OpenVPN clients from 5 to 2 in order to free up some additional NVRAM space for the RT-AC68U and DSL-AC68U. See the main thread on 386.11:

Release - Asuswrt-Merlin 386.11 is now available for AC models

Asuswrt-Merlin 386.11 is now available for AC models. 386.11 (14-May-2023) - UPDATED: curl to 8.0.1. - UPDATED: openvpn to 2.6.3. - CHANGED: Reduce max OpenVPN clients to 2 for RT-AC68U and DSL-AC68U due to lack of NVRAM on these two models. Note that existing...

www.snbforums.com

Make sure to follow the extra step of runningclear_vpnclients.sh indicated in the change log file if you have a RT-AC68U and DSL-AC68U.

 

[unsynaps]

OK, so still nobody has actually explained why would someone need 5 OpenVPN clients. I would really like to see a real-life scenario explanation as for what and which and why... I guess some people just have enough time to argue about 2 vs 5, but don't have time for explaining this simple thing. I mean, @Yota ... seriously... grandma using 5 OpenVPN clients on her AC68U router in 2023? Grandma must be some very well-versed hacker or something.

5 up at one time? No.
5 configured differently and turning them off and on as needed so I don't have to re-enter settings every single time? Yes.

 

[Iko]

If you haven't already updated to 386.11, you should. It incorporates the reduction of OpenVPN clients from 5 to 2 in order to free up some additional NVRAM space for the RT-AC68U and DSL-AC68U. See the main thread on 386.11:

Release - Asuswrt-Merlin 386.11 is now available for AC models

Asuswrt-Merlin 386.11 is now available for AC models. 386.11 (14-May-2023) - UPDATED: curl to 8.0.1. - UPDATED: openvpn to 2.6.3. - CHANGED: Reduce max OpenVPN clients to 2 for RT-AC68U and DSL-AC68U due to lack of NVRAM on these two models. Note that existing...

www.snbforums.com

Make sure to follow the extra step of runningclear_vpnclients.sh indicated in the change log file if you have a RT-AC68U and DSL-AC68U.

Thanks @bennor. I had already upgraded to 386.11 but hadn't read the changelog so didn't know about running the script. I just did that though and funnily my NVRAM usage was increased by a tiny bit when I refreshed the sysinfo page. Maybe that is because I had already gone in and cleared all the clients (reset them to default anyway) before doing the hard reset? In any case there's plenty of spare memory now.