ASUS RT-AC68U Firmware version 3.0.0.4.378.4376

[maximvd]

here's the changelog:

ASUS RT-AC68U Firmware version 3.0.0.4.378.4376
Security related
- Upgrade OpenSSL library to 1.0.0q
- Fixed CVE-201301813
- Fixed the XSS vulnerability on page Main_Analysis_Content.asp

AiProtection fixes
- Fixed router reboot issue when disabled AiProtection
- Fixed kernel panic when wan reconnected
- Modified web history strings
- Updated signature to 1.030
- Optimize memory usage

Other
- Added Movistar profile in IPTV setting page

http://www.asus.com/be-nl/Networking/RTAC68U/HelpDesk_Download/

 

[texashoser]

Thanks. Looks like they are still updating their US-based support site. Still listed as Japanese-only for Windows 7 downloads...

 

[S_D]

No longer listed as JP only on the international site (Win8.1 download section), but not picking it up from the firmware auto update feature.

 

[texashoser]

I know the rule of thumb is to reset to factory default after each FW upgrade, but you definitely need to do it on this one.

NTP, the network map, and quite a few other things are borked without resetting back to defaults after upgrade.

 

[uwish]

might be a silly question BUT after resetting to factory, can you then load a saved config file in the new firmware version?

I have tons of changes and port forwarding and I really don't want to go through and add them all again....

 

[texashoser]

might be a silly question BUT after resetting to factory, can you then load a saved config file in the new firmware version?

I have tons of changes and port forwarding and I really don't want to go through and add them all again....

That's what I typically do.

 

[john9527]

Definitely NOT a good idea to restore a saved settings after a factory reset for a firmware upgrade. Merlin wrote up a 'sticky' explaining everything you should read....

http://forums.smallnetbuilder.com/showthread.php?t=22822

 

[texashoser]

Definitely NOT a good idea to restore a saved settings after a factory reset for a firmware upgrade. Merlin wrote up a 'sticky' explaining everything you should read....

http://forums.smallnetbuilder.com/showthread.php?t=22822

Don't necessarily buy this. First, applying the same settings manually will write into nvram mostly the same values you are writing by uploading the saved config file. And it depends FW by FW load which values may be outdated or depreciated. It depends on features you've enabled/configured, too. I just don't believe that reloading a saved config after a factory reset gets the device into exactly the same state as if it weren't reset in the first place.

Besides, the fact that a system is this buggy requiring you to manually reconfigure a device is a massive failure in of itself. Any outdated/deprecated parts of a saved config when loaded into a newer FW should simply be ignored and release notes should be written to specifically explain which new/old parts of firmware need manual reconfiguration to avoid issues. I mean, how does Cisco pull this off? Manually entering a config via the CLI is exactly the same as copying and pasting the text. If there is a feature that isn't supported by the firmware, you'll get a warning when entering that specific line of config.

As per Merlin, the release notes are supposed to tell you when a reset is needed. This new one doesn't require that - at least according to the notes... Which we all know are woefully inadequate, of course.

My case is proof-positive that reloading a saved config after a FW update and reset doesn't just get you back into the same situation. After upgrading to this FW, the network status page showed both the primary and secondary WAN's as being disconnected even though the primary WAN interface was working. NTP was hosed and displayed an invalid date. Logs were showing all sorts of errors.

I updated with a saved config, rebooted, and all the above went away.

In short, having to perform an nvram reset and manual reconfig after every FW update is laughable and a crappy way to design a product.

To sum up, after an update, see if your device is working as expected and any bugs you had are now gone or at least not made worse. If you encounter bugs and weirdness, then try uploading a saved config. The last thing you should try is reentering the entire config from scratch - not the first thing - even if it's what is ultimately required.

Sorry, I just don't have much patience for quirky products.

 

[john9527]

As with anything, you are free to proceed as you see fit. I was only providing information on the way the product is currently architected and the way it's meant to be managed.

 

[texashoser]

As with anything, you are free to proceed as you see fit. I was only providing information on the way the product is currently architected and the way it's meant to be managed.

Correct. I shouldn't shoot the messenger.

But aside from my problems with the product, I just don't believe that restoring a saved config after a FW update gets you to exactly the same state as if you didn't do anything after a FW update.

