can configuration information of the same firmware version be exported/imported to each other?

[Dedel66]

If you overwrite these nvrams with the MAC of a different device's config file, they won't be replaced by the correct one unless you did another factory default reset. You will end up with a mixture of correct and incorrect MACs.

On which mac addresses do you refer to?

This is the AX88U I configered manually as an AP and saved it´s config:

This the AX88U I configured with the saved config:

There I don´t see a mix of macs.

@all: don´t worry about showing settings, the APs are not online. This was just for testing.

I don't want to argue just curious.

 

[RMerlin]

On which mac addresses do you refer to?

All of them.

The webui isn't showing you everything that's stored in nvram.

 

[Viktor Jaep]

On a factory default reset, the MACs are copied from the bootloader to a number of nvrams, and a few other nvram are filled with calculated MACs (i.e. base-MAC + 2). If you overwrite these nvrams with the MAC of a different device's config file, they won't be replaced by the correct one unless you did another factory default reset. You will end up with a mixture of correct and incorrect MACs.

If you back up your config using the UI and export your routers settings to a .cfg file, does this file contain all these MAC addresses? Or are there nvrams that we can't get to that won't get backed up in this .cfg? It would just make so much more sense that these values would get updated/replaced if they don't match what's already in nvram.

Is there a way to force an update of MAC addresses by perhaps blanking them out in nvram, or through some other means without doing a factory reset?

 

[Tech9]

I’ll give you more information about what happens in reality @Viktor Jaep when I get back home tonight. Asus save/restore is smarter than copy/paste. You don’t get different MAC addresses.

 

[RMerlin]

If you back up your config using the UI and export your routers settings to a .cfg file, does this file contain all these MAC addresses?

I don't know, libnvram has been closed source since HND. It's possible it might be filtering certain values, but I have no way of knowing for sure.

 

[Viktor Jaep]

I don't know, libnvram has been closed source since HND. It's possible it might be filtering certain values, but I have no way of knowing for sure.

It would think from a business perspective, if Customer A's router died, and Customer A decides to buy another similar model router to restore his backed up router settings/.cfg back to, that it shouldn't be engineered to cause them any trouble down the road. Asus should be encouraging that. Ya know?

If Asus really wanted to prevent a .cfg from being restored to prevent future NVRAM/MAC issues, they would have written some rules around these files to identify some kind of hardware finger print, and deny a restore unless it is the same exact original router where the .cfg originated from... and prevent it from being restored onto another exactly similar model/HW/FW level. Purely for self-preservation.

But that's not what we see... in fact, it's so wide open that you will regularly see people trying to restore RT-AX58U .cfg's onto a new GT-AX6000 (looking at the OP of this thread), and Asus isn't standing in the way to prevent this from happening.

I would probably give Asus some of the benefit of the doubt, that they have thought through some of these scenarios to prevent bricking or NVRAM corruption issues in order to keep these routers going with as little coming back to them in RMA form. But where is the breaking point...

 

[Tech9]

But where is the breaking point...

Here how it works in reality, tested and verified with NVRAM comparison, GUI settings comparison and functionality:

The same router older to newer firmware - all good.
The same router newer to older firmware - may need fixing here and there, not guaranteed.
If the new firmware has password encryption, but the older one doesn't for example - factory reset, no way to log into the GUI.

RT-AC68U -> RT-AC86U -> RT-AX86U logical upgrade path - all good.
Notice the conversion of DHCP reservations, custom device names, custom icons between ARMv7 and NHD - it was done automatically.
RT-AX58U -> RT-AX88U (both on 388 firmware) - all good.
RT-AX88U -> RT-AX86U (both on 388 firmware) - all good.

Host with extra features to target without - changes to NVRAM transferred, but ignored.
Host with fewer features to target with extras - extra features remain at default values.
Dual-band host to tri-band target - the extra radio will be on default, existing radio if incompatible settings will be set to Auto.
Tested with RT-AC68U -> RT-AC5300
5GHz-1 radio (ch.149 on RT-AC68U) was on Auto channel, 5GHz-2 radio (non-existent on RT-AC68U) was on all Default.

Two reasons I did not recommend @fffddd doing it:
- Asus save/restore is unaware of Asuswrt-Merlin changes on top (more on this below)
- I don't have newer BCM4912 hardware and haven't tested it myself

