Posted: Thu Jun 13, 2019 3:10 Post subject: "Reset, or Not Reset, That is the Question..."
Clearing my thoughts...
I see a lot of users that doesnt reset when upgrade to a new build. So if we are testers of all this builds, we have to do it on a way that is a fresh flash, to identify new bugs or old ones that still are present... right?
Then whats the point to uprade/test without reset, if you bring the old config that may work over the new build, but if you do a fresh config, it may not work at all. And using it during some time without really know if it is stable... I think that would be a "false positive" and you could lose the point/moment when a bug is introduce.
If you are really testing new builds, i think it should have 2 stages:
1) flash without reset -> test some time;
then
2) Clear all config -> test some time;
And compare results between both stages. Or if you dont have the time, just do: 2.1) Clear all config -> flash build -> clear again -> test some time; but never do stage 1 only.
I could say too, to add log files, but im sure that is pointless unless you get a critical issue, cause the time that devs must invest. But thats another affair.
Posted: Fri Jun 14, 2019 15:43 Post subject: Re: "Reset, or Not Reset, That is the Question..."
There's no need to reset if no issues are found, except for:
-Before and after flash from OEM
-Making large jumps in build versions
-Kernel version changes (including in- or outside of a build type)
It (and esp the 30/30/30) is an ancient relic of early WRT54G days. If you backpack into remote prehistoric caves on the outskirts of Dresden in Germany, you can still find "30/30/30" carved into the stone with bone fragments.
reset to factory defaults is nothing i advice. thats more a panic button for most users here. i upgrade all my devices without a reset and i take care that all is backward compatible.
Certainly, if issues are found, one should reset and manually set up to confirm it isn't nvram-related.
if you have no problems, then no erase. If you have problems and want to rule out something strange use "erase nvram"
If the issue is still present, logs and other relevent info should be provided, which my (Broadcom) new build threads state:
New Build threads' wrote:
Important: if any issues are found, please provide log info (GUI syslog, `dmesg`, `cat /var/log/messages`).
Or put into SVN ticket. For firewall issues, also provide "iptables" info (`iptables -L`, `iptables -t nat -L`, & the /tmp/.ipt file).
But ya, it needs to specify the reset part too, though it is stated often when issues are reported. I will update it on my next build thread; thanks! _________________ #NAT/SFE/CTF: limited speed w/ DD#Repeater issues#DD-WRT info: FAQ, Builds, Types, Modes, Changes, Demo#
OPNsense x64 5050e ITX|DD: DIR-810L, 2*EA6900@1GHz, R6300v1, RT-N66U@663, WNDR4000@533, E1500@353,
WRT54G{Lv1.1,Sv6}@250|FreshTomato: F7D8302@532|OpenWRT: F9K1119v1, RT-ACRH13, R6220, WNDR3700v4
Joined: 18 Mar 2014 Posts: 12834 Location: Netherlands
Posted: Fri Jun 14, 2019 16:12 Post subject:
I totally agree with @jwh7 about when to reset.
I test a lot of new builds and only reset when experiencing problems, that amounts to about resetting twice a year. But I tinker a lot
But to add my thoughts:
Reset after upgrading
Best way to reset for builds from mid 2018 and onwards is telnet into your router and do:
Code:
nvram erase && reboot
If you reset, put settings in manually.
Restoring from backup gives you the same garbage back.
But to add my thoughts:
Reset after upgrading
Best way to reset for builds from mid 2018 and onwards is telnet into your router and do:
Code:
nvram erase && reboot
If you reset, put settings in manually.
Restoring from backup gives you the same garbage back.
Disclamer: There could be specific routers which do not like nvram erase, although all my routers are fond of it
Ya, the only reason to reset before an upgrade is if there isn't enough memory available to download and flash the new firmware, or similarly, if almost out of nvram. I should note that the Reset wiki does give details about the 'nvram erase` change. I added it in January. _________________ #NAT/SFE/CTF: limited speed w/ DD#Repeater issues#DD-WRT info: FAQ, Builds, Types, Modes, Changes, Demo#
OPNsense x64 5050e ITX|DD: DIR-810L, 2*EA6900@1GHz, R6300v1, RT-N66U@663, WNDR4000@533, E1500@353,
WRT54G{Lv1.1,Sv6}@250|FreshTomato: F7D8302@532|OpenWRT: F9K1119v1, RT-ACRH13, R6220, WNDR3700v4
Posted: Fri Jun 14, 2019 16:42 Post subject: Re: "Reset, or Not Reset, That is the Question..."
jwh7 wrote:
There's no need to reset if no issues are found, except for:
-Before and after flash from OEM
-Making large jumps in build versions
-Kernel version changes (including in- or outside of a build type)
It (and esp the 30/30/30) is an ancient relic of early WRT54G days. If you backpack into remote prehistoric caves on the outskirts of Dresden in Germany, you can still find "30/30/30" carved into the stone with bone fragments.
reset to factory defaults is nothing i advice. thats more a panic button for most users here. i upgrade all my devices without a reset and i take care that all is backward compatible.
Certainly, if issues are found, one should reset and manually set up to confirm it isn't nvram-related.
if you have no problems, then no erase. If you have problems and want to rule out something strange use "erase nvram"
If the issue is still present, logs and other relevent info should be provided, which my (Broadcom) new build threads state:
New Build threads' wrote:
Important: if any issues are found, please provide log info (GUI syslog, `dmesg`, `cat /var/log/messages`).
Or put into SVN ticket. For firewall issues, also provide "iptables" info (`iptables -L`, `iptables -t nat -L`, & the /tmp/.ipt file).
But ya, it needs to specify the reset part too, though it is stated often when issues are reported. I will update it on my next build thread; thanks!
Quote:
Kernel version changes
e.g. Linux 3.10.108-d8 #24891
that means all "3", "10", "108", "d8" or the "#" number?
Ya, such as (when using capable routers) changing Broadcom MIPS NOR flash routers between v2.4, v2.6, and v3.x. But also when BS switched K3X from v3.4 to v3.10, and for non-Broadcom changes from v4.4 to v4.9 to now 4.14. I think also BCM ARM (and MIPS NAND) might have changed from v3.18 to v4.4 at some point. _________________ #NAT/SFE/CTF: limited speed w/ DD#Repeater issues#DD-WRT info: FAQ, Builds, Types, Modes, Changes, Demo#
OPNsense x64 5050e ITX|DD: DIR-810L, 2*EA6900@1GHz, R6300v1, RT-N66U@663, WNDR4000@533, E1500@353,
WRT54G{Lv1.1,Sv6}@250|FreshTomato: F7D8302@532|OpenWRT: F9K1119v1, RT-ACRH13, R6220, WNDR3700v4
Ya, such as (when using capable routers) changing Broadcom MIPS NOR flash routers between v2.4, v2.6, and v3.x. But also when BS switched K3X from v3.4 to v3.10, and for non-Broadcom changes from v4.4 to v4.9 to now 4.14. I think also BCM ARM (and MIPS NAND) might have changed from v3.18 to v4.4 at some point.
So I don't have to reset my router even when just the revision number or the stable version number changed?
Joined: 08 May 2018 Posts: 14125 Location: Texas, USA
Posted: Sat Jun 15, 2019 11:57 Post subject:
Really, the only time you'd want to clear nvram is when something in the base code or webUI changes drastically, and old settings might cause issues. For example. the recent udhcpd removal. A kernel or package version change is negligible. Just my $0.02
P.S. As best I could tell, there was really no need to reset, due to no real change in default nvram values, so...