ASUS RT-AC66R Firmware Version 3.0.0.4.374.726

[doubleroll]

I had the same warning. All I did was reboot and it went away...no factory reset.

Looks like the message about NTP is back...even after reset with the button on the router:

* Remind: Did not synchronize your system time with NTP server yet.

Time is correct...strange.

 

[vdemarco]

Yes, but you can save them before and restore them after using the admin site.

But if you restore the settings via the UI, then the reset to factory defaults has done nothing.

You should just write the stuff down, and reenter the values. (sorry)

 

[babgvant]

But if you restore the settings via the UI, then the reset to factory defaults has done nothing.

Are you sure?

Most of the time these sorts of recommendations are intended to get users to a "known state". If restoring the settings from a down-level cfg files undoes that, ASUS needs to document that clearly & spend some time writing validation code in the restoration logic.

 

[MrSinatra]

But if you restore the settings via the UI, then the reset to factory defaults has done nothing.

You should just write the stuff down, and reenter the values. (sorry)

Are you sure?

Most of the time these sorts of recommendations are intended to get users to a "known state". If restoring the settings from a down-level cfg files undoes that, ASUS needs to document that clearly & spend some time writing validation code in the restoration logic.

I could be talking completely ignorantly here, so it would be cool if an expert like Merlin who knew would say what is the truth, but my gut says this:

the whole point of doing a reset after a FW upgrade, on ANY device, not just a router, isn't to simply return values and settings to default (although that sure is a goal), but to actually make sure the new firmware is fully installed as well as wipes away any old residue or data from the pre-updated environment. i.e. it gives a pristine, vanilla exp.

restoring then old settings should not bring back that residue, it should be safe to do. its something I had to do with my dlink dir-655 a lot and I simply forgot about with this router.

in other words, I think it makes sense to:

1. backup settings/values
2. upgrade FW
3. reset the router (via the physical button) to be sure that the new FW has totally taken hold and replaced/removed the old FW
4. restore the old settings and values from step 1

having said all that, it should not be necessary to do this at all, asus should develop their products such that upgrading is a simple easy process, which in previous versions it has been. so I hope this does not become the new routine. but overall, I do think what I described above is safe!

feel free to let me know i'm wrong though.

 

[RMerlin]

Yes, but you can save them before and restore them after using the admin site.

Don't. Otherwise, there would be no point in resetting to factory defaults if you just reload the exact same settings that you had before, bringing you back to square one.

Loading a saved backup recreates every single settings exactly as they existed before the reset, including the low-level/internal ones not controlled by the webui.

 

[babgvant]

Don't. Otherwise, there would be no point in resetting to factory defaults if you just reload the exact same settings that you had before, bringing you back to square one.

Loading a saved backup recreates every single settings exactly as they existed before the reset, including the low-level/internal ones not controlled by the webui.

Wow. That is really, really poor design.

 

[RMerlin]

Wow. That is really, really poor design.

That is perfectly normal. If you have a virus on your computer, create a disk image of your PC using Acronis True Image, reformat it, then restore that image, you will get the exact same result - virus will be back.

The idea of a backup is to have a copy of ALL settings, in case your router loses its configuration. If the goal is to get rid of some old settings, this method won't work. AFAIK, every router out there has the same limitations.

Ideally, what you are looking for would be a selective restore. Implementing this in a user-friendly way is kinda tricky, as you wouldn't know which settings need to be cleared and which can be safely restored. The closest thing you do is to make a text-based backup of your settings:

nvram show > /mnt/sda1/some_usb_disk

After clearing your settings simply open the text file on your PC, then browse through it to locate the important settings, and manually restore them (again, over telnet). For example, for the static DHCP list:

nvram set dhcp_staticlist="what_you_had_in_the_text_backup"
nvram commit

Someday, I might go ahead and write a script that would at least take care of the most annoying settings (DHCP reservations, port forwards, etc...). Time, unfortunately, is a limited resource

 

[MrSinatra]

hi Merlin,

I just thought i'd let you know that I followed the steps I laid out in my previous post before seeing your posts, and I was screwed anyway.

what I mean is: i backed up my "130" config, installed the new FW, did a reset, and then tried to restore the backup.

