OpenWrt Forum Archive

Topic: Completely clearing NVRAM back to pre-OpenWRT settings

The content of this topic has been archived on 21 Mar 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.


I really hope I'm not duplicating here, but I've searched high and low with no results on this issue.

Basically, I've set some nvram variables to some settings that mean I can't access the internet from my wifi hotspot. Not much use as a hotspot! I'm running OpenWRT WhiteRussian (so's I can use NoDogSplash happily) and all I want to do is get everything back to how it should be on a completely fresh install.

Sadly even flashing back to linksys firmware and asking for a return to factory settings leaves nvram variables from openwrt untouched! I flash back to openwrt and voila, my DNS is still there, my broken bridge is still there, everything.

I am tearing my hair out here! Somebody help me save my access point please? smile

Thanks a million.

The concept I use is to completely erase NVRAM which should trigger the basic initialization of NVRAM by the CFE (boot code) on the next boot.  Whiterussian will set a few trivial ones (not many) during its initialization.  I've never had trouble on WRT54G v4 (same as WRT54GL) and WRT54GS v3 but have read others not so lucky on earlier versions.

So... In Whiterussian... at your own risk...

mtd -r erase nvram

The -r option reboots when its done.  It'll be defaults (like  Be sure and give it 10 minutes before even thinking of resetting or powering it off if it's not responding.  Good luck!

OK, I'm happy to do this if the answer to my next question (which I foolishly forgot to include), is a yes. I'm currently running a WRT45G v1.1 - is this safe to do?

Yeah I thought so.

How would wiping all the nvram parameters and then comitting a select set of booting ones work before a reboot? What ones would I realistically need to commit to allow it to flash back up?

I believe THAT would be the most dangerous for bricking.  I don't know what the CFE uses to declare the NVRAM bad to trigger the writing of all the default variables and it might get stuck in between.

Also, I have no idea why the 1.1 is "not safe".  Does it work sometimes?  Never?  Isn't designed like later versions?  Will it work with certain precautions?

Tell you what... here's my list of variables in a WRT54G v4 immediately after ereasing then booting Whiterussian 0.9:

***eou_private_key=(a big key not to touch)
***eou_public_key=(a big key not to touch)
lan_ifnames=vlan0 eth1 eth2
***vlan0ports=3 2 1 0 5*
***vlan1ports=4 5

There isn't many.  I flagged "***" on everything that configures possibly different hardware with different values.  Others configure things like network and wireless.  The "(unique) is for things like MAC addresses that mine does you no good.  I'm not at all sure what ??? might do if it were different.  It's obvious some, like SSID, is from Whiterussian's initialize.

Anything else you see may be due to your bad HotSpot config, assuming it's in NVRAM.

EDIT: boot_wait defaults OFF but when ON enables a short boot window for tftp flashing of Linksys-formatted *.bin files.  It says OFF only because that's the default.


(Last edited by Bill_MI on 1 Apr 2010, 07:19)

~# nvram show <-shows all the nvram variables
~# nvram show | less <- lets you review each variable
~# nvram show > file <- saves the list to a file which you can transfer somewhere so you can review the settings
~# nvram set lan_ipaddr= <- blanks the value for lan_ipaddr
~# nvram commit <- saves your changes

it's safe, tedious and tiring.  but it's safe. big_smile

The above list was created with: nvram show | sort it's alphabetical.  Keeps both in order.

Also, you have the way to make a variable BLANK.  To make it not exist:

nvram unset lan_ipaddr
(bad example... you need that one smile )

(Last edited by Bill_MI on 1 Apr 2010, 18:11)

The discussion might have continued from here.