1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Potential fix for NVRAM corruption?

Discussion in 'Tomato Firmware' started by ringer004, Sep 8, 2009.

  1. ringer004

    ringer004 LI Guru Member

    I've been reading these threads for some time now (they are a great resource!) and I've noticed a common theme which seems to occur. It seems the NVRAM image can get corrupted and the router starts to behave very erradically.

    In my line of work, I do a lot of mission critical S/W. In mission critical S/W, if an NVRAM image is really important, you keep a second copy of it for a backup. The theory is that both copies are not likely to get corrupted at the same time. If they do, you likely have a much bigger problem to deal with.

    My NVRAM dump of Tomato S/W in ASCII form is ~8K bytes. I believe the size of the NVRAM is 32K bytes? In compressed form, the image is less than 4K.

    So there is plenty of room to store a second copy of the NVRAM image. Store both (identical) images with a 32 bit CRC. At power up, read both primary and secondary images. If one of the images fails its CRC check, resave that image from the good one. And then obviously just use the image with the good CRC.

    If both images fail the CRC check, then you are no worse off than the current implementation.

    Any thoughts, questions, or comments would be welcome...
  2. rhester72

    rhester72 Network Guru Member

    NVRAM "corruption" is rare on the order of nonexistent. The real issue is that a) major firmware upgrades may use differently-named NVRAM variables for the same function (or, worse, use the *SAME* name for a _different_ function - hello, DD-WRT!), or b) people try to reuse NVRAM variables between different sets of hardware (which will very nicely goof up things like internal VLAN definitions, often bricking the router!).

    The "right" solution to this, of course, is to a) completely abstract the hardware and VLAN definitions and b) use an immutable, cross-platform method of defining these variables. OpenWRT solved these problems by moving away from NVRAM entirely (a good thing, since some hardware doesn't have any!) and using standardized text configuration files instead.

    Then again, OpenWRT is *still* feeling the growing pains of this shift in direction (nearly two years later!), and it was more paramount for them because of the wider base of hardware support (and more achievable due to the FAR larger developer base). It's not as much of a factor for a smaller, much more limited-scope project like Tomato with a single primary developer, though the pitfalls of NVRAM management do bite from time to time. I have yet to see a full NVRAM clear fail to solve such issues.


Share This Page