Asuswrt to Asuswrt-Merlin - basics work, whatever is different (like VPN configurations, script changes, etc.) doesn't (as expected).
Asuswrt-Merlin to Asuswrt - cleaned properly configuration to the features available in Asuswrt works, otherwise needs fixing. Forgotten CakeQoS will invoke Unknown QoS type message, has to be changed/fixed to Asuswrt available options by enable/disable. Forgotten VPN configurations will just hang there unused/unrecognized, may be a problem for routers with low NVRAM. Any script changes have to be reverted to defaults before save/restore, but unfortunately I found some scripts don't clean well after uninstallation. More issues with scripts, but not subject of this conversation.

Now you know why Asus doesn't have hardware and version check. Their save/restore simply works most of the time on incremental upgrades or replacements. Notice the FAQ says "your Asus router" and not "the same hardware and the same firmware". Third party firmware users already accepted the "use at your own risk" condition and have to follow the developers recommendations. If they don't - their problem.

Some people like to repeat what someone else says without testing. This is how forum mythology was born.

 

[Viktor Jaep]

Here how it works in reality, tested and verified with NVRAM comparison, GUI settings comparison and functionality:

The same router older to newer firmware - all good.
The same router newer to older firmware - may need fixing here and there, not guaranteed.
If the new firmware has password encryption, but the older one doesn't for example - factory reset, no way to log into the GUI.

RT-AC68U -> RT-AC86U -> RT-AX86U logical upgrade path - all good.
Notice the conversion of DHCP reservations, custom device names, custom icons between ARMv7 and NHD - it was done automatically.
RT-AX58U -> RT-AX88U (both on 388 firmware) - all good.
RT-AX88U -> RT-AX86U (both on 388 firmware) - all good.

Host with extra features to target without - changes to NVRAM transferred, but ignored.
Host with fewer features to target with extras - extra features remain at default values.
Dual-band host to tri-band target - the extra radio will be on default, existing radio if incompatible settings will be set to Auto.
Tested with RT-AC68U -> RT-AC5300
5GHz-1 radio (ch.149 on RT-AC68U) was on Auto channel, 5GHz-2 radio (non-existent on RT-AC68U) was on all Default.

Two reasons I did not recommend @fffddd doing it:
- Asus save/restore is unaware of Asuswrt-Merlin changes on top (more on this below)
- I don't have newer BCM4912 hardware and haven't tested it myself

Asuswrt to Asuswrt-Merlin - basics work, whatever is different (like VPN configurations, script changes, etc.) doesn't (as expected).
Asuswrt-Merlin to Asuswrt - cleaned properly configuration to the features available in Asuswrt works, otherwise needs fixing. Forgotten CakeQoS will invoke Unknown QoS type message, has to be changed/fixed to Asuswrt available options by enable/disable. Forgotten VPN configurations will just hang there unused/unrecognized, may be a problem for routers with low NVRAM. Any script changes have to be reverted to defaults before save/restore, but unfortunately I found some scripts don't clean well after uninstallation. More issues with scripts, but not subject of this conversation.

Now you know why Asus doesn't have hardware and version check. Their save/restore simply works most of the time on incremental upgrades or replacements. Notice the FAQ says "your Asus router" and not "the same hardware and the same firmware". Third party firmware users already accepted the "use at your own risk" condition and have to follow the developers recommendations. If they don't - their problem.

Some people like to repeat what someone else says without testing. This is how forum mythology was born.

Wow, there's so much great data to digest here... thanks for all this. Will need to take some time and chew on this.

 

[Tech9]

Will need to take some time and chew on this.

In short:

Does it work on stock Asuswrt? - yes
Does it require the same router model? - no
Does it require the same firmware version? - no
Can you expect complications? - yes, if you are going backwards in hardware and firmware

How it works under the hood - I don't know. Based on results it's not just copy/paste, but matching and converting data when needed. Whatever doesn't apply to the new model is skipped or ignored. There is some fail-safe logic built-in and it works. I personally never encountered unrecoverable condition. Minor issues only, fixable.

 

[Dedel66]

@Tech9

Thank you very much for taking time for these detailed tests and thus confirming my observations.

 

[L&LD]

Yup, testing all obsolete models makes me feel so much better about this now.

And we are in the RMerlin subforum here. So again, all your 'testing' goes out the window.

As I stated already, you just don't know what configuration the router is in when you import from one model to another.

Regardless of how good your guesses (i.e. testing) were on models that don't mean much today).

 

[Dedel66]

@L&LD
OT: The way you write here seems arrogant and disrespectful. It is a forum for like-minded people where no one is allowed to put themselves above others!

 

