Tomato 1.28 to Toastman mod

Discussion in 'Tomato Firmware' started by Releak, Jul 13, 2012.

  1. Releak

    Releak Serious Server Member


    I have been searching and reading more than 10 topics, and Googled for hours to try and find the proper method to upgrade from Tomato 1.28 vanilla to the Toastman mod on my WRT54GL 1.1 router.

    It seems I first have to erase the nvram memory [] , and I can then use the upgrade feature under "administration" []. Can I have this confirmed by someone so that I do not accidentally brick my precious router?

    Or maybe I have to go back to stock firmware?

    I am planning to use the standard tomato-WRT54G_WRT54GL-1.28.7633.3-Toastman-IPT-ND-Std, which I assume is the right build for my router.
  2. Toastman

    Toastman Super Moderator Staff Member Member

    Upgrade from the Tomato GUI - erase nvram. Don't use your old config file, reconfigure from scratch.
  3. Releak

    Releak Serious Server Member

    Oh, a response from the author himself. Very suprising :)

    I successfully upgraded to your mod. However, I doubt erasing the nvram is any necessary? When I first erased the nvram all settings was restored to default. I then upgraded using the administration -> upgrade menu. I read a lot of your other topics and saw you recommending erasing the nvram, but is this really needed and why?

    They aren't cleaned during a flash or? If one does it before or after a flash shouldn't matter either, right?

    I did not use the config file from the vanilla version, but reconfigured from scratch.
  4. Releak

    Releak Serious Server Member

    I specifically applied this mod to use the bandwidth limiter, and it works freaking flawlessly. So awesome thank you Toastman.
  5. koitsu

    koitsu Network Guru Member

    Erasing the NVRAM (doing a "thorough erase") absolutely is necessary. I don't know where you got the impression it isn't. Just because something works without doing it doesn't mean it's going to work the next time you upgrade. Let me explain:

    1. NVRAM variable values may change in syntax, or may change in value altogether. E.g. that network interface called "vlan0" in one version might be called "eth0.1" in another,

    2. NVRAM variable names may change completely. This is a regular issue especially when switching between firmware "brands" (e.g. going from DD-WRT to OpenWRT to TomatoUSB), but can also happen when upgrading to a new version number of a firmware (e.g. TomatoUSB 1.27 to 1.28). This has already bit people when switching between things like TomatoUSB Toastman to TomatoUSB Teaman; some variables there are not named the same between both firmwares. There is no universal naming standard for variables. You can make one called "bob_snakes" if you want and tie in code/shims to use that variable as well, but there's no guarantee OpenWRT (for example) or even an upgraded version of the same firmware you're running would work with it.

    A "thorough erase" basically erases all the NVRAM variables that TomatoUSB (or any third-party firmware) puts in place and only leaves the ones the router comes with out-of-the-box (i.e. the factory defaults). This ensures that after doing a firmware upgrade there won't be any "leftover cruft" in NVRAM that could break things for you later.

    Backing up your configuration (to a file) and then restoring it after an upgrade doesn't help either of the above cases (I'm sure you can figure out why). Backing up/restoring a config is perfectly fine to do as long as you aren't changing firmware version or firmware "brand" -- it'll Just Work(tm).

    There are ways to solve this problem with technology, but they are tedious and difficult (painful) to maintain (for the coders/authors). It involves storing what version of firmware you're using in the actual config backup, then code in the new firmware version would have to parse that and have a bunch of "upgrade conversion" routines to convert old interface names/variables/etc. into the new ones. It's tedious as hell and for something as generic as a consumer-grade home router, this really isn't plausible. It also would bloat the firmware every single release.

    The bottom line is that you should keep a text file around with all of the settings you change from the stock defaults. This is what I do, and it has never, ever failed me.

    Make sense?
  6. Releak

    Releak Serious Server Member

    Thank you koitsu for taking your time to explain me this :)

    I did make a backup of the config file from the vanilla version, just in case I wanted to return to that version and have the opportunity to import my settings. I did not import it into Toastman's mod so that is good.

    When I erased the NVRAM "thoroughly" did that mean I was returning to the default settings of Tomato 1.28, or the Linksys stock firmware default settings?
    I understand what you said, but I still don't understand whether erasing the NVRAM before or after an upgrade makes a difference.

    I erased the NVRAM memory and returned to default settings (of Tomato 1.28 I assume, and not the Linksys stock firmware), which means I'd carry the default settings over to the Toastman mod. So does that now mean I have the default settings of Tomato 1.28 vanilla on my Toastman mod, and should have done the erase of the NVRAM memory after the update?

    Thanks this is awesome feedback!
  7. koitsu

    koitsu Network Guru Member

    I'm having a hard time following all of this. Politely: it's not my responsibility to keep track of what firmware you use, what version, when (meaning at what point) you erase NVRAM, or what erase method you use. It becomes too tedious for me to track these kinds of usage patterns -- sorry.

    Admin -> Configuration -> Restore Default Configuration has two options: "Restore default router settings (normal)" and "Erase all data in NVRAM memory (thorough)". This is what I understand to be correct:

    The first option will set all of the NVRAM variables which the active firmware version uses to whatever the firmware version itself considers default values. Meaning, NVRAM settings from other firmware "brands", etc. will still remain intact. E.g. if OpenWRT makes an NVRAM variable called "balls", choosing this pulldown option will not get rid of it. So any leftover cruft will not get removed.

    The second option will clear NVRAM contents completely (I believe using the "nvram erase" command), and then proceeds to set all NVRAM variables which the active firmware version uses (just like in the first option). This gets rid of any leftover cruft from other firmware "brands", or previous firmware versions (if NVRAM variables are renamed, etc.), and makes sure that important settings (like boot_wait) get restored.

    Alternately I can go look at the actual code to see what the actual behaviour is, but it's a lot easier to just rely on someone who's already familiar with it (Toastman, Teaman, Shibby, etc.) who can confirm/deny my above statements.

    Regardless, hopefully this will allow you to answer your own question.

    The bottom line is that every time you change firmware "brands", or upgrade versions of the same "brand", you need to do the "thorough" method, otherwise leftover crap remains in NVRAM which some underlying code of the firmware could trigger off of (and behave oddly as such). There's too many variables/conditions where this could be true; one cannot track them all. For example I know factually, first-hand, that going from the stock Asus RT-N16 firmware to DD-WRT then to TomatoUSB often results in the router behaving like its bricked. This is because of the NVRAM variable situation I've described above (specifically, there are probably NVRAM variables which TomatoUSB relies on which DD-WRT also relies on, yet they use different syntaxes; such things like interface names would be an example). Again, I've experience this first-hand, and a colleague of mine just recently ran into this himself less than 2 weeks ago.

    The same advice applies when going from something like Tomato -> TomatoUSB. The two firmwares share a lot of NVRAM variables, no argument there, but there is no guarantee that it will always be this way. Do the thorough reset every time and manually re-configure the router by hand every time and you'll be fine.
  8. azdps

    azdps LI Guru Member

    Releak, when you "Restore default router settings" you are restoring the default settings of whatever firmware you are using. In your case, when you restored the settings it was the Tomato firmware default settings. It has nothing to do with any previous firmware you had installed. The "Restore default router settings" is typically used when you start changing settings in your router and you want to start over from scratch using the default settings of the firmware you have installed.

    When you "Erase all data in NVRAM memory" you are actually restoring default settings and more. For instance, if you have custom NVRAM entries that you made those will be completely erased from memory, and the entry plus the settings for the entry, will be completely erased and will no longer exist. This usually should be done when switching between different types of firmwares because they may have NVRAM settings that don't exist in the firmware you may be installing on your router.
  9. Releak

    Releak Serious Server Member

    So this "bricked" behavior all happened because you did not erase the NVRAM memory? Did you solve it? I am just curious now :)

    So this means that erasing the NVRAM has to be done after an update and not before. In my case I erased the NVRAM before I did the update, so that is a bad thing. Everything seems to work just fine though, but should I erase the NVRAM now then and reconfigure from scratch?

    Thank you both for clarifying it!
  10. fubdap

    fubdap LI Guru Member

    @Releak - This is what you should do every time you upgrade - check the box.

  11. koitsu

    koitsu Network Guru Member

    Yes, the solution was to use the 30-30-30 method labelled "Hard reset".
  12. Releak

    Releak Serious Server Member

    In Tomato 1.28 vanilla that box does not exist :) ... Hence one of the reasons I am asking so much about the NVRAM
  13. koitsu

    koitsu Network Guru Member

    It looks like this (as I described in my earlier post), does it not?

    Attached Files:

  14. Releak

    Releak Serious Server Member

    Yes that is true koitsu
  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