User NVRAM Save/Restore Utility (R26.2)

[elorimer]

So after a firmware upgrade and (mandatory?) firmware reset, exploiting the flexibility of @john9527's design I can in a few seconds reliably (i.e. repeatedly and consistently) selectively restore tedious time-consuming GUI configurations such as the DHCP IP reservations, VPN and Guest Networks etc. safe in the knowledge that a corrupt configuration isn't restored, but if it was, I can easily review the human-readable restore script and adapt as necessary.

I confess more than once doing this after completely wiping the router and doing an M&M configuration. I just edit the restore script to delete all the sections except the VPN and DHCP IP reservations, and use the rest as a checklist. I think I will now modify my copy of the script to add the additional variables for the VPN section as you suggest.

The firmware settings save and restore part of the firmware is really if one is rolling back to a prior version, or if one has embarked on adding some new element and want to retreat to a prior point.

 

[cmkelley]

Two years ago I proposed some changes to @john9527's script - basically to provide more feedback/stats and easier management of the backups.

i.e. I still use my tweaked version of the script (see this post) to fix the incomplete/broken backups for end-user configuration panels such as the VPN server/client GUI.

So after a firmware upgrade and (mandatory?) firmware reset, exploiting the flexibility of @john9527's design I can in a few seconds reliably (i.e. repeatedly and consistently) selectively restore tedious time-consuming GUI configurations such as the DHCP IP reservations, VPN and Guest Networks etc. safe in the knowledge that a corrupt configuration isn't restored, but if it was, I can easily review the human-readable restore script and adapt as necessary.

Clearly the firmware's GUI backup/restore '.cfg' feature is useless in this very common firmware upgrade scenario.

Performing a firmware reset after upgrade is hardly mandatory. I can't remember the last time I did, and I use a number of scripts and Entware add-ons without issue. I've done tons of installing and removing of stuff on the router I use for testing without resetting the firmware. I think you over-estimate how common resetting the firmware is for most people.

 

[Martineau]

Performing a firmware reset after upgrade is hardly mandatory. I can't remember the last time I did, and I use a number of scripts and Entware add-ons without issue. I've done tons of installing and removing of stuff on the router I use for testing without resetting the firmware. I think you over-estimate how common resetting the firmware is for most people.

If you look closely I actually typed

(mandatory?)
​

using the parentheses and question-mark to make the point that it should be considered a judicious choice.

However, including those who have explicitly stated that 'dirty upgrades' never work for them, given the number of 'gurus' who immediately post that a 'factory reset/M&M config' should be performed, I still believe a significant number of forum members, rather than frustratingly endure (completely avoidable) weird router behaviour, would agree that it is a no-brainer and will simply always prefer (even with manual screen prints methods etc.) to perform the 'factory reset' as a best-practice for peace of mind - if not also being able to reply that they are clearly technically astute and have already "been there , done that".

NOTE: I prudently perform a 'factory reset' after every formal firmware 'release' upgrade to hopefully pre-empt 'dirty-upgrade' issues potentially introduced by undisclosed/hidden closed-source low-level firmware changes made by ASUS, despite even @L&LD publicly stating that he doesn't always feel it necessary to follow his own M&M advice when upgrading the firmware on his routers.

I guess you just got lucky by continuing to 'dirty-upgrade', but even you publicly posted your luck ran out and personally acknowledged the benefit of a 'factory reset' to fully resolve a weird firmware issue unique to your router.

 

[Rolo]

Performing a firmware reset after upgrade is hardly mandatory. I can't remember the last time I did, and I use a number of scripts and Entware add-ons without issue. I've done tons of installing and removing of stuff on the router I use for testing without resetting the firmware. I think you over-estimate how common resetting the firmware is for most people.

It's mandatory for troubleshooting router issues--which the AC5300 never not has

 

[L&LD]

For clarity: I always follow my own advice for customer's routers. M&M Config each and every time.

I don't want to go back for a service call for something I could have easily prevented by investing a few additional minutes anyway.

For my own routers, I make that call on a case-by-case basis. If there is any indication of 'weirdness' on my network, I would not hesitate to do a full M&M Config. With the repetition and practice I get doing that for others, it is a mere 20 minutes additional time to me anyway, for my network.

I am somewhat pleasantly surprised and pleased with the current run on my personal routers. I have been doing a dirty upgrade since 384.10 without any showstopping issues and currently running 384.14 A2 on my RT-AC86U.

