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.
Your environment appears to be seriously broken :confused:, the readlink command is missing and "nvram get" isn't working.

What firmware version are you running? What custom software have you installed (entware, ad-blockers, etc.)?

I am running:
Firmware: DD-WRT v3.0-r35244 big (03/05/18)

Custom software if it fits on the category you are asking is YAMon.
 
I have so many settings and doing it manually would be a royal pain

I was think about this this morning.

I too would like to update from 380.68_4 on an RT-AC66U to the latest Merlin on a yet-to-be-purchased RT-AC86U. The pain of transferring the settings is what is puttiing me off buying the new router.

I was wondering if it is possible to set up old and new routers on the table, each connected to a separate laptop, side by side. Then go through each set-up screen on the old router, and enter the equivalent settings in the new router, using the second laptop.

Of course, the 2 routers would have to be kept completely separate, only one connected on the WAN side, and only one with working radio.

Did anyone try this please ? How did it work out ? Are most of the settings on equivalent screens, or are they moved around so much that this approach is impractical ?
 
I was think about this this morning.

I too would like to update from 380.68_4 on an RT-AC66U to the latest Merlin on a yet-to-be-purchased RT-AC86U. The pain of transferring the settings is what is puttiing me off buying the new router.

I was wondering if it is possible to set up old and new routers on the table, each connected to a separate laptop, side by side. Then go through each set-up screen on the old router, and enter the equivalent settings in the new router, using the second laptop.

Of course, the 2 routers would have to be kept completely separate, only one connected on the WAN side, and only one with working radio.

Did anyone try this please ? How did it work out ? Are most of the settings on equivalent screens, or are they moved around so much that this approach is impractical ?
Screen shots are your friend no need to have side by side router config pages.
 
I was think about this this morning.

I too would like to update from 380.68_4 on an RT-AC66U to the latest Merlin on a yet-to-be-purchased RT-AC86U. The pain of transferring the settings is what is puttiing me off buying the new router.

I was wondering if it is possible to set up old and new routers on the table, each connected to a separate laptop, side by side. Then go through each set-up screen on the old router, and enter the equivalent settings in the new router, using the second laptop.

Of course, the 2 routers would have to be kept completely separate, only one connected on the WAN side, and only one with working radio.

Did anyone try this please ? How did it work out ? Are most of the settings on equivalent screens, or are they moved around so much that this approach is impractical ?
That is what I did. 68u -> 86u.
 
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.
 
Has author's of this utility moved on to other projects? Of course he is not obligated to keep this up to date, just curious about the ownership of this utility.
 
Has author's of this utility moved on to other projects? Of course he is not obligated to keep this up to date, just curious about the ownership of this utility.
@john9527 does the fork for older devices its the top post in the forum. Right now back porting all the changes must be bitch.
 
So I understand correctly: the only issue would be that the new features in 384 (Alexa, IFTTT, new settings) won't be saved/restored with the current version of these scripts, correct?
 
So I understand correctly: the only issue would be that the new features in 384 (Alexa, IFTTT, new settings) won't be saved/restored with the current version of these scripts, correct?
Exactly.
 
So I understand correctly: the only issue would be that the new features in 384 (Alexa, IFTTT, new settings) won't be saved/restored with the current version of these scripts, correct?

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...

Code:
./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 :eek:
 
Last edited:

So it's not really that different then? I was under the impression you meant that since they are different codebases, restoring would be impossible.

But from what I can see here, it's only new settings that wouldn't work, which is a non-issue since going from 380 to NG there would not be any new settings to restore yet.

Interesting developments to say the least. I will of course continue to follow this with great interest.
 
So it's not really that different then? I was under the impression you meant that since they are different codebases, restoring would be impossible.

But from what I can see here, it's only new settings that wouldn't work, which is a non-issue since going from 380 to NG there would not be any new settings to restore yet.

Interesting developments to say the least. I will of course continue to follow this with great interest.
@Martineau has a very important point about the changes between 380 and 384 depending on your current settings you could import a really messed up situation and would either be unstable or need to be reset anyway.
 
But from what I can see here, it's only new settings that wouldn't work, which is a non-issue since going from 380 to NG there would not be any new settings to restore yet.
Not quite. As @Martineau pointed out, some of the existing settings now have a reduced maximum length, leading to the possibility of the data being truncated.
 
Not quite. As @Martineau pointed out, some of the existing settings now have a reduced maximum length, leading to the possibility of the data being truncated.

I saw the script example. But I don't know how to use it. Is the a possibility to write a script and run over SSH or something to find out which of my NVRAM values would be at risk, if any?
 
I saw the script example. But I don't know how to use it. Is the a possibility to write a script and run over SSH or something to find out which of my NVRAM values would be at risk, if any?
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.
 
and also it is now in base64 encoding format :eek:

I had to do that because libnvram (at least the HND one) was choking on variables containing carriage returns. Base64 encoding was the only safe way to work around this new limitation - at least in a clean way. I don't like the old /s/\/r\/n/>/g method I used in the past with certificates.
 
I had to do that because libnvram (at least the HND one) was choking on variables containing carriage returns. Base64 encoding was the only safe way to work around this new limitation - at least in a clean way. I don't like the old /s/\/r\/n/>/g method I used in the past with certificates.

I fully understand the technical advantages for the use of the base64 format, it's just a pity that unlike @john9527 's firmware

Code:
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

e.g. openvpnserverX.postconf
Code:
        Chk_Entware 'base64' || { Say "***ERROR*** Entware" $ENTWARE_UTILITY "not available";exit 99; }
       
        Say "VPN Server" $VPN_ID "will BIND to" $BIND_IP "via virtual interface '"$GUI_VPN_IF"'"
        sed -i "s/^nobind.*$//" $CONFIG                
        sed -i "s/^local.*$/local $BIND_IP/" $CONFIG    # Replace the virtual 'local wanX' to force the VPN Server to BIND to the desired WAN interface
        # Update GUI to advise user which interface the VPN Server was bound/connected thru'
        # e.g. nvram set vpn_serverX_custom="<existing local wanX> # yyyymmddhhmm Last BIND to $BIND_IP via $VPN_IF"
        # v384.xx the Customisation is now called 'vpn_server"$VPN_ID"_custom2' and is in Base64 format!!!
        NVRAM_VAR="vpn_server"$VPN_ID"_custom2"
        BINDDATE=$(date +%Y%m%d%H%M)
        CMD="$(NVRAM_Edit $NVRAM_VAR "$(echo -e "local ${GUI_VPN_IF}.*")" "$(echo -e "local $GUI_VPN_IF # $BINDDATE Last BIND to $BIND_IP via "$VPN_IF"") ")"
        CMD=$(echo "$CMD" | base64)                     # Encode back into base64
        nvram set $NVRAM_VAR="$CMD"                     # Update the NVRAM variable....visible in the GUI
 
Status
Not open for further replies.

Latest threads

Sign Up For SNBForums Daily Digest

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