[R7800] Will no longer save settings after reboot.

[HELLO_wORLD]

Also, there is a potential fix to this problem. No a solution as it does not solve the NAND issue, but a workable fix as another alternative to using openwrt.
When I started to experience this problem, I quickly realized that the nvram save and restore commands would be useful and using them would be faster than manually entering everything at each reboot. The problem was still the need to reboot for certain parameters to be activated, and of course rebooting would delete the parameter...
@kamoj came with an experimental init.d script that would restore early in the boot process the nvram from a previously saved state, and it worked on my defective R7800. Of course, I could not experiment a lot, so we did not go very far with that, but I the little experience I had with it seems to show that it is a real potential fix.
I made a little backup script to save the nvram in a way that is compatible with @kamoj ’s experimental restore script in case I would need it in the future (hopefully not), and it also makes a time stamped backup on the external drive.

 

[verbage]

Also, there is a potential fix to this problem. No a solution as it does not solve the NAND issue, but a workable fix as another alternative to using openwrt.
When I started to experience this problem, I quickly realized that the nvram save and restore commands would be useful and using them would be faster than manually entering everything at each reboot. The problem was still the need to reboot for certain parameters to be activated, and of course rebooting would delete the parameter...
@kamoj came with an experimental init.d script that would restore early in the boot process the nvram from a previously saved state, and it worked on my defective R7800. Of course, I could not experiment a lot, so we did not go very far with that, but I the little experience I had with it seems to show that it is a real potential fix.
I made a little backup script to save the nvram in a way that is compatible with @kamoj ’s experimental restore script in case I would need it in the future (hopefully not), and it also makes a time stamped backup on the external drive.

Oh, this is great! And if you and @kamoj can share the details, that would be cool! Regarding the file that holds a backup of the nvram from a previously saved state, is this specifically a configuration settings backup file that one might have produced through the web GUI previously (like before the problem emerged). Or is it some type of intermediate snapshot of the nvram after the router has failed, but once again after setting up your configuration? And this nvram snapshot can be loaded on the fly from a USB drive early in the boot process essentially bypassing the nvram config data stored in the mtd11 partition? I am sure I am messing something up, but I would be thrilled to hear more details!

 

[kamoj]

I have stayed out of the testing of this backup/restore thing, concentrating on bug-fixing the add-on
and adding other functions, while @HELLO_wORLD did the hard work -and had a defective device.

If I could get more of his experience in PM e.g., I could make an add-on for our enhanced scripts.
The add-on would make automatic backups, restore at boot, show a list of restore points, have manual backup option, error detection, logging etc.
@vergabe: The backup/restore configuration file would be compatible withe the ones created from the GUI,
with the option to get it out as a readable file as well.

PS
Work on this depends on my time (priority), helpers and testers like @HELLO_wORLD, and demand.

 

[HELLO_wORLD]

As I said, @kamoj kindly shared with me his script, and it is very experimental and potentially dangerous, that’s why it is not public.
Messing with it could brick the router, requiring tftp restore.

Independently of this script, the nvram can get corrupted in between reboots (I lost once my settings without a reboot) while I was changing a setting from GUI, so any commit operation to nvram is a risk, therefore any automated backup of nvram could potentially save a corrupted state and restoration would carry that corruption (I am talking only when the NAND is defective).
When the nvram is systematically erased between reboots, then there nothing to lose in having a automated restore early in the boot process, and I know from experience that it works.
So to summarize :
For those having problems with nvram resets, and can’t RMA, without any warranty, the best practice would be to:
1) install the restore script from @kamoj . I already made a kind of an installer for it, so I will check with @kamoj by PM about that.
2) doing a manual backups of the nvram when the router is setup the way you need. I can provide my simple backup script for that.
Any automated backup is dangerous as it may save a corrupted state.

To enter more into details for those who are interested, there is only one place where a backup can be done in a way it can be read at boot time: the NAND... No USB drive is readable at that point.
So the backup file we want to be restored at boot can only be in the root fs, that is segment 6 of MTD that hopefully is not corrupted like segment 11 (nvram). That’s what the script from @kamoj does.
My backup script is saving the backup where his script needs it in MTD6 as well as a time stamped version in the USB drive.

 