[RMerlin]

In short:

Have you checked that every occurences of the old MAC were replaced by the new one in nvram? Not just the 1:xxx 2:xxx entries, but also all the wireless instances (wl1_, wl1.1_). I remember there was one or two others tied to either the clientlist or AIMesh config sharing, I forgot which.

I would also be worried by models that use a different interface for wan0. RT-AX58U (if I recall correctly) uses eth5 instead of eth0. Also devices with an extra multigig port might use a different interface name for wan0, so going to a device with only a single WAN interface might yield unexpected results.

There's just so many different scenarios to cover that it's why I always tell people it's best not to trust cross-device migration.

 

[RMerlin]

Yup, testing all obsolete models makes me feel so much better about this now.

On the contrary, these tested scenarios do yield interesting pieces of data, and they shouldn't just be dismissed.

 

[dosborne]

Summary;

If you have to ask "is it possible...." the answer is no (to save everyone a headache).

If you want to do it, go ahead, but be prepared for all sorts of bizarre issues and hope that a full manual reset and config resolves it. It is your router and your right to screw it up.

 

[L&LD]

@L&LD
OT: The way you write here seems arrogant and disrespectful. It is a forum for like-minded people where no one is allowed to put themselves above others!

That's your take, not mine.

I don't want to be in a yes-man group. I want ideas to be discussed and challenged if needed.

 

[Tech9]

Have you checked that every occurences of the old MAC were replaced by the new one in nvram?

Comparing NVRAM contents before and after shows correct values. Whatever doesn't apply remains unchanged or ignored.

There's just so many different scenarios to cover

This is correct. There is AiMesh on top which I didn't touch. Some folks reported save/restore restores AiMesh as well, but I can't confirm. I found potential user issues with Asus save/restore, but easy to fix with minimal knowledge or with little guidance. May be intentional due to security reasons, some of the settings are not transferred and not documented in FAQ. Simpler configuration and closer hardware works very well though without a glitch. There is always reset option if something isn't right. I believe Firmware Upgrade FAQ mentions it. Based on results Asus has some logic behind save/restore and I found settings structure pretty consistent across different models. Save/restore also does compatibility conversions, this is impressive and supports @Viktor Jaep observations it was done with migration and hardware upgrade intent.

 

[Viktor Jaep]

Comparing NVRAM contents before and after shows correct values. Whatever doesn't apply remains unchanged or ignored.



This is correct. There is AiMesh on top which I didn't touch. Some folks reported save/restore restores AiMesh as well, but I can't confirm. I found potential user issues with Asus save/restore, but easy to fix with minimal knowledge or with little guidance. May be intentional due to security reasons, some of the settings are not transferred and not documented in FAQ. Simpler configuration and closer hardware works very well though without a glitch. There is always reset option if something isn't right. I believe Firmware Upgrade FAQ mentions it. Based on results Asus has some logic behind save/restore and I found settings structure pretty consistent across different models. Save/restore also does compatibility conversions, this is impressive and supports @Viktor Jaep observations it was done with migration and hardware upgrade intent.

Fantastic research on this, @Tech9! You should be awarded an Asus research grant!

 

[Tech9]

If you have to ask "is it possible...." the answer is no

In this case you have to reset after every firmware upgrade. If you compare the NVRAM values before and after you'll find them identical after save/restore and after firmware upgrade with no reset. In one case you replace NVRAM contents over specific firmware base, on the other case you replace the firmware base keeping old NVRAM contents. The final result is the same. Do you reset your router after every firmware upgrade? I believe you don't.

Fantastic research on this, @Tech9!

I did spend some time on it, but as @RMerlin says above it is impossible to cover all possible options. What I can say is as a result I learned how to transfer settings safely between Asuswrt different firmware and hardware and also between Asuswrt-Merlin different firmware versions and between Asuswrt and Asuswrt-Merlin different firmware. Something many people around say is not possible and you end up with "all sorts of bizarre issues". I did not end up with any issues. Asuswrt-Merlin needs a bit more preparation, Asuswrt is a straight shot.

How deep did I go for fun - up to converting one Asus model to another more expensive, loading stock Asuswrt on it and upgrading it online.

 

[Tech9]

Save/restore also does compatibility conversions

Actually, this isn't exactly correct. Save/restore does some conversions, but major changes are done by the firmware itself. If the partitions structure was changed - the firmware does it on first boot. I remember trying to kill one router going back and fort with firmware when Asus made partition changes in preparation for 386 code base. It survived.