Quite the opposite. It should get you to exactly to the same point as if you manually entered in the same exact config - unless a feature was altered/removed from the new FW. In that case, the newer firmware should simply ignore settings it no longer supports. In the case where new features have been added that the save config knows nothing about, the default values (on/off, specific settings, etc) should be used exactly as they would be entered after a reset.

I'd love it for Asus to chime in on this directly.

 

[john9527]

Correct. I shouldn't shoot the messenger.

But aside from my problems with the product, I just don't believe that restoring a saved config after a FW update gets you to exactly the same state as if you didn't do anything after a FW update.

Quite the opposite. It should get you to exactly to the same point as if you manually entered in the same exact config - unless a feature was altered/removed from the new FW. In that case, the newer firmware should simply ignore settings it no longer supports. In the case where new features have been added that the save config knows nothing about, the default values (on/off, specific settings, etc) should be used exactly as they would be entered after a reset.

I'd love it for Asus to chime in on this directly.

The major problem is that the saved config contains 'system' setup parameters for the wireless radios that tend to change between driver releases or just the firmware levels themselves. So there is a good chance you will end up running in a less than optimal state or experience things like drops, stutters, etc.

BTW, I also agree that there should be a better way. Maybe you missed it in the sticky, but I've written a utility to fill the gap and only transfer the 'user' settings. You may want to give it a look....

http://forums.smallnetbuilder.com/showthread.php?t=19521

 

[texashoser]

The major problem is that the saved config contains 'system' setup parameters for the wireless radios that tend to change between driver releases or just the firmware levels themselves. So there is a good chance you will end up running in a less than optimal state or experience things like drops, stutters, etc.

BTW, I also agree that there should be a better way. Maybe you missed it in the sticky, but I've written a utility to fill the gap and only transfer the 'user' settings. You may want to give it a look....

http://forums.smallnetbuilder.com/showthread.php?t=19521

Thanks. Any radio-related configuration with regards to device drivers shouldn't be saved to the configuration file. That's a dumb idea. Wouldn't those just get loaded into vram by the firmware itself?

 

[john9527]

Thanks. Any radio-related configuration with regards to device drivers shouldn't be saved to the configuration file. That's a dumb idea. Wouldn't those just get loaded into vram by the firmware itself?

Yes, they get loaded when you do a Reset to factory defaults (circular argument to follow ).....otherwise they use what's there.

There is a flip side to doing it this way.....those that want to experiment with changing these parameters (most are documented in the source) can do so without the firmware resetting them, although Asus is starting to lock down this capability. Then you could use the built in Save Configuration/Restore to get back to a known state.

 

[texashoser]

Yes, they get loaded when you do a Reset to factory defaults (circular argument to follow ).....otherwise they use what's there.

There is a flip side to doing it this way.....those that want to experiment with changing these parameters (most are documented in the source) can do so without the firmware resetting them, although Asus is starting to lock down this capability. Then you could use the built in Save Configuration/Restore to get back to a known state.

That should be easily solvable to account for both types of configs/users. If the radio device configs have been altered in any way, simply set a config bit to true (1). If set to true, the router would use the radio settings contained in the saved config. If set to false (0), the router would load the default radio settings contained in the FW.

This is stuff ain't rocket science...

 

[RMerlin]

Sigh.

And I thought after writing this whole FAQ the endless debate would end. Guess I was wrong.

When you save your config, the router will go through every single nvram value found in your nvram, and put it in the saved config. Every single one. This can be found in the router's source code, in nvram/nvram.c.