i was kinda shocked to see that NOTHING restored. it was completely ignored.

so that's my warning to anyone out there, you will lose everything.

as to the convo, like i said, you could restore on a dir-655 after fw upgrade.

and it seems to me its just a matter of setting/values/prefs. when you do the reset, the point is to do more than just wipe those away, right? so, to me anyway, it does make sense to back them up / restore them after a FW update (with the exception of anything that's no longer there of course)

 

[babgvant]

That is perfectly normal. If you have a virus on your computer, create a disk image of your PC using Acronis True Image, reformat it, then restore that image, you will get the exact same result - virus will be back.

I'm not convinced that it's normal, many settings save/restore mechanisms are not all-or-nothing. I haven't looked at the code/distro ASUS uses, but I'm reasonably familiar with embedded Linux programming and it's certainly possible to implement a more intelligent mechanism for managing settings.

Using an image based backup for this purpose was a bad design choice. It reduces portability, and makes the feature mostly useless except in one - quite limited - use case. Personally I prefer to use an XML based mechanism because it's human readable, and easy to perform runtime validation (XSD). If they had selected that implementation over the current one it would be simple to ensure that invalid values are not used. There, are of course, other approaches that are equally valid. The point is that using a poor design leads to poor results - in this case UX suffers.

 

[got_milk]

I'm not convinced that it's normal, many settings save/restore mechanisms are not all-or-nothing. I haven't looked at the code/distro ASUS uses, but I'm reasonably familiar with embedded Linux programming and it's certainly possible to implement a more intelligent mechanism for managing settings.

Using an image based backup for this purpose was a bad design choice. It reduces portability, and makes the feature mostly useless except in one - quite limited - use case. Personally I prefer to use an XML based mechanism because it's human readable, and easy to perform runtime validation (XSD). If they had selected that implementation over the current one it would be simple to ensure that invalid values are not used. There, are of course, other approaches that are equally valid. The point is that using a poor design leads to poor results - in this case UX suffers.

Consumer routers don't have that much NVRAM available. An XML document would be far too large to store. Compactness is key.

 

[babgvant]

Consumer routers don't have that much NVRAM available. An XML document would be far too large to store. Compactness is key.

I'm not sure that's entirely accurate (ie there's more than one way to load an XML document), but more importantly critiquing an offhand implementation misses the points - probably also worth rereading the part about other equally valid approaches (XML was just one option). Features should be implemented in a way that maximizes their value. Persisted settings isn't a complicated thing to do. Validation is important.

The current design is limited and flawed both because it isn't portable b/w FW versions and because it doesn't enforce that artifact (if there are breaking changes b/w versions it should refuse to apply settings files created by an incompatible FW).

 

[RMerlin]

XML is just a way of storing data in a hierarchical method. It's completely unrelated to the issue at hands - the router would still have no way of knowing if a given value in the restored backup is a correct value, or not.

Let's take a concrete example. Let's say that there is an nvram value that sets a clock frequency to 600 MHz. The manufacturer finds out that 600 MHz is not stable, so decide to default to 580 MHz instead with a new firmware. So they recommend people reset to factory default, which means the setting will then get the proper default value of 580 MHz. If you restore a saved backup, you get your clock once again at 600 MHz, meaning your stability issues will not be resolved. Having the backup stored as binary or XML doesn't change anything - the router will still read from the backup that "clock=600", and would reapply that incorrect value. The storage format is totally irrelevant.

This is the real issue why you cannot restore a saved backup. If a low-level default value was changed in a new firmware release, the router has no way of telling if the value it would be about to apply from that backup is valid or not. Having the value stored as binary, plain text or XML in the backup would change nothing. XML is nothing but a data storage format.

 

[MrSinatra]

hi Merlin,

I follow what you are saying, but the backup/restore facility should only apply to what the user can setup/specify, imo. in other words, the only valid info in a restore operation would be those values which are valid to the new firmware user settings/prefs.

I liken this whole thing as similar to a BIOS upgrade, when sometimes you had to pull the battery out, etc, to get the new BIOS revision "fully implemented." this seemed to do with things beyond user settings.

some newer overclocking things (beyond my paygrade) allow you to save settings, update the bios, reset, and restore the settings.

so anyway, I guess what I am trying to say is that the backup/restore function should only apply to whats exposed to the user, and not other settings, imo. it really should be a txt ini type file.

 

[babgvant]

XML is just a way of storing data in a hierarchical method. It's completely unrelated to the issue at hands - the router would still have no way of knowing if a given value in the restored backup is a correct value, or not.

Taken on its own, you are correct. XML is just a way to structure data. That said, there exist a set of supporting technologies to validate (XSD) and transform (XSLT) XML data which can facilitate a solution to this problem.

To be clear, XML data storage is just a potential solution. It is not the only valid approach. There may even be approaches better suited to the hardware limitations of these devices. The problem here is that there doesn't appear to be any validation of user provided input. Which is poor design and limits the usefulness of the backup/restore feature.

Let's take a concrete example. Let's say that there is an nvram value that sets a clock frequency to 600 MHz. The manufacturer finds out that 600 MHz is not stable, so decide to default to 580 MHz instead with a new firmware. So they recommend people reset to factory default, which means the setting will then get the proper default value of 580 MHz. If you restore a saved backup, you get your clock once again at 600 MHz, meaning your stability issues will not be resolved. Having the backup stored as binary or XML doesn't change anything - the router will still read from the backup that "clock=600", and would reapply that incorrect value.

Yes. Unvalidated data in any format, is unvalidated data. The application of unvalidated data from user space is bad and can lead to poor results. There are many ways to approach this problem, XML is just one.

For e.g. say we have the setting document below:

<root>
<clock>600</clock>
</root>

If this document was validated w/ XSD prior to application the developer would just change the schema def such that 600 was no longer a valid value. (Note this is unnecessarily verbose).

...
<xs:element name="clock">
   <xs:simpleType>
      <xs:restriction base="xs:integer">
         <xs:minInclusive value="580"/>
         <xs:maxInclusive value="580"/>
      </xs:restriction>
   </xs:simpleType>
</xs:element>...

It is also possible to use XSLT to reset/remove values if they should now be ignored. So stripping out <clock> or changing it to 580 if the current value != 580 are both simple tasks.

Again, this isn't strictly the domain of XML, it's just one potential solution to validate user input in a structured way. Any mechanism where data can be serialized, deserialized and validated will work - pick your favorite (JSON is another popular method). The important part is that any data that has been to userland gets checked - not doing that is poor design. This is a basic "best practice" of software development, it confuses me that anyone would argue this point.

If a low-level default value was changed in a new firmware release, the router has no way of telling if the value it would be about to apply from that backup is valid or not.

I disagree with this completely. Sanity checking values is a fundamental part of writing good software. Values that users shouldn't touch, shouldn't be persisted (what's the point if they aren't portable and only cause problems?). Anything they can touch should be validated before reapplication.

There are myriad methods to accomplish this, XML is just one. The problem here is that the mechanism to save/restore settings is implemented in a way that makes it not terribly useful. Fixing that isn't complicated.

 

[goldswimmerbj]

Is it worth upgrading from Rmerlin to this?

 

[RMerlin]

I disagree with this completely. Sanity checking values is a fundamental part of writing good software. Values that users shouldn't touch, shouldn't be persisted (what's the point if they aren't portable and only cause problems?). Anything they can touch should be validated before reapplication.

Except in the example I gave, it's not about sanity checking. 580 and 600 are both perfectly valid values - it's just that the manufacturer would have changed the default value. If you blindly set it back to 580, and the user wants to overclock to 600 (or 610), restoring his saved backup will set it back to 580, leaving the user annoyed at the fact that the settings he chooses are being overridden by the firmware. That means he can no longer rely on reusing a backup, as the router would arbritrarily override some of his configuration.

Another issue that was previously unmentioned: there is currently (on my own router) no less than 2040 different nvram settings. Good luck handling that in an efficient manner with an XML file. The hours (if not days) of engineering time involved in not only developing but also maintaining all that data management will offset the 15 mins it would take you, as a user, to manually reconfigure your router. This is just not worth it resource-wise.

And internally there is no way you are going to be able to store 2040 different settings and all the associated overhead in a 64 KB storage area. My router currently uses over 48 KB out of 64 KB. Got any estimate of the overhead involved in XML? You can bet that if you wanted to also use XML for internal storage, you would never even fit half of the current settings in those 64 KB, so that means the internal storage would still need to remain binary-only.

Finally, the BIOS analogy was mentionned. BIOS works exactly the same way the current router firmwares do. In fact, my recent FW updates on this new motherboard automatically reset all my settings back to factory defaults, and erased all my saved profiles. The current router situation is what is being used industry-wide with low-level settings management. There is nothing unusual with it, and "fixing" it isn't just a matter of "let's just save this as XML". It's far, far more complex than this, and an actual solution to the problem would leave you with such a complex piece of code that it's simply not worth the development effort versus what you would gain from it. Plus the very strong chance of creating a whole new set of bugs to troubleshoot and fix as you make changes to your internal settings.

In software, the KISS principle should be paramount. If more developers stuck to it, modern software wouldn't be the general disaster that it has turned into, as software developers implement bazillions of features, make code insanely complex, quite often just for very trivial features or features that nobody would really benefit from.

 

[RMerlin]

Is it worth upgrading from Rmerlin to this?

Depends on what features you need out of my FW.

 

[MrSinatra]

Merlin,

why would the backup save prefs/settings and so on that are not exposed to the user in the first place?

a restore should not apply to your internal values of 500/580/600 example.

 

[babgvant]

Except in the example I gave, it's not about sanity checking. 580 and 600 are both perfectly valid values - it's just that the manufacturer would have changed the default value. If you blindly set it back to 580, and the user wants to overclock to 600 (or 610), restoring his saved backup will set it back to 580, leaving the user annoyed at the fact that the settings he chooses are being overridden by the firmware. That means he can no longer rely on reusing a backup, as the router would arbritrarily override some of his configuration.

But the backup is mostly useless now, as it stands, because there's no effort to validate the values across FW revisions. Weighing inconvenience against useless, for me, inconvenience trumps.

Even a simple check like "can I safely apply this cfg file created w/ X FW" would be a big step forward. The current situation just lets you do things that ASUS knows aren't right.

Another issue that was previously unmentioned: there is currently (on my own router) no less than 2040 different nvram settings. Good luck handling that in an efficient manner with an XML file. The hours (if not days) of engineering time involved in not only developing but also maintaining all that data management will offset the 15 mins it would take you, as a user, to manually reconfigure your router. This is just not worth it resource-wise.

15 min * X number of users = some number that is usually greater than the development effort.

This is not that different than the math that drives SW development (how I, and I imagine, you, get paid). Spend 2 hours dev time automating a 10 min user task, saves $ & time in the long run.

Generating validation code doesn't have to be time consuming. A little bit of regex knowledge and good upfront planning goes a long way here.

And internally there is no way you are going to be able to store 2040 different settings and all the associated overhead in a 64 KB storage area. My router currently uses over 48 KB out of 64 KB. Got any estimate of the overhead involved in XML? You can bet that if you wanted to also use XML for internal storage, you would never even fit half of the current settings in those 64 KB, so that means the internal storage would still need to remain binary-only.

This XML discussion has become a discourse in forest v. trees selected, because as demonstrated, it's simple to sort this kind of problem. If there's a HW limitation that makes XML inappropriate, that's development - it was just an e.g. - choose another mechanism. Store & validate using bit bashing if that is all the HW is capable of.

The important part is that it gets validated when applied. The lack of validation and storing everything, even the stuff that the user hasn't changed, makes the current feature almost useless.

In software, the KISS principle should be paramount. If more developers stuck to it, modern software wouldn't be the general disaster that it has turned into, as software developers implement bazillions of features, make code insanely complex, quite often just for very trivial features or features that nobody would really benefit from.

KISS doesn't mean being lazy. Not validating user input is lazy and dangerous. It is poor SW design and inconsistent with good development practices.

 

[goldswimmerbj]

Depends on what features you need out of my FW.

All i use your firmware for is the additional monitoring of the router, I dont ever use Aicloud so i guess ill skip this update, unless it offers some amazing speed boost.