When my health/personal life gets more in order, I do intend to do a full ('nuclear') reset and see if any changes are observed in my daily use. Not that it seems to need it right now. But just because I know just how much better the network works after doing so.

 

[dbareis]

But just because I know just how much better the network works after doing so.

I'm wondering where is the best place to report bugs like that and have you done so? Would evidence show up in the sparse logs?

Sent from my SM-T590 using Tapatalk

 

[L&LD]

I'm wondering where is the best place to report bugs like that and have you done so? Would evidence show up in the sparse logs?

Sent from my SM-T590 using Tapatalk

Report bugs?

This is user/device configuration errors as far as I'm concerned. Simply a consequence of how all links in the chain are affecting each other at this stage in any particular network set up. Including possible inter-firmware changes of internal variables, device microcode settings that may change meanings or actions between firmware and are stored on client devices. And even SSID naming bugs that crop up from time to time that can take you on a long goose chase for no reason too.

Nothing to report, just something to fix/do if you want the smoothest running network.

 

[AppleBag]

It's mandatory for troubleshooting router issues--which the AC5300 never not has

That router is always causing you headaches? I was thinking about buying it ... you don't recommend it?

 

[Rolo]

That router is always causing you headaches? I was thinking about buying it ... you don't recommend it?

Yes, it has always had problems (crashes/reboots, slows down until a manual reboot, clients momentarily losing connection) and therefore I do not recommend the GT-AC5300 (or any Asus product for that matter since I've eliminated all of them due to issues like this: motherboards in 2005, laptops in 2008, network devices in 2018--video cards purely from guilt-by-association). Asus puts together nice hardware but their firmware always has problems. A Bugatti with a broken steering column is still undrivable, no matter how beautiful it is otherwise.

I use a syslog server to capture all the router's events and it's bad.

 

[Xentrk]

I now have the nvram backup and restore utility working flawlessly on my AC88U. What I did was dump out a sorted list of the nvram values and did an eyeball comparison with nvram.ini. I then added missing nvram variables to nvram.ini and removed nvram variables in nvram.ini that I don't have. I got half way thru and realized I probably shouldn't have removed some of the nvram variables as they may pertain to other routers that have features such as tri-band wireless.

The fact that it worked flawlessly on the first test was very encouraging. I now want to take a look at some of the changes @Martineau has implemented. When I get further along, I am open to posting my changes to GitHub and granting access to the repo to other developers. I don't see a license reference on the source code so I don't think I would break any rules for posting on GitHub. But @john9527 can advise about the license. Full credit for the original source code would be given to him.

The jffs backup and restore function takes care of the nvram variables that get stored on /jffs/nvram folder for HND routers. I want to repeat the steps for my friend's AC86U. But I won't be able to take it offline to test since it is a production environment. I would have to wait until I can go onsite during the next firmware upgrade to test it. This is where others could step in and help test.

 

[thelonelycoder]

I now have the nvram backup and restore utility working flawlessly on my AC88U. What I did was dump out a sorted list of the nvram values and did an eyeball comparison with nvram.ini. I then added missing nvram variables to nvram.ini and removed nvram variables in nvram.ini that I don't have. I got half way thru and realized I probably shouldn't have removed some of the nvram variables as they may pertain to other routers that have features such as tri-band wireless.

The fact that it worked flawlessly on the first test was very encouraging. I now want to take a look at some of the changes @Martineau has implemented. When I get further along, I am open to posting my changes to GitHub and granting access to the repo to other developers. I don't see a license reference on the source code so I don't think I would break any rules for posting on GitHub. But @john9527 can advise about the license. Full credit for the original source code would be given to him.

The jffs backup and restore function takes care of the nvram variables that get stored on /jffs/nvram folder for HND routers. I want to repeat the steps for my friend's AC86U. But I won't be able to take it offline to test since it is a production environment. I would have to wait until I can go onsite during the next firmware upgrade to test it. This is where others could step in and help test.

Keep amtm compatibility in mind while overhauling the code and structure. It'll be simpler and faster to integrate once users get wind of your project.

 

[Martineau]

I now want to take a look at some of the changes @Martineau has implemented. .

In the years since I sent you (and @john9527 ) my hacked scripts, I have made a few more tweaks, so I'll send you a link to the most recent versions.

 

[Xentrk]

In the years since I sent you (and @john9527 ) my hacked scripts, I have made a few more tweaks, so I'll send you a link to the most recent versions.

Very Grateful!

 

[Xentrk]

Keep amtm compatibility in mind while overhauling the code and structure. It'll be simpler and faster to integrate once users get wind of your project.

I concur. I will include an install/remove script that can be added to AMTM. I should be able to reuse some code from the x3mRouting install script.

 

[renmet]

In the years since I sent you (and @john9527 ) my hacked scripts, I have made a few more tweaks, so I'll send you a link to the most recent versions.

Hello,

can you also send me the link to the newest version? Thanks for your help

kindly regards

 

[PolarBear]

Hello,

can you also send me the link to the newest version? Thanks for your help

kindly regards

@Martineau
The nvram save utility is something I really miss since the move to the new 384 firmware.
Could you send me a link too please ?
Many thanks
PB

RT-AC86U

 

[Martineau]

@Martineau
The nvram save utility is something I really miss since the move to the new 384 firmware.
Could you send me a link too please ?

@Xentrk's post #810 implied that he would publish the revised v384.xx compatible 'nvram-rmerlin.ini' file.

So having decided to err on the side of caution, I only explicitly added v384.xx variables that I specifically needed to be able to restore and also implemented the 'Unset' NVRAM variable feature.

e.g. nvram-rmerlin.ini v384.xx NVRAM variables

[VPN Server]
# Martineau Add following Base64 custom2  v384.xx replaced by 3 variables _cust2,_cust21 and _cust22
vpn_server1_cust2
vpn_server1_cust21
vpn_server1_cust22
# Martineau Add following Base64 custom2  v384.xx replaced by 3 variables _cust2,_cust21 and _cust22
vpn_server2_cust2
vpn_server2_cust21
vpn_server2_cust22

[VPN Client]
# Martineau Add following Base64 custom2  v384.xx replaced by 3 variables _cust2,_cust21 and _cust22
vpn_client1_cust2
vpn_client1_cust21
vpn_client1_cust22
# Martineau Add following Base64 custom2  v384.xx replaced by 3 variables _cust2,_cust21 and _cust22
vpn_client2_cust2
vpn_client2_cust21
vpn_client2_cust22
# Martineau Add following Base64 custom2  v384.xx replaced by 3 variables _cust2,_cust21 and _cust22
vpn_client3_cust2
vpn_client3_cust21
vpn_client3_cust22
# Martineau Add following Base64 custom2  v384.xx replaced by 3 variables _cust2,_cust21 and _cust22
vpn_client4_cust2
vpn_client4_cust21
vpn_client4_cust22
# Martineau Add following Base64 custom2  v384.xx replaced by 3 variables _cust2,_cust21 and _cust22
vpn_client5_cust2
vpn_client5_cust21
vpn_client5_cust22

[DHCP settings]
# Martineau For nvram-save.sh v30.1 add HND-Marker for variables on /jffs/nvram/
?dhcp_staticlist
?dhcp_hostnames
# Martineau Add dhcp_hostnames due to new format of variable dhcp_staticlist v384.13

[WAN Configuration]
# Martineau Add v384.12
dns_local
dns_local_cache

# Martineau tweak
[Unset - NVRAM variables]
>Martineauwifivpn_fd

You are still welcome to my revised script, but without ALL of the v384.xx NVRAM variables defined in

'nvram-rmerlin.ini'

you would not be able to FULLY restore a v384.xx router, but then again you should be using the GUI Save/Restore for that anyway?

 

[Xentrk]

I have some availability coming up and plan to resume work on the script. I was making good progress on it but put it on temporary hold to accommodate some update requests for x3mRouting. I'm focusing on making the code POSIX compliant and am close to being done with that phase. I will then test. Once that is done, I will code an installation menu.

 

[Rudi Pittman]

My script proposal post #648 was acknowledged post #666 but never published by @john9527.

I presumed he had rejected my modifications (see post #736), and without his approval, deemed it a courtesy to withhold releasing my unofficial version.

Since this script has been "semi-abandoned" would you mind sharing the modded version you have available? Your changes seem like sane ones to me. I successfully upgraded a router from 380.70 after taking a backup, installed 384.13, factory reset then restored the backup. I did end up having to run the clear_macid.sh script because the qos list, network map and a few other places were not populating but worked fine after that. I have 2 freenas servers and each of the jails within it gets it's own ip address so I had alot of static ip address's tied to macid's and didn't want to have to redo all of them again.

 

[Yiannis]

I would like to report a problem with the utility.
It looks it didn't restore Custom Configuration at ovpn VPN server section.