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.
Any clear instructions on how best to use this utility (or not use it) to migrate only the most critical settings (DHCP Reservations, OpenVPN Settings), while leaving the rest to be manually configured during a move from 380.70 to 384.xx?

Thanks in advance.
 
What if I was to:

1) Backup a full migrate to the entware usb drive including jffs
2) Upgrade firmware from current 3.80.70 to 3.84.xx and do a factory reset to initialize all variables including new ones.
3)
Restore the "migrate" backup which will overwrite keys that match while the new ones remain to what they were initialized to.
4) Final reboot to stable 3.84 with my old settings?

Am I missing something?
 
Is a version to migrate from 380 to NG in the pipeline at all?

I have so so many settings and for me personally, doing a manual migration with screenshots and stuff like that is not an achievable effort. It can not be done. So I'm either dependent upon this tool like I have been, or maybe to just wing it and not do a factory reset between upgrades, but that in turn would mean that things might be unstable after the upgrade.
 
Thanks for the latest update!

Just tried using it on 384.7 beta1 running on 86U and the script stalls on QOS settings - any idea as to what's causing this?

Cheers
 
What update? I don't think the tool has been updated to work on that firmware release. :rolleyes:
 
Thanks for the latest update!
What update?
Just tried using it on 384.7 beta1 running on 86U and the script stalls on QOS settings - any idea as to what's causing this?
As far as I know the script has not been updated to properly backup and restore firmware in the 384 branch. At least, that's what the post on the previous page say and I haven't seen any updates since last year.

Hopefully in time it will be updated as it's considered very useful by many.
 
What update?

As far as I know the script has not been updated to properly backup and restore firmware in the 384 branch. At least, that's what the post on the previous page say and I haven't seen any updates since last year.

Hopefully in time it will be updated as it's considered very useful by many.
I must have confused the dates. Thanks for pointing my error out!
 
