NVRAM size

[eak]

Does anyone know if there an ASUS product newer than the RT-AC66U that has more than 64KiB of NVRAM? I am forever having to reset and reload my router because I run into the limit. It would make life much simpler if there were a product with more. The last time I looked I didn't see NVRAM size specified on the ASUS product pages, so I thought I would ask users if they have one with more.

 

[john9527]

None that I'm aware of....even the tri-band AC3200 is still 64K.

But if you are running OpenVPN servers/clients, this wiki entry may help you out
https://github.com/RMerl/asuswrt-merlin/wiki/reducing-nvram-for-openvpn-certs

 

[RMerlin]

It's all 64 KB. We might see the RT-AC3200U get upgraded to 128 KB at some point since this model is running dangerously low on free nvram, and I did see some traces in the source code hinting at support for 128 KB nvram, but nothing has been announced so far.

 

[eak]

But if you are running OpenVPN servers/clients, this wiki entry may help you out
https://github.com/RMerl/asuswrt-merlin/wiki/reducing-nvram-for-openvpn-certs

Thank you. That looks like it would indeed solve the problem. I will give it a try at the next reload.

Do you happen to know if there is a way to set the certificate used by the router's HTTPS daemon? I would set it to the same one used by OpenVPN and avoid some certificate warnings when I first use https:// to the router.

 

[RMerlin]

Do you happen to know if there is a way to set the certificate used by the router's HTTPS daemon? I would set it to the same one used by OpenVPN and avoid some certificate warnings when I first use https:// to the router.

https://gist.github.com/davidbalbert/6815258

 

[mstombs]

It's all 64 KB. We might see the RT-AC3200U get upgraded to 128 KB at some point since this model is running dangerously low on free nvram, and I did see some traces in the source code hinting at support for 128 KB nvram, but nothing has been announced so far.

The crazy thing is that Flash chips are organized into erase blocks, to write to anything in a block the whole section is first erased and everything re-written. The erase block size in an RT-N66U :-

Dec  1 00:00:07 kernel: 0x01fe0000-0x02000000 : "nvram"

131072 Bytes = 128 kB

So no change in flash usage, a bit more ram for the live nvram variable storage I guess.

A long time ago I built a version of tomato on a WRT54G-TM with 128kB with a custom compiled CFE with matching NVRAM_SPACE - it worked for a while till it didn't when I needed JTAG to recover. I suspected that Broadcom binary drivers may also need to be recompiled, but also the source tree is a bit of a mess with many variables for the same thing in different places, so not a simple change - see here for evidence of using 128kB for an arm CFE if NVSIZE=128

https://github.com/RMerl/asuswrt-me...src/cfe/build/broadcom/bcm947xx/Makefile#L223

but this Makefile defaults to 32kB for mips, which is no longer current, except for the poor old RT-N16 ...

 

[RMerlin]

Broadcom's nvram handling code is so obsolete... Technically, nvram values should still not be larger than something like 100 bytes. That's why the CFE will flat out crash if you try to do an "nvram show" from the CFE while you have anything like OpenVPN or SSH keys configured. Someone need to wake Broadcom up to this.

 

[eak]

https://gist.github.com/davidbalbert/6815258

Thank you. That is very helpful. I just make the /jffs change for the OpenVPN certs and it worked well. I might even have the room for a https cert/key in nvram now (too bad they can't live in jffs too).

What did you think of sasoiliev's suggestion at at the link you posted? I actually keep a separate CA just for OpenVPN because of the ASUS need to have things simpler (RSA instead of EC, two-level instead of three-level, shorter RSA keys to save space). Someday it would be nice if it all unified.