[Redbot]

@verbage I can confirm that my R7800 is saving its settings again after sitting in a box for a week. I don't trust it any more though, and have moved on.

@kamoj would my r7800 help you test? Send me your address and I'll ship it to you tomorrow.

 

[tommytqt]

@verbage I can confirm that my R7800 is saving its settings again after sitting in a box for a week. I don't trust it any more though, and have moved on.

@kamoj would my r7800 help you test? Send me your address and I'll ship it to you tomorrow.

Such a gentlemen !!!!
What have you moved on with? I am waiting for Wifi 6 to be a little more popular to upgrade my router.
Thank you.

 

[verbage]

I have stayed out of the testing of this backup/restore thing, concentrating on bug-fixing the add-on
and adding other functions, while @HELLO_wORLD did the hard work -and had a defective device.

If I could get more of his experience in PM e.g., I could make an add-on for our enhanced scripts.
The add-on would make automatic backups, restore at boot, show a list of restore points, have manual backup option, error detection, logging etc.
@vergabe: The backup/restore configuration file would be compatible withe the ones created from the GUI,
with the option to get it out as a readable file as well.

PS
Work on this depends on my time (priority), helpers and testers like @HELLO_wORLD, and demand.

Wow, wow, wow--this is great news!!! For sure, I completely understand this depends on your time, the overall demand for a solution, and finally, on end users who can feed you information and try things out to debug it. Of course, I am willing to help with the latter.

 

[verbage]

As I said, @kamoj kindly shared with me his script, and it is very experimental and potentially dangerous, that’s why it is not public.
Messing with it could brick the router, requiring tftp restore.

Independently of this script, the nvram can get corrupted in between reboots (I lost once my settings without a reboot) while I was changing a setting from GUI, so any commit operation to nvram is a risk, therefore any automated backup of nvram could potentially save a corrupted state and restoration would carry that corruption (I am talking only when the NAND is defective).
When the nvram is systematically erased between reboots, then there nothing to lose in having a automated restore early in the boot process, and I know from experience that it works.
So to summarize :
For those having problems with nvram resets, and can’t RMA, without any warranty, the best practice would be to:
1) install the restore script from @kamoj . I already made a kind of an installer for it, so I will check with @kamoj by PM about that.
2) doing a manual backups of the nvram when the router is setup the way you need. I can provide my simple backup script for that.
Any automated backup is dangerous as it may save a corrupted state.

To enter more into details for those who are interested, there is only one place where a backup can be done in a way it can be read at boot time: the NAND... No USB drive is readable at that point.
So the backup file we want to be restored at boot can only be in the root fs, that is segment 6 of MTD that hopefully is not corrupted like segment 11 (nvram). That’s what the script from @kamoj does.
My backup script is saving the backup where his script needs it in MTD6 as well as a time stamped version in the USB drive.

Thanks for the additional insight and details, @HELLO_wORLD. For sure, I understand this could be dangerous, i.e. that one could end up with a bricked router that would require a flash of the firmware using the tftp method vs. doing it by the normal web GUI method. So this would only be for folks who are willing to take that risk because they are at a point of desperation--warranty is expired, and they have no other option.

 

[HELLO_wORLD]

Funny thing...
I have to send back to defective router, so I did a factory reset... without success! All my settings stayed (SSID, etc...)
The reason is the init.d restore script that was restoring the nvram with my backup settings. Once I realized what was going on and removed the backup, factory reset worked.

That confirms 2 things:

1) the restore script early in boot process definitely works!

2) one side effect is that you cannot factory reset the router with the script installed and a backup file existing (as the settings in that backup file will be the ones loaded in nvram); in that case you need to be able to access the router using settings from backup to remove the backup file, then you can factory reset. It can cause problems with bad settings as it might be challenging to factory reset... A safeguard could be implemented in the script to not restore in certain conditions.

