User NVRAM Save/Restore Utility (R26.2)

[ozzed]

From this post:

nvram show | awk '{print length(), $0 | "sort -n -r"}' | cut -d"=" -f 1 | head

Also worth reading: this. You can see that it's still a work in progress with some variables being allowed longer lengths.

Thank you I get the following result:

size: 49476 bytes (16060 left)
1089 sshd_hostkey
624 sshd_dsskey
394 rc_support
365 dhcp_staticlist
338 sshd_ecdsakey
338 client_info_tmp
129 custom_clientlist
120 qos_rulelist
117 wps_env_buf
102 asus_device_list

So there would probably be issues, as if I understand it correctly, the result would be enpty if no values exceeded the limit.

 

[ColinTaylor]

, as if I understand it correctly, the result would be enpty if no values exceeded the limit.

No, that is just a list of your NVRAM variables sorted by size and showing the top 10. Any that exceed, say 150 bytes, might need some further attention.

 

[Martineau]

Any that exceed, say 150 bytes, might need some further attention.

Depends on the variable....
v384 NVRAM variable size limitation

 

[ColinTaylor]

Depends on the variable....
v384 NVRAM variable size limitation

Indeed, that was my point (post #718).

 

[Rolo]

For v384.xx, Asus now impose strict NVRAM variable size limits.

So potentially you could have say a very long v380.xx DHCP Reserved address list that would be truncated during the v384.xx restore resulting in a corrupt variable.

I'm probably missing something but what would this have to do with this script specifically? If my 380 variable is too long for 384, then won't that be a problem as soon as I update to 384?

Specific to me, already on 384 and having made backups from 384, were I to reset and restore, I would not lose anything, correct?

I really only care about the DHCP reservations (it drives me nuts that they incorrectly call them "static") and icons and probably the SSH key. Everything else doesn't take long to fat-finger vs. checking it after a restore anyway.

 

[ColinTaylor]

I'm probably missing something but what would this have to do with this script specifically? If my 380 variable is too long for 384, then won't that be a problem as soon as I update to 384?

Presumably (or not) there's some sort of migration process happening when you update the firmware. Whether there is or not, this script doesn't know anything about it or how it works.

Specific to me, already on 384 and having made backups from 384, were I to reset and restore, I would not lose anything, correct?

Most of the discussion here is about going from 380 to 384. But if you're currently on 384 then the variable length issue shouldn't be a problem. However this script will not be backing up all of your variables because it's not aware of the ones introduced in 384.

 

[RMerlin]

it's just a pity that unlike @john9527 's firmware

Included additional BusyBox applets hd, od and base64

for your firmware it is necessary to install the base64 utility from Entware as I dynamically update the OpenVPN Configuration GUI

John added this only a week ago, give me a break... Changes don't happen overnight.

 

[Martineau]

...give me a break

Well a simple "Whoops! mea culpa, but thanks for reminding me and I'll add it to the next release" would have sufficed?

...changes don't happen overnight.

Indeed they don't.

I recall the v382.2 Beta debuted for the RT-AC68U on Dec 30th 2017? and the use of base64 and the removal of the legacy variable etc. (was it in a change log?) subsequently carried thru' to v384.4 is therefore nearly 3 months old?

John added this only a week ago

With all due respect to @john9527 he is presumably still playing follow-my-leader and to save unnecessary work only cherry picks appropriate backports to his fork when you publish a new non-beta final release - yet to his credit, diligently spotted the omission and included it in his recent release.

 

[bmb]

For v384.xx, Asus now impose strict NVRAM variable size limits.

So potentially you could have say a very long v380.xx DHCP Reserved address list that would be truncated during the v384.xx restore resulting in a corrupt variable.

I would advise that you check the current size of your NVRAM variables before deploying the restore utility.

e.g. I wrote a script...

./NVRAMDump.sh -h

Current NVRAM variables using >99 bytes Summary:
2288  dhcp_staticlist
1767  custom_clientlist
810  nc_setting_conf
568  vpn_server1_custom2
508  vpn_client5_custom2
492  vpn_client1_custom2
474  rc_support
452  vpn_client2_custom2
228  wl1_acs_excl_chans
205  wl1_chansps
192  vpn_client4_custom2
191  vpn_client_custom2
189  vpn_serverx_clientlist
120  qos_rulelist

Total:62294/65536 Free:3242

Vars with no value Total:10493

NOTE: Pay attention to one of the OpenVPN NVRAM variables as one name has changed and also it is now in base64 encoding format

I used the restore script in migrate mode (380 - 384) before reading about possiblel issues. Everything seemed OK for a few days then I began having problems after making a change to one device in the DHCP reserve list (long list), some devices lost ipv4 connectivity and others lost ipv6. I've now initialized the router (AC87U) and started with a clean slate and all is good again.

So this advice from Martineau could save anyone a lot of potential messing around.

 

[RMerlin]

I recall the v382.2 Beta debuted for the RT-AC68U on Dec 30th 2017? and the use of base64 and the removal of the legacy variable etc. (was it in a change log?) subsequently carried thru' to v384.4 is therefore nearly 3 months old?

There was no reason at the time for adding the base64 applet. I only add new applets if strictly necessary, because each applet increases the footprint of the busybox binary, and since busybox is implemented as a single binary, it means every time it runs any of its applets, it will require to be fully loaded in memory.

The only reason now is to maintain applet parity with John, something we've already been trying to do in the past. Since he only released a firmware with it a week ago (which was the first time I heard it was being added), it was too late to add it to 384.4. At that point the focus was on finalizing 384.4 so I could finally get it out with all the stability fixes it was going to bring. There was BB work already scheduled to be done in 384.5, such as merging the 1.24 and 1.25 installs into a single install, followed by investigation into possibly updated the version. Only after that would I be willing to look at re-achieving applet parity with John's fork.

The reason I answered the way I did is because it's not the first time I feel one of your comments toward my development plan come off as snarky.

 

[ColinTaylor]

Well a simple "Whoops! mea culpa, but thanks for reminding me and I'll add it to the next release" would have sufficed?

I don't think Merlin needs to apologise for your personal scripts being incompatible with the latest firmware. To suggest he does is frankly insulting.

 

[RMerlin]

Appreciate the feedback folks, but let's drop the matter. What had to be said has been said by now.

 

[st3v3n]

I too had been waiting for the utility to be updated before making the decision to upgrade from 380 code base to 384. I support several routers and wanted to avoid manually entering the configuration. I finally decided to do it. I used the instructions here to back up nvram values so I could avoid having to renter static dhcp assignments. I used the snipping tool to take screen shots of key screens. I used the built in utility to save jffs partition and Configuration in case I needed to revert. I also used SFTP session to make another backup copy of jffs and usb drive to my laptop. I had no issue restoring jffs using the built in jffs restore utility. I saw one user who did though.

Xentrx, how did your migration to v384 work out, or is it too soon to say? We've been waiting for things to stabilize before jumping up from 380.68_4, which is still 100% stable/rock solid. Cheers.

 

[ozzed]

Appreciate the feedback folks, but let's drop the matter. What had to be said has been said by now.

I did not mean for this to turn into what it did and I apologize if my comments triggered things that are better left alone.

I appreciate yours and others contribution to this firmware and am very thankful for it, taking nothing for granted. The only reason I'm asking about the compatibility with this migration tool is because for me the convenience of using it is worth the wait for a compatible version, if there will be one.

As a side-question... Will 308.70 be compatible with the RT-AC87U or will it only be for the models that will not be migrated to NG?

 

[RMerlin]

As a side-question... Will 308.70 be compatible with the RT-AC87U or will it only be for the models that will not be migrated to NG?

Yes, 380.70 will be available for all models (except the RT-AC86U which isn't supported by this old code).

 

[john9527]

Sorry everyone for being away a bit....I have some personal demands on my time right now that are keeping me busy.....

Included additional BusyBox applets hd, od and base64

These were added so I could do a decode of the new DNSCrypt v2 resolvers file (If you want so see some 'ugly' code, take a look at dnscrypt-update-resolvers.sh in my fork which decodes/converts the v2 file into a v1 csv). Note that you don't really need base64 as you can do it with openssl as well, it's just that in case of an error the output was easier to deal with in Busybox's stripped version.

For the utility, the comments are correct. The hurdles for me to get over....
- The new metadata in the nvram defaults in the source broke some scripts I had written to extract the data I need.
- As mentioned, the big problem in 380 -> 384 migration is the possibility of exceeding the new nvram length checks. This is something that can be handled, but it needs to be coded as well as adding the length info to the nvram ini file.
- Part of the new nvram metadata also indicates that at some point encryption is going to be added to some of the variables. I don't know yet what this is going to mean for the utility.
- Extracting the 'user' variables to backup/restore for each new release is getting to be difficult. I'm looking at moving to some sort of 'exclude' model rather than an 'include' model, but this is going to take a redesign and some time.

 

[ozzed]

Yes, 380.70 will be available for all models (except the RT-AC86U which isn't supported by this old code).

Allright, thanks I'll probably upgrade to 380.70 then and take the wait and see approach.

Sorry everyone for being away a bit....I have some personal demands on my time right now that are keeping me busy.....


These were added so I could do a decode of the new DNSCrypt v2 resolvers file (If you want so see some 'ugly' code, take a look at dnscrypt-update-resolvers.sh in my fork which decodes/converts the v2 file into a v1 csv). Note that you don't really need base64 as you can do it with openssl as well, it's just that in case of an error the output was easier to deal with in Busybox's stripped version.

For the utility, the comments are correct. The hurdles for me to get over....
- The new metadata in the nvram defaults in the source broke some scripts I had written to extract the data I need.
- As mentioned, the big problem in 380 -> 384 migration is the possibility of exceeding the new nvram length checks. This is something that can be handled, but it needs to be coded as well as adding the length info to the nvram ini file.
- Part of the new nvram metadata also indicates that at some point encryption is going to be added to some of the variables. I don't know yet what this is going to mean for the utility.
- Extracting the 'user' variables to backup/restore for each new release is getting to be difficult. I'm looking at moving to some sort of 'exclude' model rather than an 'include' model, but this is going to take a redesign and some time.

Thanks for getting back regarding this

It sucks that some values will eventually be encrypted. It's not very open and user friendly on ASUS's part, but not much that can be done if they do chose that path.

 

[Xentrk]

Xentrx, how did your migration to v384 work out, or is it too soon to say? We've been waiting for things to stabilize before jumping up from 380.68_4, which is still 100% stable/rock solid. Cheers.

No problems to report. I have done the upgrade on three routers now. I plan to launch a blog site soon and just finished the instructions on the method I used. I hope to post it in a few days. If you want, I can post the word version to Dropbox and send you a link. Would be good to have another pair of eyes look at it.

 

[st3v3n]

Glad to hear it, appreciate it when you have time.

 

[Xentrk]

Glad to hear it, appreciate it when you have time.

Link sent in PM.