Low NVRAM.. despite factory defaulting etc

[Simon W]

Hi,

I've had the "low NVRAM" warning on my RT-AC3200 for a while now, always assumed this to be likely a product of having been lazy for a few code upgrades and not factory defaulting etc. So today I tried to tackle it, but with no success:

First I backed up using the NVRAM Save/Restore tool, then factory defaulted, checked the NVRAM usage levels out-of-the-box (all ok), then using the NVRAM Save/Restore tool to do a clean restore = this pretty much put me back the the high NVRAM levels I started with.

Second I factory defaulted again then reconfigured from scratch manually, seemed to be ok until I imported the final two blobs of config, my static IP assignments (around 15 of them) and then, what seemed to push it over the edge, my custom_clientlist (I've given most of my devices meaningful names, around 50 of them) = high NVRAM levels again.

Surely this can't be right that I've hit a limitation of the router?! I wouldn't say I use all the features, certainly none of the VPN settings, nor any of the media sharing, cloud integration etc. If the custom_clientlist takes such a dint out of the very limited NVRAM isn't it possible to offload this to somewhere else?

To quantify I'm currently running at 63565 / 65536 bytes.

What sort of NVRAM utilisation do others run at (fully configured / steady state)? Can't see how mine should be wildly different?!

Thanks.

 

[joegreat]

About which router type your are talking?

 

[Simon W]

About which router type your are talking?

Good point well made = RT-AC3200 !

 

[john9527]

What router and firmware?

If it's an AC3200, you are disadvantaged wrt NVRAM because when they added the third radio they didn't expand NVRAM (the third radio takes about 5-6K of NVRAM space).

Some of the clientlist was already moved to JFFS, but not all. I suspect you will have to give up some of your custom defintitions.

 

[joegreat]

Good point well made = RT-AC3200 !

I was assuming it: Do a small search in the forum and you get a ton of complains about NVRAM shortage...

Unfortunately the AC3200 model is short on NVRAM by design and there is no magic solution for it: you can only check which entries are the biggest and avoid/reduce them as far as possible.

 

[RMerlin]

I experimented with potentially removing some OpenVPN clients for the RT-AC3200. Seems it would only save roughly 1K per client removed (so reducing it to three clients max = 2KB saved at most). Probably not worth the trouble for so little nvram saved, as this model present other issues as well for me.

 

[FTC]

Hi, what all the others said is exactly right about the RT-AC3200.
However there is something you can do : Run the command from a telnet / ssh session :

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

This will free up a good chunk of empty variables nvram space.A small warning though : This has been done in tomato firmware since long ago, and was not tested (some months ago) in asuswrt / merlin as far as I know. There is a small risk that the firmware interprets different a 'uninitialized var' from an 'empty var' . However, I have used it in my merlin (RT-AC3200) setup and did wonders and was ok for the functionality I use.. so test it at your own risk.

 

[NomadTech]

Hi, what all the others said is exactly right about the RT-AC3200.
However there is something you can do : Run the command from a telnet / ssh session :

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

This will free up a good chunk of empty variables nvram space.A small warning though : This has been done in tomato firmware since long ago, and was not tested (some months ago) in asuswrt / merlin as far as I know. There is a small risk that the firmware interprets different a 'uninitialized var' from an 'empty var' . However, I have used it in my merlin setup and did wonders and was ok for the functionality I use.. so test it at your own risk.

Works on RT-AC3200. Freed roughly 10KB

Update: NVRAM keeps creeping up. Roughly 9k in 5 days. Without me touching anything.

 

[Petrica]

Hi,

I haven't found similar issue description: on a AC87u running Merlin fw (380.65_4) OpenVPN client list gets loaded twice in NVRAM (as both vpn_client1_clientlist and vpn_client_clientlist with the same content). As I use quite a lot of rules for policy routing each list eats up 3.5 KB.

Most of the times the two client lists are shown together however sometimes only vpn_client1_clientlist appears. There is no difference in performance (except that it uses NVRAM).

Regards,

 

[RMerlin]

vpn_client_clientlist

This is a temporary variable that gets filled whenever you change settings through the webui. The web server then copies it to the appropriate instance (client1, client2, etc...).

This is the case for all OpenVPN settings.

 

[sfx2000]

This is a temporary variable that gets filled whenever you change settings through the webui. The web server then copies it to the appropriate instance (client1, client2, etc...).

This is the case for all OpenVPN settings.

Is there any reason to keep the vpn_client_clientlist in NV/flash in the first place?

This is pretty much ephemeral data, so putting this over in /tmp with tmpfs might be an option here...

just thinking outside the box...

 

[RMerlin]

Is there any reason to keep the vpn_client_clientlist in NV/flash in the first place?

This is pretty much ephemeral data, so putting this over in /tmp with tmpfs might be an option here...

just thinking outside the box...

You're talking redesigning pretty much the whole process on how the webui interacts with nvram. Instanced settings such as OpenVPN, WAN settings, wireless settings, etc... all use these un-instanced settings to pass the variables between the filled webui form and the httpd server. The server then copies them to their appropriate instance (wl0, wl1, vpnclient1, vpnclient2, etc...), while data that isn't instanced is simply left as-is, until it all gets committed back to nvram.

You'd have to ask Broadcom why this was designed this specific way.

 

[jappish84]

+1 for

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

on RT-AC-3200

Not sure if it broke anything though, freed 10KB

 

[pattiri]

I would like to notice a little thing about this command.

I've used this on my AC88u even though I dont need it and NVRAM usage dropped around 56KB from 66KB that's cool but every firmware upgrade it becomes 66 KB again. So don't trust this command that much.

 

[joegreat]

I've used this on my AC88u even though I dont need it and NVRAM usage dropped around 56KB from 66KB that's cool but every firmware upgrade it becomes 66 KB again.

That's logical: firmware update sets all the removed entries again - just re-run the script after every firmware update!

 

[sfx2000]

You're talking redesigning pretty much the whole process on how the webui interacts with nvram. Instanced settings such as OpenVPN, WAN settings, wireless settings, etc... all use these un-instanced settings to pass the variables between the filled webui form and the httpd server. The server then copies them to their appropriate instance (wl0, wl1, vpnclient1, vpnclient2, etc...), while data that isn't instanced is simply left as-is, until it all gets committed back to nvram.

You'd have to ask Broadcom why this was designed this specific way.

Yeah, I know...

It was a good idea 20 years ago, but we're doing so much more these days...

Was hoping Broadcom would make the jump over to eMMC with the new chipset and board support package, it would make life so much easier for the OEM's and Third Parties... even though, as you mention above, it would mean a fairly big jump for the WebGUI and backend read/write handling of the variables... but sometimes, a moment of agony is better than an ongoing long term ache.

Who knows, maybe it's coming - QCA has eMMC support in their Wave 2 Chipset BSP's already. So does Marvell...

 

[RMerlin]

Was hoping Broadcom would make the jump over to eMMC with the new chipset and board support package, it would make life so much easier for the OEM's and Third Parties...

Broadcom are failing at very basic things that are plain silly. For instance, why limit nvram to 128 KB on those modern routers when the actual mtd partition is already much larger than that anyway, due to block sizes? It makes no sense, beside being flat out oblivious at what the OEMs need out of the nvram storage. I see no reason not to allocate 512 KB or even 1 MB out of the gate. This limited nvram partition forces some of them like Asus to start storing things in jffs instead, meaning those settings are not part of any settings backup users might do.

 

[sfx2000]

I see no reason not to allocate 512 KB or even 1 MB out of the gate. This limited nvram partition forces some of them like Asus to start storing things in jffs instead, meaning those settings are not part of any settings backup users might do.

That's why eMMC is a much better approach - I agree with the silliness here...

 

[Viperrt1996]

Hi, what all the others said is exactly right about the RT-AC3200.
However there is something you can do : Run the command from a telnet / ssh session :

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

This will free up a good chunk of empty variables nvram space.A small warning though : This has been done in tomato firmware since long ago, and was not tested (some months ago) in asuswrt / merlin as far as I know. There is a small risk that the firmware interprets different a 'uninitialized var' from an 'empty var' . However, I have used it in my merlin (RT-AC3200) setup and did wonders and was ok for the functionality I use.. so test it at your own risk.

Hi,
I also have this same issue, ran command in SSH on my ac3200 without getting any change in nvram size. Not sure if I'm missing something runing it as I am somewhat new to doing command line stuff to router using putty.
After running the command, the last two lines of output to putty are as follows:
size: 64939 bytes (597 left)
usage: nvram [get name] [set name=value] [unset name] [show] [commit] [save] [restore] [erase][fb_save file] ...

Not sure if this is correct, but size is unchanged from before running command.

Any help will be appreciated!

 

[joegreat]

Not sure if this is correct, but size is unchanged from before running command.

You have do also a nvram commit after the unset one line script - otherwise the cleanup is not sticky across reboots...