Anyway, the script should definitely help people encountering the problem, but some caution would be required, and using the script wouldn’t be advised for devices without the problem (the backup part would be safe and even recommanded.)

Wow, wow, wow--this is great news!!! For sure, I completely understand this depends on your time, the overall demand for a solution, and finally, on end users who can feed you information and try things out to debug it. Of course, I am willing to help with the latter.

 

[verbage]

@verbage I can confirm that my R7800 is saving its settings again after sitting in a box for a week. I don't trust it any more though, and have moved on.

@kamoj would my r7800 help you test? Send me your address and I'll ship it to you tomorrow.

@Redbot, this is a super-interesting observation that after your R8700 sat around for a week in a box, it seems to be working again and remembering settings. But I think you are right about not trusting it because I suspect the problem will return. So in your case and my case, leaving the router unplugged and unused for a period of time would have allowed it to cool down, and that potentially is a factor in allowing the router to again start functioning normally. But I suspect this is not a permanent fix--just a temporary respite--and the problem will eventually return. @HELLO_wORLD's first R7800 also started retaining settings again for a short period of time, but he did not have to leave it unplugged and unused for this to occur so it's not a straightforward case for heat being a factor.

 

[verbage]

2) one side effect is that you cannot factory reset the router with the script installed and a backup file existing (as the settings in that backup file will be the ones loaded in nvram); in that case you need to be able to access the router using settings from backup to remove the backup file, then you can factory reset. It can cause problems with bad settings as it might be challenging to factory reset... A safeguard could be implemented in the script to not restore in certain conditions.

Interesting observation about the potential consequences of this. What would be ideal is the following. If these settings could be stored on an external USB drive, and the rootfs could potentially look there first before restoring settings from the local rootfs... In fact, a future pipe dream could take this to an even lower level with the bootloader--perhaps a whole rootfs, etc. could be loaded from an external device if one is found, and then just boot normal from the onboard flash if not. Probably not many folks would be interested in something like this, and if one's flash chip is more robust, there is probably no need for it (except that it could potentially speed up a testing process). But the point is that it could potentially be used in a fashion to implement run profiles if there were ever a need/desire for that.

 

[HELLO_wORLD]

I realized that the problem might have another origin...

The symptoms we encounter are similar to the reset button being triggered.
What exactly does the reset button?

For what I understand, it erases the nvram (MTD11) and its data is replaced with default values (are they actually written in nvram or is the system using defaults when nvram config is missing?)
Is it possible that the problem is somehow the reset process being triggered? Overheating component? Some hardware access triggering it?
The very first thing would be to actually test the NAND of a defective router and check that some regions of it are worn out. I cannot do anything with my defective router as it is being sent back to Netgear (I cant’t keep it, but I can keep extra antennas and AC adapter).

 

[HELLO_wORLD]

@verbage : do you know if the factory reset procedure (reset button) is working with openwrt firmwares as well?

 

[verbage]

Is it possible that the problem is somehow the reset process being triggered? Overheating component? Some hardware access triggering it?

Interesting thought! So the router would get into some type of perpertual reset mode, which if running official Netgear/Voxel firmware would trigger the erasure of the mtd11 partition. This brings up an interesting thought--what does the reset button do under OpenWRT, for example, since there is no mtd11 partition? Of course, I have not tried that yet because this whole point of this thread is focused on trying to save settings or the lack of that ability!!! I can look into this later, and maybe even test it--can't do it now for fear of a family revolt.

Whatever the case, your point is that this could be due to a faulty component that perpetually triggers the erasure of mtd11. This is another great interpretation that could explain the observations! Indeed, it would imply that the Macronix flash chip is not "worn out" or defective in the particular segment that stores mtd11--it just appears that way because the reset process is being triggered perpetually.

To test if the flash chip is fully functional or worn out/damaged in some region should be simple for Netgear engineering staff--just erase the whole chip, write something to it, and then read it back for comparison without doing a reboot/recycle in between. Indeed, I believe we could also do it at this level, too--do the same process, but only for mtd11. But one would have to be sure it is implemented in reality ("nvram commit"???) vs. just in memory. Actually, since it functions as a block device, couldn't one just raw write/read the mtd11 partition with dd from a shell? Maybe an "nvram commit" would still be needed to finalize the operation and make it actually happen?

 

