Why need to manually re-enter settings after 3.0.0.4.220?

[tbessie]

People are saying here that, after upgrading the firmware to 3.0.0.4.220, you should manually re-enter all your settings.

This is kind of sucky if you have an hour or two's work to do so. Rather than have a copy of nvram as the saved settings file, why doesn't the router have, say, an XML file with all the settings saved that way, so that you could always used a previously saved settings file with WHATEVER file nvram is available? In 2012, making router settings files be a copy of memory (which is what I'm assuming is going on here) is ridiculous.

Is everyone SURE that's what this file is, and that manually reentering settings is really required?

- Tim

 

[WilliamY]

People are saying here that, after upgrading the firmware to 3.0.0.4.220, you should manually re-enter all your settings.

This is kind of sucky if you have an hour or two's work to do so. Rather than have a copy of nvram as the saved settings file, why doesn't the router have, say, an XML file with all the settings saved that way, so that you could always used a previously saved settings file with WHATEVER file nvram is available? In 2012, making router settings files be a copy of memory (which is what I'm assuming is going on here) is ridiculous.

- Tim

+1. I too don't understand this whole re-entering setting process, not only Asus firmware but also Tomato or other 3rd parties.

 

[KevTech]

Firmware upgrades most of the time involve changes which would make a setting file incompatible.


For example, you may have a firmware upgrade with changes made to the wireless radios and after you upload your old setting file the setting are not "in tune" with the changes so you end up with low connection speeds.

 

[DaveMishSr]

People are saying here that, after upgrading the firmware to 3.0.0.4.220, you should manually re-enter all your settings.

This is kind of sucky if you have an hour or two's work to do so. Rather than have a copy of nvram as the saved settings file, why doesn't the router have, say, an XML file with all the settings saved that way, so that you could always used a previously saved settings file with WHATEVER file nvram is available? In 2012, making router settings files be a copy of memory (which is what I'm assuming is going on here) is ridiculous.

Is everyone SURE that's what this file is, and that manually reentering settings is really required?

- Tim

It is because you want to start with a clean NVRAM. The settings for your configuration are stored in the NVRAM. If there is a corruption in the settings file it will carry over when you restore it. Also, someone already mentioned the compatibility issue when flashing from one platform to another (i.e.: Asuswrt to Asuswrt-merlin to TomatoUSB or any combination thereof). So a settings file for Asuswrt will not work on TomatoUSB and restoring settings in Asuswrt-merlin from a file created in Asuswrt could lead to problems also. It is always wise to manually re-enter all settings when crossing over from one firmware to another, and not simply upgrading versions of the same firmware, so as to make sure that your NVRAM will not contain any corruptions and/or compatibility errors.

 

[tbessie]

I think you're not getting the point...

Hey all...

With regards to my question - I think you're not quite getting the point I'm trying to make.

I've written a lot of software over the years, and when moving from Version X to Version X+1, an upgrade path is usually established for settings as well.

In order to do so, the settings file should be saved to a file in an externalizable format (eg. XML) that is Version-agnostic, insofar as a file saved from software/firmware Version X, and read with Version X+1, with various filters being applied by the software/firmware version to accommodate for changes that may have been made in the meanings of the settings.

That is, the XML is parsed, and an internal mapping table is maintained by the software/firmware, that maps old settings to new settings (one-to-many, many-to-one, or settings that may no longer have a meaning in the new version being noted).

An intelligent settings upgrade methodology such as this does not need to depend upon the "clear everything and enter everything from scratch by hand" voodoo you folks are talking about.

I'm sure the programmers at Asus know that a given setting for a firmware at Version X maps to another setting/group-of-settings/lack-of-a-setting in Version X+1 (or even X+N). They could implement this knowledge in the firmware, so that we as users wouldn't be forced to do this silly clear/re-entering stuff.

If the settings file is merely a binary copy of what's sitting in NVRAM, that is just BAD PROGRAMMING PRACTICE, and points to lazy engineers. Unless there is some physical limitation (eg. having a parser in the firmware to parse an externalizable format settings file would take up too much memory, for instance), this should be done whenever possible. There ought not be a need to "copy" one settings file in-place into where the new one lives. It should be parsed, interpreted, and converted into whatever format and settings the new firmware version uses.

Just my opinion, of course, but, again, in 2012 we should be beyond the "clear and re-enter" voodoo we're told to do.

- Tim

 

[RogerSC]

Yes, ideally all that could be done. But keep in mind, we're talking about programmers here that have all they can do to avoid generating new firmware bugs when they fix old ones. I wouldn't expect all that setting manipulation software to work if written by those programmers *smile*. I wouldn't trust it, anyways.

 

[RMerlin]

An XML-based config would only be useful when the nvram format change. And as far as I can remember, the RT-N66U was the first time I ever heard of a router requiring a new nvram format during an update. So there's no point in implementing an XML format just for that one time exception that will probably never happen again. It would be of no help for the far more typical scenario where you don't want to re-apply older settings as they might no longer be valid with newer firmware code.

 

[tbessie]

An XML-based config would only be useful when the nvram format change. And as far as I can remember, the RT-N66U was the first time I ever heard of a router requiring a new nvram format during an update. So there's no point in implementing an XML format just for that one time exception that will probably never happen again. It would be of no help for the far more typical scenario where you don't want to re-apply older settings as they might no longer be valid with newer firmware code.

In other routers that had the same "save/restore NVRAM" methodology, I've definitely seen quite a few times they've said to re-enter things from scratch, so I've hit this situation more often than I'd like.

Implementing an externalizable format, like XML, WOULD be of help for the scenario where you don't want to re-apply older settings. If they no longer apply 1) because they don't exist, then the settings upgrade code would know this and reject inapplicable settings in the XML file, and if 2) because it still exists in the new firmware, but you only had it because of some other way the firmware worked, say - then you'd just need to upload your settings, and unset those particular ones that you wouldn't want set anymore.

In the 2nd case, there probably would be far more settings you WOULD want to preserve than those you wouldn't; for example, I have 20-50 reserved MAC->IP settings; having to enter those again is absurd, if it's because some other setting changed (or the size of the NVRAM changed, like this time). If a setting I didn't want set this time 'round was there, I'd upload my old settings, and unset that 1 (or several) settings. Much easier than re-entering 50 IP reservations, for example.

- Tim

 

[tbessie]

Yes, ideally all that could be done. But keep in mind, we're talking about programmers here that have all they can do to avoid generating new firmware bugs when they fix old ones. I wouldn't expect all that setting manipulation software to work if written by those programmers *smile*. I wouldn't trust it, anyways.

Yes, I would agree that THAT is a good point.

- Tim

 

[RMerlin]

In other routers that had the same "save/restore NVRAM" methodology, I've definitely seen quite a few times they've said to re-enter things from scratch, so I've hit this situation more often than I'd like.

Implementing an externalizable format, like XML, WOULD be of help for the scenario where you don't want to re-apply older settings. If they no longer apply 1) because they don't exist, then the settings upgrade code would know this and reject inapplicable settings in the XML file, and if 2) because it still exists in the new firmware, but you only had it because of some other way the firmware worked, say - then you'd just need to upload your settings, and unset those particular ones that you wouldn't want set anymore.

In the 2nd case, there probably would be far more settings you WOULD want to preserve than those you wouldn't; for example, I have 20-50 reserved MAC->IP settings; having to enter those again is absurd, if it's because some other setting changed (or the size of the NVRAM changed, like this time). If a setting I didn't want set this time 'round was there, I'd upload my old settings, and unset that 1 (or several) settings. Much easier than re-entering 50 IP reservations, for example.

- Tim

Every time they say to re-enter settings from scratch (aside from the unique RT-N66U situation), it's generally not because of nvram format change, but because settings names/structure have changed. In these cases, an XML format won't help you. And writing code that handles a transition is a PITA, because for starter you don't know for sure from which version they are coming from. They could be downgrading. Or skipping multiple versions. And if you start implementing config version numbers, you end up with a pretty messy piece of code after a few firmware revisions, very prone to introducing issues. I've been through that myself before (writing code that could handle upgrading older config settings), and quickly started getting pretty hairy.

The simpler you keep it, the most solid your code will be.

Two simple commands will allow you to easily export and re-import those long forward or static DHCP entries. For example:

nvram get vts_rulelist > /mnt/sda1/portlist.txt
nvram get dhcp_staticlist > /mnt/sda1/dhcp.txt
...
nvram set vts_rulelist="`cat /mnt/sda1/portlist.txt`"
nvram set dhcp_staticlist="`cat /mnt/sda1/dhcp.txt`"

There. I just saved, and restored the two most tedious settings.

 

[tbessie]

Every time they say to re-enter settings from scratch (aside from the unique RT-N66U situation), it's generally not because of nvram format change, but because settings names/structure have changed. In these cases, an XML format won't help you. And writing code that handles a transition is a PITA ...

Sure, it's a PITA, but I still feel it could be done. Of course, I don't know the structure of the NVRAM settings file, nor how much it changes for each upgrade, but I believe it could be done, and mapping tables to go between versions COULD be done, given enough forethought. So we'll have to agree to disagree on that point.

Two simple commands will allow you to easily export and re-import those long forward or static DHCP entries. For example:

...

There. I just saved, and restored the two most tedious settings.

If that is true, then thank you - which memory are those files stored in, assuming a hard-reset (according to Asus's instructions) were done in between? Wouldn't it be cleared, too, if I cleared NVRAM and did a firmware upgrade in between? Or is the basic filesystem data maintained between resets and firmware upgrades?

- Tim

 

[RocketJSquirrel]

If that is true, then thank you - which memory are those files stored in, assuming a hard-reset (according to Asus's instructions) were done in between? Wouldn't it be cleared, too, if I cleared NVRAM and did a firmware upgrade in between? Or is the basic filesystem data maintained between resets and firmware upgrades?

RMerlin is suggesting you redirect the output of the "nvram get" commands to an attached USB drive.

 

[tbessie]

RMerlin is suggesting you redirect the output of the "nvram get" commands to an attached USB drive.

D'oh! Sorry about that, I didn't look at the target of the redirect; just assumed it was a local file. I haven't used the USB port on the router yet.

- Tim

 

[darknight]

Every time they say to re-enter settings from scratch (aside from the unique RT-N66U situation), it's generally not because of nvram format change, but because settings names/structure have changed. In these cases, an XML format won't help you. And writing code that handles a transition is a PITA, because for starter you don't know for sure from which version they are coming from. They could be downgrading. Or skipping multiple versions. And if you start implementing config version numbers, you end up with a pretty messy piece of code after a few firmware revisions, very prone to introducing issues. I've been through that myself before (writing code that could handle upgrading older config settings), and quickly started getting pretty hairy.

The simpler you keep it, the most solid your code will be.

Two simple commands will allow you to easily export and re-import those long forward or static DHCP entries. For example:



There. I just saved, and restored the two most tedious settings.

Of course its not easy and a PITA, but the same can be said for good software design.

The real reason this doesn't happen is because there is really no pressure from the average consumer who will never even think about the version of the firmware on their router.