What's new

Saving Configurations - Simplified Version

  • 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!

Ebartone

Occasional Visitor
I get that with many firmware updates, it is necessary to NOT bring back a formerly saved configuration, due to not only the "obvious" settings being saved in the configuration, but the NVRAM as well. But when this product is as dynamic as it is, and changing FW is so frequent (at least for me, and others that like to experiment), it becomes a bit old typing in all of the variables over and over. At least for me, beacuse I'm a fairly lazy person.

So question, sugestion, idea, outburst - could there be an option created in saving the configuration that would only save those parameters that are "typed" in, and not the NVRAM values, so this task could be avoided? Possibly that is getting too far away from the stock FW, but just thought I'd ask.

Thanks!
 
So question, sugestion, idea, outburst - could there be an option created in saving the configuration that would only save those parameters that are "typed" in, and not the NVRAM values, so this task could be avoided? Possibly that is getting too far away from the stock FW, but just thought I'd ask.

Thanks!

In general this would work, but success would depend on the particular two firmware versions involved. The structure/format of "typed in" values, especially those which have a series of fields per value (like IP reservations, for example) may change between two releases. (They usually don't, but could.) So that's an example of a setting that could *usually* be imported without problem in most firmware upgrades (or downgrades), but might cause problems in a specific upgrade where data structure differed.

In other words, any comprehensive script that saved/restored values would have to be reviewed, tested, validated, and perhaps updated for every "combination" of two firmware versions involved (upgrade and downgrade). That's a big, complex task.

Of course the fewer settings addressed, the less likelihood of it causing a problem. And there are only a few settings that are really cumbersome to re-input, so the focus should be on those.

For myself, I created a couple of scripts that save/restore the few specific settings that take me the most time to re-input after a reset to defaults. One script saves everything in nvram for future reference, then saves selected entries into a file which will later be restored. The second script does the actual import/restore of that second file. The scripts reside (and store/retrieve their files) from a USB stick.

Those scripts are attached. DISCLAIMER: I am not a Linux guy nor a script-writer by trade, so these can probably be improved a lot -- but they work for me. :eek: I stole the concept from a post Merlin made quite a while back, then hacked together the scripts the best I could.

Note that you will need to change the path to files, depending on which mount point is assigned (sda1 or sda2) and what subfolder you create for your files.


--Script to export settings--
Code:
#!/bin/sh

FN="/mnt/sda1/Settings/AllSettings.txt"
nvram show >$FN

FN="/mnt/sda1/Settings/settings.txt"
echo "vts_rulelist=`nvram get vts_rulelist`" >$FN
echo "dhcp_staticlist=`nvram get dhcp_staticlist`" >>$FN
echo "dhcp_static_x=`nvram get dhcp_static_x`" >>$FN
echo "dhcp_start=`nvram get dhcp_start`" >>$FN
echo "dhcp_end=`nvram get dhcp_end`" >>$FN
echo "ipv6_service=`nvram get ipv6_service`" >>$FN
echo "lan_ipaddr=`nvram get lan_ipaddr`" >>$FN
echo "lan_ipaddr_rt=`nvram get lan_ipaddr_rt`" >>$FN
echo "lan_netmask=`nvram get lan_netmask`" >>$FN
echo "lan_netmask_rt=`nvram get lan_netmask_rt`" >>$FN

--Script to import selected settings--
Code:
#!/bin/sh

FN="/mnt/sda1/Settings/settings.txt"
while read line
do
	echo ${line}
	nvram set ${line} || exit 1
done < $FN
nvram commit
 
Last edited:
Better Approach?

This is perhaps a better approach than the scripts in my previous post?

Instead of two scripts and a text file, this uses a single "export_settings.sh" script, with an easy-to-revise list of desired setting names. When executed, it creates a "restore_settings.sh" script that can be executed later to restore the selected settings.

That seems cleaner... But again, I know NOTHING about Linux scripting, so someone feel free to jump in with an improved approach or correct any errors!

-- export_settings.sh --
Code:
#!/bin/sh

#location for files
 FLOC="/mnt/sda1/Settings"
#name of file for reference copy of ALL settings
 AllSetFN="AllSettings.txt"
#name of generated script file that will restore selected settings
 MySetFN="restore_settings.sh"

#define list of selected settings to be exported
MySettings="\
vts_rulelist
dhcp_staticlist
dhcp_static_x
dhcp_start
dhcp_end
dhcp_lease
ipv6_service
lan_ipaddr
lan_ipaddr_rt
lan_netmask
lan_netmask_rt
st_samba_workgroup
sshd_enable
sshd_pass
time_zone
time_zone_x
ddns_enable_x
ddns_hostname_x
ddns_server_x
wl0_macmode
wl0_maclist
wl0_maclist_x
wl1_macmode
wl1_maclist
wl1_maclist_x
wl0_ssid
wl1_ssid
computer_name
wan_upnp_enable
wan0_upnp_enable
wl0_chanspec
wl1_chanspec
wl0_wpa_psk
wl1_wpa_psk
wl0_auth_mode_x
wl1_auth_mode_x"


#save reference copy of all settings
nvram show | sort >$FLOC/$AllSetFN

#generate the script that will restore selected settings
FN=$FLOC/$MySetFN
echo "#!/bin/sh" >$FN
echo >>$FN
echo "# generated script to restore selected nvram settings" >>$FN
echo >>$FN
for S in $MySettings
do
   echo "nvram set $S=\"`nvram get $S`\"" >>$FN
done
echo "nvram commit" >>$FN
 
Last edited:

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

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