Save roughly 10% Nvram space?

Discussion in 'Tomato Firmware' started by Nitro, Oct 17, 2012.

  1. Nitro

    Nitro Networkin' Nut Member


    after stumbling upon an old dd-wrt page after reading and scouting the internet about news for "asus RT-N16" & "64KB nvram" i stumbled upon a script that you can easily add to you init script page and it will recover roughly 10% of your nvram (or atleast in my test case)

    I had to modify the script to work with my router so as far as I currently know you'll be required to configure "jffs" partition in order to have this script work.

    the script:

    rm /jffs/nvramshow
    nvram show >> /jffs/nvramshow
    while read -r line; do
    if [[ "$val" == "" ]]; then
    nvram unset $var
    i=`expr $i + 1`
    if [[ $i == 50 ]]; then
    sleep 2
    done < /jffs/nvramshow
    exit 0


  2. koitsu

    koitsu Network Guru Member

    Do you know what this script does? (I know what it does; I'm asking you if *you* know what it does, and if you know what the repercussions of this script are :) )
  3. Monk E. Boy

    Monk E. Boy Network Guru Member

    Technically it just needs a writeable directory on the router, so a mounted, writeable, USB drive would work too. You'd just have to modify the path.

    Personally I understand what the script does but upon reflection I could see it having significant repercussions depending on how the system later interacts with the deleted information.
  4. koitsu

    koitsu Network Guru Member

    Correct/exactly. The script author makes the assumption that "because an NVRAM variable contains no value, there's no point in the variable being there". This is an absolutely 100% WRONG assumption. There is absolutely code in the firmware where it makes the assumption that a variable exists and will get back an empty string (or NULL; I forget which) if the variable has no value. But in the case there is no variable the error condition is completely different, and may not be handled correctly by the underlying code at all.

    So bottom line: don't run this script. Downright dangerous and for very little savings.

    Instead, how about figuring out what NVRAM variables take up the most space (this is incredibly easy to figure out too!) on a per-value basis and then seeing if there's a way to minimise those? There are all sorts of text compression techniques that may work depending on what the text commonly is.

    Honestly my opinion is that 32KBytes for NVRAM is already pretty big (I don't understand how people are running out -- seriously), but I'm also fine with 64KBytes too. The crux of the problem, if you ask me, is that the authors of firmwares decide that NVRAM is a good place to store all sorts of things (like scripts, etc.) which I completely disagree with. I'm much more of the opinion that routers should come with a mandatory SD or microSD slot that be populated with something that is a full 100% writeable filesystem (JFFS would be fine). This is basically same thing as the existing USB model we have, except without the need to use USB and that mess of a stack (consider all the requirements tack on about 3MBytes of firmware space!). SD and microSD cards are pretty big now and would be perfect for storage for things like scripts or whatever else. The sooner people stop abusing NVRAM the better.

    Rant over.
  5. mstombs

    mstombs Network Guru Member

    Why does script need non volatile storage, could just use ram disk on /var/tmp? It just a temporary record what was done, and I suggest out-of -date on next router boot!

    There was a version of nvram_get that returned the name of the var if it didn't exist.

    BUT, when router boots it checks/sets some key nvram vars, I doubt it initializes empty ones. So whatever function created them before will either do it again, or not work as expected (just testing the assumptions the code makes!).

    Dual N band routers have big problem with 32kB, there are lots of core vars needed by wireless drivers which are kernel modules. Lots of nvram space can be taken up with static dhcp assignments, but the router has to write these into a dnsmasq confile file before use.

    nvram is precious, and clearly the most heavily used flash block!. Some vars used by CFE critical to operation, others just seem to be temporary used for communicating info from code to web interface, and just happen to be saved on "nvram commit".
  6. koitsu

    koitsu Network Guru Member

    FWIW, I am in complete 100% agreement that things like scripts, or "larger" pieces of information (even down to network/NIC configuration, even if it only takes up 40-50 bytes) should be stored on an actual flash-retained filesystem (e.g. JFFS) rather than NVRAM. This is how OpenWRT does it, leaving NVRAM purely for things that *absolutely* need it. I have always agreed with their approach. However, the problem with JFFS is that since its a filesystem, you end up wasting some of your flash space due to filesystem metadata and similar -- in turn, this decreases the amount of flash available for the firmware itself.

    Despite being a huge TomatoUSB/Toastman/Shibby/others advocate, I really do firmly believe that OpenWRT has a significantly cleaner, better overall design from the ground up. Their GUI ("LuCI"), on the other hand, is complete garbage (so many things were broken with it, especially the wireless GUI options/panel -- I was able to break that thing with very little difficulty). However, that said -- OpenWRT uses a "dual" filesystem method -- they use squashfs (which is read-only) for the firmware bits located in /rom, and JFFS for an "overlay" partition which literally overlays itself on top of / so you can make modifications to things and so on (e.g. scripts in /etc, yadda yadda). Their flash and filesystem layout, and also how they let you (if you want) use an external storage device (USB, SD, etc.) as your JFFS2 partition:

    And here's their filesystem documentation so you don't get too confused by all the terms being used (be sure to see the "Implementation in OpenWRT" section too):

    The "overlay" method is absolutely hands down great. However, for generic non-technical end-users, I can assure you that this would confuse the hell out of them. :)
  7. Monk E. Boy

    Monk E. Boy Network Guru Member

    I could see the overlay method being way less confusing for non-technical users, who always baffled when making changes to configuration files only to lose those changes on reboot.
  8. gfunkdave

    gfunkdave LI Guru Member

    Hey koitsu, how do you check what nvram variables take the most space? My mother in law's RT-n-12 is complaining about very low NVRAM (4.5% free) since I upgraded it to Shibby 132. Yes, I cleared NVRAM. I couldn't get the more basic IPv6-VPN build to flash (it always came back with zero NVRAM free and the router became unresponsive) so I had to use the Max build. I suspect a lot of the features I'm not using are taking up space but I'm not sure how to deal with them...

    (sorry for bumping an old was first in the Google results)
  9. mstombs

    mstombs Network Guru Member

    I don't have access to a Shibby router at the moment - but in Toastman there is an option in Administration->Debugging screen to "Download NVRAM Dump" which lets you download and see the contents as a text file.

    Example portforward and QOS rules seem to take up a lot of text of mine.

    Preferably edit the variables from router through web gui, or from command router command line as above.
    Last edited: Jan 31, 2016
  10. gfunkdave

    gfunkdave LI Guru Member

    Thanks! I was able to go from 4.9% available to about 6.1%. It seems that SSH keys and VPN keys take most of the available space.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice