What's new

User NVRAM Save/Restore Utility (R26.2)

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Status
Not open for further replies.
Brilliant! I followed your tips and it worked exactly as described.
Just out of curiosity, why Telnet, not SSH? SSH is more secure and handy. And via Telnet we cannot reboot the router in the terminal after the restoration process, unlike SSH (or maybe I'm doing smth wrong?)
Will your script work via SSH?
Will definitely work via SSH. The reason for telnet is again the 'typical' target user. The telnet client is included with Windows and is simple to use, so someone doesn't need to go out and get/configure another client.

I'm going to make a few changes to the guide to make this clearer in the next update.
 
Will your script work via SSH?
I have telnet disabled by default and use it only through SSH, without any problems whatsoever, like @john9527 already mentioned.

Regarding the user guide, I think it would be great if there was made a difference between a novice user and a (more) advanced user. I found something somewhat confusing too and such an awesome script (which saved my *ss more than once), just deserves a comprehensive guide for both groups of users, that is, in my humble opinion :rolleyes:
 
I'm going to make a few changes to the guide to make this clearer in the next update.

Good! Also, to bring the guide to a common style and to make user better realize what's going on, it's be better to stick to one form of perms notation, either octal or symbolic. In the beginning of the guide it is stated
chmod 755 ./*.sh
but in the Saving the data for later use part
chmod a+rx ./*.sh

For a novice user (for me too) it's somewhat confusing, either these permissions are equivalent or no. For example, I had to use permission calc to determine that :D, 'cause stat command is not available on AsusWRT.
 
This is the most useful and easiest tool
I have come across after moving to merlin.
Save and Restore...and save a ton of time and frustration.

I assume @john9527 would not mind,
if users take initiative in starting/updating a
user/installation guide with installation steps, experience, faq etc.,
 
I have just discover this application. Thank you for making it available. I will use this to update my setting from now on. Previously I have to backup the setting via GUI -> update the firmware -> restore to default -> restore the backup. It seems to have work but your method should be more proper.
 
I have just discover this application. Thank you for making it available. I will use this to update my setting from now on. Previously I have to backup the setting via GUI -> update the firmware -> restore to default -> restore the backup. It seems to have work but your method should be more proper.
Not just "more proper" but the only method. The method you used must not be used when updating the firmware; it should be used only if, for whatever reason, you need to restore the settings on your router in the very same firmware version you made the backup on.

From Merlin's FAQs https://www.snbforums.com/threads/faq-nvram-and-factory-default-reset.22822/

"Can I just restore my saved settings after I do a factory default reset?
No. The idea behind a factory default reset is to have your router start using the NEW default values. If you restore your saved settings, you will overwrite those new values with the old ones, and you are back to square one."


Sounds like you've been lucky up to now, but certainly, if you get any problems in future, your first step would be to restore to factory default settings and then manually input your settings. From there on, you could use John's tool knowing you're on a solid foundation. Personally, I think I'd do that anyway, rather than wonder what gremlin "sleeper cells" might be waiting to wake up.
 
Last edited:
Not just "more proper" but the only method. The method you used must not be used when updating the firmware; it should be used only if, for whatever reason, you need to restore the settings on your router in the very same firmware version you made the backup on.

From Merlin's FAQs https://www.snbforums.com/threads/faq-nvram-and-factory-default-reset.22822/

"Can I just restore my saved settings after I do a factory default reset?
No. The idea behind a factory default reset is to have your router start using the NEW default values. If you restore your saved settings, you will overwrite those new values with the old ones, and you are back to square one."


Sounds like you've been lucky up to now, but certainly, if you get any problems in future, your first step would be to restore to factory default settings and then manually input your settings. From there on, you could use John's tool knowing you're on a solid foundation. Personally, I think I'd do that anyway, rather than wonder what gremlin "sleeper cells" might be waiting to wake up.

Thank you for the link. My gut feeling was from Merlin's FAQs. I was too lazy to entered every entries but you have confirm that I am either do that or use John's tool.

But in saying that, my experience was when I have encountered intermittent slow internet speed after the minor update, restoring the backup following factory reset resolved the issue.
 
Last edited:
Thank you for your link. My gut feeling was from Merlin's FAQs. I was too lazy to entered every entries but you have confirm that I am either do that or use John's tool.

But in saying that, my experience was when I have encountered intermittent slow internet speed after the minor update, restoring the backup following factory reset resolved the issue.

I guess if, whilst you've been doing this, Merlin has not released an update for which he stated a factory reset was required, no great harm was done, indeed, it seems you found something that has worked for you. Like you, I'll soon be using John's Utility for the first time and look forwards to the time and effort it saves.
 
I have a question that is kind of simplistic.
I have an RT-3100 and I thought it was going to go out one night when I was sleeping and a thunder storm came threw the area. Fortunately my son-in-law had unplugged it, but I didn't know till next morning.
Anyway! It got me to thinking about if I had to get a new one of same model. Would the "Nvram-save" USB stick from the old RT-3100 work to reload the same environment on the new one or should I create a safety shield by using a spare USB stick and using the "Migrate" feature in the script?
I know there are explanations in the script, but I just want to be sure I understand this correctly.
 
Nothing simplistic about your question, better safe than sorry.

If you manage to get exactly the same revision RT-3100 (if there are different revisions of the RT-3100, I don't know that model), in case this one breaks down, it should work with your current 'regular' nvram-save backup. In all other scenario's, your safest bet would be the migrate option as it backups the values which can safely be restored to other models.

Personally, I use migrate every once in a while, in case my RT-AC68U breaks down (which is still available in the same revision, but in case I decide to go for another model) and the regular nvram-save on a weekly basis (or more frequent if I have the urge to fiddle with something, or before an upgrade), so I always have (at least) two recent backups, the 'regular' router-specific version and the migrate version.

@john9527, please correct me if I'm wrong...
 
Hi John,

I can't thank you enough. Just copied my setting from my 87U merlin build and copied it onto my RT3200 without a hitch! Well, the usb stick gave me some issues, but just bought a new 16Gb and got everything running. Saves me so much time with all the port forwarding, static addresses and even copied over the time scheduling i enabled on a few devices! Amazing! :)

One thing i did do is to patch the firmware to the same level before i did the restore. Just to avoid any issues :)

Cheers!
 
Nothing simplistic about your question, better safe than sorry.

If you manage to get exactly the same revision RT-3100 (if there are different revisions of the RT-3100, I don't know that model), in case this one breaks down, it should work with your current 'regular' nvram-save backup. In all other scenario's, your safest bet would be the migrate option as it backups the values which can safely be restored to other models.

Personally, I use migrate every once in a while, in case my RT-AC68U breaks down (which is still available in the same revision, but in case I decide to go for another model) and the regular nvram-save on a weekly basis (or more frequent if I have the urge to fiddle with something, or before an upgrade), so I always have (at least) two recent backups, the 'regular' router-specific version and the migrate version.

@john9527, please correct me if I'm wrong...
Thanks for the reply!
As far as I know the RT-3100 has only one revision, but I read on the forum that the latest routers have a newer chipset. Not sure if it affects the "Nvram backup" or not. That is why asked this question in the first place.
 
As far as I know the RT-3100 has only one revision, but I read on the forum that the latest routers have a newer chipset. Not sure if it affects the "Nvram backup" or not. That is why asked this question in the first place.

Ah, I see, In that case I hope another RT-3100 owner is reading this thread and (hopefully) can confirm whether the default backup can be restored, as I simply don't know. Anyway, the migrate option will save you a lot of time in case of emergency, although you will need to reconfigure some more compared to the default nvram-save backup.
 
Thanks for the reply!
As far as I know the RT-3100 has only one revision, but I read on the forum that the latest routers have a newer chipset. Not sure if it affects the "Nvram backup" or not. That is why asked this question in the first place.
It should be OK to restore the the 'non-migrate' version (anything that is 'rev' level related should be excluded in both cases). What won't be correct is some things that are unique to the router, for example the default router friendly name which includes a couple of bytes of the router mac address.

This post has a list of the things that are different in migrate mode....some are no longer important when moving to the same model router, like clkfreq since you can't overclock anymore).
https://www.snbforums.com/threads/user-nvram-save-restore-utility-r24a.19521/page-13#post-187866
 
It would be great if the logic could be changed so that all settings are always stored, but the restore command dictates the mode. We could then just take one backup that can be used to recover our existing router, or if the worst happens it can also be used to migrate to a new one.
 
It should be OK to restore the the 'non-migrate' version (anything that is 'rev' level related should be excluded in both cases). What won't be correct is some things that are unique to the router, for example the default router friendly name which includes a couple of bytes of the router mac address.

This post has a list of the things that are different in migrate mode....some are no longer important when moving to the same model router, like clkfreq since you can't overclock anymore).
https://www.snbforums.com/threads/user-nvram-save-restore-utility-r24a.19521/page-13#post-187866
I have a question on the jffs reset. What does that mean?
Also if the old router had a mac of 0000, will it restore the jffs backup on the new one if the mac is different?
That is my main concern as I have a few custom scripts saved.
 
Sorry!
Another question.
I recently setup SSH key authentication and use this to log into SSH.
Will the key authentication files be saved and restored by the script after a firmware upgrade and factory-reset?
 
Sorry!
Another question.
I recently setup SSH key authentication and use this to log into SSH.
Will the key authentication files be saved and restored by the script after a firmware upgrade and factory-reset?
The ssh key is stored in nvram as well as in your backup, so most likely it gets restored.

Code:
marco@RT-AC68U:/tmp/mnt/ASUS/backup# cat nvram-usr-201707060920-7130.txt | grep 'ssh'
sshd_enable="2"
sshd_forwarding="0"
sshd_port="22"
sshd_pass="0"
sshd_bfp="1"
sshd_authkeys="<insert key here>"

In case it doesn't get restored: If you have generated the keypair on your pc, it's a matter of enabling ssh authentication again on your router after restoring (and preferably disabling 'Allow SSH password login' and enabling 'Enable SSH Brute Force Protection'. Then paste the public key in the appropriate field and save your settings.

When connecting the first time, you'll get a warning message, which you got too when you connected through ssh the very first time, that the fingerprint of the host is unknown or different compared to the fingerprint that is stored on the pc you use to connect. Just agree to trust the fingerprint from the host, as this is just a security measure, to make sure you're actually connecting to the right host. And that's basically all, to be able to use ssh again to connect to your router.
 
Note that with the later Merlin builds most of the keys/certs are now stored in jffs (also on my fork if they are moved with the xxxx2jffs command line utilities). I don't think Merlin has moved the sshd keys yet, though.
In these cases, it will also be necessary to 'jffs-restore.sh' to get everything correctly restored.
 
Note that with the later Merlin builds most of the keys/certs are now stored in jffs (also on my fork if they are moved with the xxxx2jffs command line utilities). I don't think Merlin has moved the sshd keys yet, though.

I haven't decided yet if I will move SSH keys or not, as this would break backward compatibility with stock firmware.

BTW, a number of interesting things in the just-released BRT-AC828 GPL:

- JFFS backup/restore. Unfortunately, most of the code is closed-source. <groan> I think that they append it to the CFG file, but I can't be sure as that's the closed part.
- Support for custom SSL certificates, and also for Let's Encrypt. The LE code isn't complete (the rc/ code isn't in the GPL tarball) so this might be a work-in-progress. Some of their implementation is interesting (ability to upload the key/cert through the webui) so I might merge some of these portions. But they store their certificate in a different location than me. That means I might need to officially drop full backward/forward compatibility, move it to their location, or implement some migration code at boot time. Things to ponder during my vacations...

Whether this will all make it into the core 382 code is also unknown - the BRT code is from a separate branch than the rest, so some of its stuff might not make it to other models.
 
Status
Not open for further replies.

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top