When you restore your saved config, the router will parse through your saved setting, and will compare with the list of default settings, as found in the router_defaults array in shared/defaults.c. If there is a setting with an identical name, the restored setting is committed to nvram. That means restoring a saved config will get rid of settings that no longer exist (which typically mean settings that aren't used by the firmware anyway, so they had zero impact beside taking up space). This also ensures that temporary values (i.e. your current WAN IP) does not get restored.

The issue lies in those low-level settings that are not managed by the webui. Let me take a concrete example which I observed last year. There was a low-level setting that's associated to how beamforming is managed by the radio. That setting is not affected by what you enter on the webui. In a new firmware release, Asus changed the value contained in that setting, to resolve wifi performance issues experienced by some.

If you were to restore your saved config, then the bugfix would be overwritten, and you would still experience issues, unless you had the know-how to manually change that setting. Does a CCNA working on a 2000$ Cisco have that kind of knowledge to read through Cisco's upgrade notes, and manually fix it? Yes. Does your 60 years old dad with a 150$ router, and who thinks that "SSH" is the noise you make at someone who speaks in a library? No. Hence, the simple method of "reconfigure your router". So comparing a 2000$ Cisco router in the hands of a CCNA versus a home gateway in the hand of an average Joe is invalid.

And BTW: Cisco is even messier. That long series of IOS commands you type to configure your router? Better check the exact IOS version your router runs, because even something as a user-facing API changes between IOS revisions. Some command syntax completely change between IOS revisions.

If you really wanted to manually update your configuration, then by all means, do a "diff" of the defaults.c content between firmware revisions, and manually apply any nvram change. You can do it - there's nothing stopping you from doing it. It will probably take more time and more efforts than manually reconfiguring your router however.

Sure, this config management isn't ideal. That's not the point in case here. There are better ways to handle this. At times, Asus has even added code to the firmware that would automatically take care of "updating" some older settings. But that kind of thing leads to code bloat, something far, far too common already in 2015. As for going with a more intelligent form of settings management... This is something Broadcom's engineer have no reasons to devote their time to. We're talking about 200$ home gateways here (of which only a very small portion of revenue goes into Broadcom's own pockets), not high-end business-class products. And the old KISS principle still applies. The more complex the plumbing, the more likely something is to break at some point.

As for "not putting these in nvram", sorry, but there are at least two reasons why they are:

1) So they can be manually adjusted if needed, either by the firmware or by the end-user
2) Because that is how the wireless driver can actually configure itself. Manually providing all those settings to the wireless driver would make the initialization code very complicated (and far more likely to break). So, Broadcom's driver directly goes to nvram, reads the values it needs from there, and applies them to itself.

So, back to the original topic: if a factory default reset is needed, then it's needed. Unless you are willing to manually compare the old and the new default settings, and manually adjust them. And if you are willing to deal with potential issues - that is your right to take the risk of facing them. Heck, myself I almost never reset my router's configuration - because I know where to look if something breaks, and also because I know what to manually adjust if needed.

But stop thinking that "restoring saved settings is just the same as manually reconfiguring". It's not. I might not be an Asus developer, but I think I've spent enough time with my hands buried in the router's source code to know what I'm talking about.

 

[texashoser]

Rmerlin, after resetting my router to default and loading the saved config, my clock settings were *not* restored:

admin@RT-AC68U:/tmp/home/root# nvram show | fgrep clk
clkfreq=800,666

I had to manually set them in nvram again. Are you sure all nvram settings get saved in the config dump?

Secondly, command definitions in Cisco rarely change in what they actually do. I'm not familiar with using the web-based GUI because I always use the IOS CLI, if that's what you mean by user-facing API. On start up, you can always see if a particular command is depreciated or not supported in the version of IOS you're running. In the case something isn't working correctly, you can always search the release notes for that IOS version. I've been working with high-end Cisco routers for 15 years. I would disagree 100% that it's messier.

As to nvram, I'm not advocating not using it, what I'm advocating is not storing nvram settings in a configuration file that combines settings parameters entered in the configuration GUI. Save them to a different file so that you can actually use the restore procedure. Or like I said, set a bit in the configuration so that when the configuration is restored, any settings existing in nvram override those found in saved/restored configuration. That's an extremely simple thing to do and it prevents the very people you refer to from ending up with nvram device settings from older configs that jack with the new, default values set in newer FW releases.

Why store potentially outdated device driver settings in a configuration file when 99% of those non-techies you speak of haven't changed them and they could cause serious performance issues? Makes absolutely no sense. Either set a bit in the configuration file or create two separate ones.

I'd also love an explanation of why my config restoration got rid of the bugs I was seeing after the FW upgrade prior to resetting the router. If I hadn't done a factory reset, then I should have been running on the same nvram settings as before with the same settings as configured by the GUI, correct? What I'm hearing is that after doing a factory reset and restoring from the saved config, I should have ended up right back up in the same place as prior to the factory reset, no? So why did the bugs and weirdness go away after the reset and config restoration? And why didn't the clock settings get restored?