[verbage]

@verbage : do you know if the factory reset procedure (reset button) is working with openwrt firmwares as well?

A-ha, I was thinking about this, and had a response already started, but just pulled the trigger on it after returning here. I will investigate the reset button under OpenWRT this evening so as not to disturb the peace right now!

 

[HELLO_wORLD]

Yes, Family Peace comes first.

About testing MTD11, it can be tested, but preferably on a spare router. On a unit with the problem, formatting MTD11, then write something on it, then read and compare. I am not sure the router would be functional after that hence the need of a spare one and not a in service one.

The factory resets happen mostly while rebooting (interruption of power erasing the memory having config and failure to load from MTD11).
It also sometimes happens while restoring from web interface (I believe it does some kind of soft reboot for some settings to take effect, like change of SSID), and there too, the memory having config is unable to restore.
When the router is on, it is ok because the memory keeps its config (is it cached in the ram? That would explains a lot). Nvram commit I believe is storing ram config to nvram config.
Can someone confirm that?
The init.d script works because I believe nvram restore is writing the backup in nvram as well as ram, and defective routers are only working with ram.

A-ha, I was thinking about this, and had a response already started, but just pulled the trigger on it after returning here. I will investigate the reset button under OpenWRT this evening so as not to disturb the peace right now!

 

[kokishin]

Perhaps I missed this in the thread (or I'm stupid).

Is there a theory as to why a previous saved off cfg file does not restore the 7800 to the settings in the cfg file?

Presumably, something is reinitializing the nvram to the factory default settings during a reboot (shouldn't) , paper clip reset (should), or power cycle (shouldn't).

Given the above is happening, why won't the 7800 allow the user to restore the nvram with the previously saved cfg file using the Restore button?

The 7800 does allow the user to manually enter all the various parameters using the gui (pita).

Is it because the manually entered parameters are stored in dram before being unsuccessfully written to nvram?

The Restore of the saved cfg file doesn't load into dram before saving to nvram? Therefore it's always unsuccessful?

 

[microchip]

Perhaps I missed this in the thread (or I'm stupid).

Is there a theory as to why a previous saved off cfg file does not restore the 7800 to the settings in the cfg file?

Presumably, something is reinitializing the nvram to the factory default settings during a reboot (shouldn't) , paper clip reset (should), or power cycle (shouldn't).

Given the above is happening, why won't the 7800 allow the user to restore the nvram with the previously saved cfg file using the Restore button?

The 7800 does allow the user to manually enter all the various parameters using the gui (pita).

Is it because the manually entered parameters are stored in dram before being unsuccessfully written to nvram?

The Restore of the saved cfg file doesn't load into dram before saving to nvram? Therefore it's always unsuccessful?

Because when you upload a Settings file, the router applies it and reboots. So when it reboots, the NVRAM is cleared again in these faulty units and thus your settings are gone as well. It's a circle

 

[kokishin]

Because when you upload a Settings file, the router applies it and reboots. So when it reboots, the NVRAM is cleared again in these faulty units and thus your settings are gone as well. It's a circle

Thanks. Makes sense. Vicious cycle.

So when you enter the parameters manually, the router saves them but never reboots?

If so, would it be possible for @Voxel to modify the the Restore button function to not reboot the 7800 (presuming it would operate correctly)?

 

[Voxel]

If so, would it be possible for @Voxel to modify the the Restore button function to not reboot the 7800 (presuming it would operate correctly)?

I'll check. What could be done.


P.S.
Guys, I am really sorry. This thread is important. But I am totally overloaded. You know... This isolation. E.g. my parents need my daily help. Tp help with ordering food, to help with order by Internet (how it is possible to pay by credit card in Internet - they do not understand). Kids: remote school conferencing. Zoom, Skype. Viber, Whatsapp, Team Viewer, RDP, ssh, etc. etc. etc...

Voxel.