Has this script ever been updated to handle 384.xx? If not, any alternatives short of reconfiguring everything? (I have two routers..current on 380.70 and one I intend to flash clean with 384.xx and reset to factory...just trying to get the majority such as qos settings..static ip's....wireless wan etc passed on.
 
Marko and Rudi; several months ago, we managed one lucky upgrade jump from 380 to 384, without anything going wrong and it's been humming ever since. But; we were prepped for it not to work, and to rebuild/reconfigure from scratch. Yes, it does take time and some preparation, which is the case when so much gets dependent on the code.. When things go wrong, no tools will work, so that's when it really becomes time-intensive.

The NG FW doesn't always let you off a easy as it did the one time we were lucky. Leftover bits may hang in that aren't going to be compatible. At any rate, that's all been covered in the wiki / threads. As long as one has spent enough hours with the router that it's second nature, documenting with screen-grabs make up for memory slips, making setup from a blank slate not as bad/time-consuming or complex as workstation installation. Sometimes images don't work as advertised. If the router suddenly quits or becomes corrupted, it's best to have an updated backup router on standby. With the new Asys code becoming more closed off, it's better to go all the way, to treat the 384 upgrade as a new router, a blank slate. John's back-ports the security fixes so that might be way forward if he supports your model. Good luck.
 
Last edited:
Marko and Rudi; several months ago, we managed one lucky upgrade jump from 380 to 384, without anything going wrong and it's been humming ever since. But; we were prepped for it not to work, and to rebuild/reconfigure from scratch. Yes, it does take time and some preparation, which is the case when so much gets dependent on the code.. When things go wrong, no tools will work, so that's when it really becomes time-intensive.

The NG FW doesn't always let you off a easy as it did the one time we were lucky. Leftover bits may hang in that aren't going to be compatible. At any rate, that's all been covered in the wiki / threads. As long as one has spent enough hours with the router that it's second nature, documenting with screen-grabs make up for memory slips, making setup from a blank slate not as bad/time-consuming or complex as workstation installation. Sometimes images don't work as advertised. If the router suddenly quits or becomes corrupted, it's best to have an updated backup router on standby. With the new Asys code becoming more closed off, it's better to go all the way, to treat the 384 upgrade as a new router, a blank slate. John's back-ports the security fixes so that might be way forward if he supports your model. Good luck.

I've got a t-mobile router convinced it's an ac68u and I'm pretty sure the legacy version it is on is not going to get any more updates security or otherwise. I've also got some pretty extensive static ip's by macid, qos priorities by HOST and a wireless WAN that gets internet from a wifi hotspot. To get all that working smoothly together is not something I want to have to do again screenshots or not. I'll try doing a full backup and pull out the sections I need but at this point I've pushed it to the back burner cause more is involved than the simple update I'd hoped for. To bad the script couldn't just pull up a list of "sections" for you to checkbox that you wanted saved in a "gui fashion"....I know you can pass the parms to the script to accomplish the same thing.

Thanks for the followup.
 
I'm running the scripts on 384.6 on AC3200. All appears to be completing fine to a quick eyeball, although I've not used one for a restore/upgrade in god knows how long. Some time after I upgraded to 384 about a year ago I started having a lot of weird stability issues and behavior on the router. Like all kinds of services and processes were acting weird and/or failing. I subsequently did a full NVRAM reset and firmware reload, then used the script to restore settings and all went fine.

I see 3 possible issues reported in this thread.

The first is concerning 380-384 compatibility and migration and problems if if you have params > 150 bytes that are not allowed in 384 (that last bit important because if the parameter is allowed to be longer in 384 then in fact it should be OK).

The second is whether there are new params not properly handled by the script for 384. That certainly I can't speak to without comparing one of the usr backups with the full nvram list and then trying to figure out if any of the differences are important user based settings. I imagine there well could be some things missed now.

The other is the report above of script hanging up on QoS settings. That I can't speak to, as i've not used a restore script in about a year, but the backup script certainly completes.

My take is (and I bet somebody knows better than I and will correct me in a minute... but nonetheless here goes...)
  • Script is still very useful and can be used to restore the vast majority of parameters. If you're doing upgrades/migration in a controlled fashion you certainly could do the analysis of what is not included and handle that by hand. In a migration I suppose it might be restoring some 'legacy' parameters from 380 that are restored but now unused or replaced, but as long as they are truly deprecated then that shouldn't be much problem.
  • If you are doing the 380 migration you should to run the nvram show | awk etc. command to see what params might exceed 150bytes as that appears to be the most critical concern. For what its worth my current 384 list of params from that (aka at least all these are "OK" in my config) are
810 nc_setting_conf
484 rc_support
465 custom_clientlist
239 sshd_authkeys
184 dhcp_staticlist
175 qos_rulelist​
  • If you get caught in a catastrophic restore situation it might be a bit trickier but as long as you have been running the backups you should still have the nvram-usr and nvram-all files from the backup to refer to and work from. If you diff them you should see what is not included in usr and if there are things that you need to restore manually (and could easily turn that diff-output into another script honestly). So while its not as plug and play as it used to be, running the script nightly or weekly is still probably better than nothing for most people.
 
Other than aimesh (which is basically a non issue if only using 1 router) what are the noticeable improvements/features in 3.84 vs 3.80? Just re-evaluating the "if it ain't broke, don't fix it" philosophy.
 
Other than aimesh (which is basically a non issue if only using 1 router) what are the noticeable improvements/features in 3.84 vs 3.80? Just re-evaluating the "if it ain't broke, don't fix it" philosophy.
SECURITY! You are leaving your network in a vulnerable state by not updating on a regular basis.
.
 
Last edited:
Other than aimesh (which is basically a non issue if only using 1 router) what are the noticeable improvements/features in 3.84 vs 3.80? Just re-evaluating the "if it ain't broke, don't fix it" philosophy.

If you read through all the changes in between, I doubt you’ll hesitate for long before upgrading to the latest firmware. I can’t be sure but I think there’s a mandatory reset to factory default settings (RFDS) somewhere within that gap, and, even if there isn’t, you’d be asking for trouble if you didn’t RFDS given such a jump:

https://asuswrt.lostrealm.ca/changelog

https://asuswrt.lostrealm.ca/changelog-382

NB After the RFDS it’s a manual re-insertion of settings; definitely no short cuts with backups!
 
Rudi, as long as your router is an actual 68, you should be able to upgrade/update without any worries, and stand to lose more by not updating. We haven't run a 68 for quite some time, they sell quite a few new units since the price has come down, as they seldom (if ever) have any issues with the NG upgrade. If it's not an actual 68, then all bets are off, and you should leave it alone rather than risk losing what you have; it would be fine for a decent backup unit. Treat yourself to a new RT-AC86 soon, or try John's build. At some point, perhaps the tool will be made to work for all, but until then, that's the way it is. To upgrade isn't not really an insurmountable issue and even under the older FW, sometimes there's no choice but to clear the thing and and rebuild/reconfigure from scratch, stick with it, build your confidence and you'll get there. Scripts can be backed up, and screen-grabs aren't all that bad. Good luck..
 
What is this?

webdav_smb_pc=

Two days ago I backupped my dear old 66U, to migrate to a new router.
I want to use this tools to have a "human-readable" configuration file but... lookin' into nvram-all-201907280906-MIGR,
values for webdav_smb_pc= are all PCs on my LAN, and one Ghost:

PIRATE-PC<192.168.1.215<00:22:02:BF:C2:49<0> (PC name and Mac Address modified).

Can someone please explain me what this means?

Thanks in advance.

Max
 
It's used by AiCloud and AFAIK relates to Samba access. I think it's a list of all of the devices that have ever accessed AiCloud shares.
Mmmmm... so It seems someone not authorized connect to my samba shared disk...

Inviato dal mio Z2 utilizzando Tapatalk
 
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