The behavior I saw does not seem to indicate that everything nvram-related gets saved and/or restored during the backup/restoration process.

What happens when a new nvram setting gets added to the firmware that doesn't exist in the saved config?

I realize you don't have all the answers for these questions and, whether you believe or not, I admire your passion for the product and technology as evidenced by you taking more than likely thousands of hours pouring through source code to come up with bug fixes and custom feature enhancements that benefit the Asus community.

Some of the fixes I'm asking for are quite easy to implement and would benefit the vast majority of Asus users while allowing those that want to customize their configurations, even to the point of altering device driver settings, to do so just as easily as they are doing now.

Part of this frustration is the bugs that are still cropping up over a year after they were documented and presented to Asus. Do I understand the difference in product development and support between a $200 router and a $500k Cisco LTE gateway? Of course I do. I would expect ATT to demand - and get - a bug fix within hours or a mitigation process that resolves the issue when thousands of customers and millions of dollars are at stake. That's the industry I've worked in for over 15 years and that's the realistic expectation.

At the same time, I think it's more than reasonable to be extremely dissatisfied with $200 products who continue to have the same bugs for over a year and require every user to not only factory reset their router after ever FW upgrade, but to restore the configs manually to boot. That's just ridiculous when 99% of their user base aren't messing with the nvram settings to begin with.

If a new FW requires it, auto reset the router during the FW upgrade, notify the user prior to the upgrade, and allow 99% of those users to restore their non-nvram config. If an advanced user wants to restore their nvram config, let them do it manually or with a separate backup.

 

[ncnetbuilder]

RMerlin drops the mike biatches...

 

[RMerlin]

Rmerlin, after resetting my router to default and loading the saved config, my clock settings were *not* restored:

admin@RT-AC68U:/tmp/home/root# nvram show | fgrep clk
clkfreq=800,666

I had to manually set them in nvram again. Are you sure all nvram settings get saved in the config dump?

Absolutely positive, I even looked at the actual code tonight. In this particular case, the clkfreq setting does not get restored because it doesn't exist in the list of default values I mentioned and which gets checked at restore time. This is because there's no global default value for clkfreq, it varies for each models, so the default value comes from the CFE at the time you do a factory default reset.

When you do a factory default reset, two things happen:

1) A set of default, hardware-specific, values are applied to nvram
2) When the firmware boots, it applies its own set of default values on top of it

Secondly, command definitions in Cisco rarely change in what they actually do. I'm not familiar with using the web-based GUI because I always use the IOS CLI, if that's what you mean by user-facing API. On start up, you can always see if a particular command is depreciated or not supported in the version of IOS you're running. In the case something isn't working correctly, you can always search the release notes for that IOS version. I've been working with high-end Cisco routers for 15 years. I would disagree 100% that it's messier.

A friend told me how between two different IOS releases, one of his colleague got bit by the command he was previously using, who had suddenly become a shorthand for "shutdown interface" in an ew IOS release. The router required someone to go on-site to do a manual power cycle.

As to nvram, I'm not advocating not using it, what I'm advocating is not storing nvram settings in a configuration file that combines settings parameters entered in the configuration GUI. Save them to a different file so that you can actually use the restore procedure. Or like I said, set a bit in the configuration so that when the configuration is restored, any settings existing in nvram override those found in saved/restored configuration. That's an extremely simple thing to do and it prevents the very people you refer to from ending up with nvram device settings from older configs that jack with the new, default values set in newer FW releases.

It's not so simple when there are many hundreds of different settings. Quick count (which includes the instanced settings and temporary ones as well):

admin@Stargate87:/tmp/home/root# nvram show | wc -l
size: 54826 bytes (10710 left)
2155

Trying to be too clever with so many settings will lead to other bugs. That's where the KISS principle should apply.

So why did the bugs and weirdness go away after the reset and config restoration? And why didn't the clock settings get restored?

It depends on the cause of your specific issue. If you have an RT-AC68U (based on this thread's model), then you might have needed the new CFE value that came with the 1.0.2.0 CFE upgrade that happened with 376.3626, for instance.

As for clkfreq, I explained what happened to that particular setting.

What happens when a new nvram setting gets added to the firmware that doesn't exist in the saved config?

You end up with the default value, coming from either the CFE (if it's a new CFE setting) or from the shared/defaults.c list of default values (if it's a new firmware-level setting).

 

[ncnetbuilder]

Merlin, the steps I typically follow when applying a new firmware to ac68u are as follow:

1. Power off
2. Power on holding the WPS button until the power led begins flashing
3. Release the WPS button and let the router boot up
4. Apply the new firmware and do the minimum in the wizard once it boots up
5. Repeat steps 2 and 3
6. Manually reapply my settings in the gui (lan subnet, vpn, dns servers, etc)
7. Reboot one final time after new settings in place (prob optional)

Is this correct?

 

[texashoser]

Rmerlin, thanks for the answers.

With regards to Cisco, it does get quite a bit complicated because there are many different trees of IOS for a given product.

With that said, there is a difference between real-time abbreviated commands and the full command saved to the written config which is stored in flash/nvram. For example, 'wr' is an abbreviation for 'write memory' just as 'no shut' is short for 'no shutdown'.

For any given Cisco interface, if the interface or controller is meant to be in a disabled state, the configuration file will indicate that:

interface Serial0/1:0
no ip address
load-interval 30
shutdown

Personally, I'm not aware of a real-time abbreviated command like 'shut' that does something different when used in non-configuration mode vs. when used in configuration mode.

Getting back on track, I see you didn't comment on my FW upgrade strategy. As I stated, the vast majority of Asus users don't modify nvram values. They simply need to upgrade their router from time to time and restore common settings like IP addresses, wireless network name/password, and perhaps port forwarding rules. Requiring these users to reset to factory default and manually enter in these settings after each upgrade is patently ridiculous.

After typing this and rereading what you've written, I need to modify my stance given how Asus software works...

My understanding now is that when the router boots, the list of default device-specific nvram vaules are not loaded from the firmware or CFE, but the config itself, correct? And any 'new' defaults as a result of a FW upgrade only get written to nvram (and thus the saved config) via factory reset. I assume this is to speed up boot time.

OK. Fair enough - makes sense.

But it also makes sense from an upgrade perspective to not have to manually reset the device to factory defaults and have to reenter the main configuration by hand every time the FW is upgraded.

This can easily be accomplished during the configuration restoration process using the built-in utility. Rather than blindly loading the saved config into nvram and overwriting any and all current default values in the list (whether the router has recently been reset or not) with values found in the saved config, load the saved config into temp space, overwrite it with the currently loaded list of defaults, and then write it out to the new permanent bootable configuration. nvram configuration values such as clock settings would not get overwritten by the restoration process. Values such as clock settings may not be global across all devices, of course, but if you're loading in a configuration for restoration, why not apply them during that operation? Why have to go back in and reset them via manual nvram set commands?

This process would be very different from the normal configuration modification operation. Changes to the configuration via the GUI interface or nvram set command would get saved to the written config immediately and would get applied during normal bootup. The only time they would get overwritten by default values is a) during factory reset or b) or via the configuration restoration utility.

This gets you the best of both worlds and is just not that difficult to implement. For advanced users, I guess you could add an option to the restoration utility such that you could choose not to have the default list of nvram values overwrite the values in the saved config and simply blindly load the saved config as it's apparently done now and written out to memory.

EDIT: I realize I may still be getting this wrong. Perhaps you're saying that the restoration utility does, in fact, parse the configuration being restored. If so, why does it overwrite every nvram value in the default list when it could cause a conflict with updated device drivers loaded by the firmware? I get that might be a feature to those who, for whatever reason, want to keep those settings. But as already mentioned, give the user the option. By default, the common, default hardware settings of the new FW should overwrite the identical settings found in the config being restored. Allow the user to override this if the want to keep the old values.

You also mentioned:

When you do a factory default reset, two things happen:

1) A set of default, hardware-specific, values are applied to nvram
2) When the firmware boots, it applies its own set of default values on top of it

Does the firmware apply its own default values upon every boot or just after a reset is done?