[R7800] Will no longer save settings after reboot.

[kamoj]

Micron M25P80 Serial Flash Embedded Memory.

 

[AlexTee]

Micron M25P80 Serial Flash Embedded Memory.

Yes, and what is it used for?

 

[kamoj]

No idea, and before I started this add-on I never knew about it's existance...
I dumped the MTD, and it was all 00:s...

 

[AlexTee]

Did you dump with nanddump or dd?
The correct tool, that works with NOR flash is flashcp from mtd-utils package, but it is missing on stock firmware.

 

[kamoj]

nanddump gives segmentation fault...
I tried dd with the zero result...

 

[spiderjuka]

Hello,

Does anybody know answer for my question?
Is it possible to save some partition with firmware, settings and all custom programms installed after ROM instalation?
If yes - for which partitions should I make an backup?
mtd6_rootfs and mtd7_netgear and mtd8_firmware or mtd11_config ???
In the system there are 20 different partitions.
Or is there any other way to make full backop of current system on R7800?

Thank you for your support.
Best Regards.

 

[kamoj]

settings are stored in mtd11 that is a nand mtd, so DO NOT use dd to backup, but instead:
(dd dumps will not be usable to restore from, since it's not NAND-aware.)
For all NAND-partions, use e.g:

nanddump --file /mnt/sda1/mtd11.nanddump /dev/mtd11

 

[spiderjuka]

Thank you.

Ok. But after that how can I restore it?

I am sorry if I ask too simple questions but it is difficult for me to find a person who can help me.

 

[kamoj]

Don't do it if you don't need to and don't know what you do.
Use the GUI backup and restore to start with, and only use nandwrite when you have the need:
https://forum.openwrt.org/t/dump-and-write-back-mtd/30180/2

#backup:
nanddump --file /mnt/sda1/mtd11.dmp /dev/mtd11
#and then to write it back:
flash_erase /dev/mtd11 0 0
nandwrite -p /dev/mtd11 /mnt/sda1/mtd11.dmp

Thank you.

Ok. But after that how can I restore it?

I am sorry if I ask too simple questions but it is difficult for me to find a person who can help me.

 

[AlexTee]

I think, I now understand, why Netgear and other manufactures continue using NVRAM partitions for keeping the essential settings. The answer is simple: to survive firmware upgrades, otherwise if all the settings are kept as uci configs, users will have to reconfigure or restore settings from backup every time they upgrade fw, which leads to broken user experience and customer dissatisfaction.

 

[HELLO_wORLD]

Yes, it is clear that it is a lot more user friendly to have settings persistant over firmware updates.
Technically, uci could persist updates if the config files (/etc/config) were saved on a separate partition.
The other solution is an easy backup/restore procedure around an update.

I think, I now understand, why Netgear and other manufactures continue using NVRAM partitions for keeping the essential settings. The answer is simple: to survive firmware upgrades, otherwise if all the settings are kept as uci configs, users will have to reconfigure or restore settings from backup every time they upgrade fw, which leads to broken user experience and customer dissatisfaction.

 

[spiderjuka]

Don't do it if you don't need to and don't know what you do.
Use the GUI backup and restore to start with, and only use nandwrite when you have the need:
https://forum.openwrt.org/t/dump-and-write-back-mtd/30180/2

#backup:
nanddump --file /mnt/sda1/mtd11.dmp /dev/mtd11
#and then to write it back:
flash_erase /dev/mtd11 0 0
nandwrite -p /dev/mtd11 /mnt/sda1/mtd11.dmp

Thank you very much for support.

Best Regards.

 

[LSM]

On April 15 I posted a message in this thread about a newer model r7800 made in Thailand on 2019/07/06 with the newer flash chip. Although it worked there were some problems. It is currently running Voxel 76.1SF+Kamoj 5.2b2-5. I also used information elsewhere in this forum to disable Netgear Analytics embedded in the firmware. Kamoj provided some advice on OpenVPN that was helpful in getting it running and I am working on getting it the VPN service tweeked to run faster.

I am getting openvpn client speeds of 55-70 Mbps down, ping 23-35 with my Linksys EA8500, but only about 25-35 Mpbs, ping of 39-48 with the r7800 using the same VPN provider and location. I was hoping for about 2x for the r7800 not 1/2 speed. I got just over 300 Mbps down, ping 35-40 with straight DHCP with my local internet provider (Rogers) with both units until I disabled the Netgear Analytics. Now with the r7800 I get about the same or slightly lower speeds with the VPN but only about 100 Mpbs down, ping about 60 for non-VPN service. As you can imagine this is getting even more confusing and frustrating.

However, I thought I would post the output from kamoj's new script that provides information on the flash chip that has been the focus of much discussion in this thread. As you can see there are 3 worn bad sections in the flash NAND from mtd0-mdtd12. This was an open-box item, did not appear to be used, and, given the manufacturing date, extensive use is unlikely There may be other interesting things in the output as well. Unfortunately, I don't have an earlier output of this script that would help to determine of the disabling of the Netgear Analytics changed anything.

FLASH TYPE NAND:
mtd0 : qcadata _ _nand _ worn bad:1 _factory bad:0 _bad allowed:t writable:t ecc errors:0 _ size: 13107200 bytes
mtd1 : APPSBL _ _ nand _ worn bad:0 _factory bad:0 _bad allowed:t writable:t ecc errors:0 _ size: _5242880 bytes
mtd2 : APPSBLENV _nand _ worn bad:0 _factory bad:0 _bad allowed:t writable:t ecc errors:0 _ size: _ 524288 bytes
mtd3 : ART _ _ _ _nand _ worn bad:0 _factory bad:0 _bad allowed:t writable:t ecc errors:0 _ size: _1310720 bytes
mtd4 : ART.bak _ _nand _ worn bad:0 _factory bad:0 _bad allowed:t writable:t ecc errors:0 _ size: _1310720 bytes
mtd5 : kernel _ _ nand _ worn bad:0 _factory bad:0 _bad allowed:t writable:t ecc errors:0 _ size: _2228224 bytes
mtd6 : rootfs _ _ nand _ worn bad:1 _factory bad:0 _bad allowed:t writable:t ecc errors:0 _ size: 31326208 bytes
mtd7 : netgear _ _nand _ worn bad:0 _factory bad:0 _bad allowed:t writable:t ecc errors:0 _ size: 71827456 bytes
mtd8 : firmware _ nand _ worn bad:1 _factory bad:0 _bad allowed:t writable:t ecc errors:0 _ size: 33554432 bytes
mtd9 : crashdump _nand _ worn bad:0 _factory bad:0 _bad allowed:t writable:t ecc errors:0 _ size: _ 524288 bytes
mtd10: language _ nand _ worn bad:0 _factory bad:0 _bad allowed:t writable:t ecc errors:0 _ size: _3670016 bytes
mtd11: config _ _ nand _ worn bad:0 _factory bad:0 _bad allowed:t writable:t ecc errors:0 _ size: _1179648 bytes
mtd12: pot _ _ _ _nand _ worn bad:0 _factory bad:0 _bad allowed:t writable:t ecc errors:0 _ size: _1179648 bytes

FLASH TYPE NOR:
mtd13: m25p80 _ _ nor _ _bad allowed:f writable:t size: _ _65536 bytes

FLASH TYPE UBI:
Device: ubi0 _ _ _type:ubi _ bad blocks:0 _Allowed bad blocks:5 _Max erase counter:4 _ size: _4190208 bytes
mtd14: cert _ _ _ _ _ _ _ _ ubi _Volume:0 State:OK _ size: _ 126976 bytes
mtd15: pot.bak _ _ _ _ _ _ _ubi _Volume:1 State:OK _ size: _ 380928 bytes
mtd16: traffic_meter _ _ _ _ubi _Volume:2 State:OK _ size: _1777664 bytes
mtd17: traffic_meter.bak _ _ubi _Volume:3 State:OK _ size: _1777664 bytes
mtd18: dongle _ _ _ _ _ _ _ ubi _Volume:4 State:OK _ size: _1777664 bytes
mtd19: overlay_volume _ _ _ ubi _Volume:5 State:OK _ size: 58408960 bytes

I am planning on doing a factory flash reset and then reinstalling the firmware and addons so I can see if this improves or changes anything. I trust this may add a bit to the helpful infromation and presented in this thread and may be of interest to some. I'll report back with the outcome of the resetting/reinstalling.


LSM

 

[ryanrudolf]

Hello everyone. Been lurking this thread for a while. Just wanted to share as additional data point.

Ive been using @Redbot 's r7800 for a while now. It also suffers the issue of not saving settings when router reboots. Luckily it works OK with OpenWRT. Im using hnyman's May05 master build and it works OK. NAND is also a Macronix.

 

[HELLO_wORLD]

On NG community forum, there are two very interesting posts confirming that the problem is linked with the flash microchip.

However, might not be the chip itself, but the soldering...

Here are the posts:

Re: R7800 Resetting to Default Config
HI,

I have moved on to a new router after this fiasco but I tried an experiment today and wanted to share it to anyone with one of these boat anchors (kinda light for that job so "paper weight" is probably more appropriate). I opened up my r8700, took off the shielding, found the chip and held some pressure on it while heating it with a butane torch ($1.00 from Menards). I plugged it all in and confiured it. I was able to re-boot several times and it retained the settings. I am going to put it in to service tonight. I'll update this thread one way or the other.

Jim


Message 69 of 71

And

Re: R7800 Resetting to Default Config
Good Evening,

It's been a week since I "torched" the flash memory chip on the underside of my r7800 and it has been rock solid. I have rebooted it several times and it holds my config (passwords, wifi names, reserved ip's). I have backed up and restored configs. Try it at your own risk, but I had nothing to lose.

Jim


Message 71 of 71

Original link: https://community.netgear.com/t5/Ni...to-default-configurations/m-p/1913254#M157881

 

[AlexTee]

On NG community forum, there are two very interesting posts confirming that the problem is linked with the flash microchip.

However, might not be the chip itself, but the soldering...

Here are the posts:


And


Original link: https://community.netgear.com/t5/Ni...to-default-configurations/m-p/1913254#M157881

If that's the case, then we still need some explanation on why it affects data retention of only a specific partition. Anyway, we need more evidence. A gas torch is the worst tool I can imagine of to heat-up a PCB. It is absolutely possible, that the cold contact is somewhere near the chip itself, and by using a torch he might've unintentionally refreshed the soldering of all the surrounding discrete SMD components, effectively eliminating the real root cause.

Anyone there with a hot air station and desire to confirm the hypothesis?

 

[Droidrat]

I made a little script called nvram-utils.
To install:

1. Connect to the router with ssh or telnet
2. Go to the directory you want to install the script (I recommend /opt/scripts):

   cd /opt/scripts

   If directory does not exist use:

   mkdir -p /opt/scripts; cd /opt/scripts

3. Copy and paste the following code:

   wget https://tinyurl.com/nvram-utils && chmod +x nvram-utils

Now the script is installed.

Usage:

• /opt/scripts/nvram-utils backup
  • To backup the current settings to be able to restore with the boot fix.
  • If you have an external drive labeled ‘optware’, it will save a copy to it with a timestamp in /mnt/optware/nvram_backups/ in binary and text formats.
• /opt/scripts/nvram-utils bootfix install
  • To install the boot fix (init.d and rc.d) to restore saved settings from backup at early boot stage.
  • THIS WILL PREVENT THE ABILITY TO DO A FACTORY RESET as the backup settings will always be restored. To prevent that, you need to access the root file system (telnet or ssh) and either:
    • remove /nvram_backup (rm /nvram_backup and confirm), or
    • uninstall the boot fix (see next command)
• /opt/scripts/nvram-utils bootfix uninstall
  • To uninstall the boot fix

That’s it. I threw that quickly without much testing. It is basic and to help people having the settings reset at reboot or restore from web GUI problem.

Thanks to @kamoj who helped with the boot fix.

After installing the most recent Voxel firmware and/or installing various Kamoj betas, I discovered that nvram-utils is no longer installed in my router. The only file in opt/scripts is "firewall-start-bwusage.sh".

Can you tell me what events necessitate reinstallation of the script?

 

[HELLO_wORLD]

Any firmware flash is removing the utility.
To reinstall, just follow install steps.

About the necessity to have the script installed or not:
The script is never necessary (except people encountering the problem with nvram not sticking after reboots), but it helps to do backups of settings and be more prepared if problems happen.

After installing the most recent Voxel firmware and/or installing various Kamoj betas, I discovered that nvram-utils is no longer installed in my router. The only file in opt/scripts is "firewall-start-bwusage.sh".

Can you tell me what events necessitate reinstallation of the script?

 

[Droidrat]

Any firmware flash is removing the utility.
To reinstall, just follow install steps.

About the necessity to have the script installed or not:
The script is never necessary (except people encountering the problem with nvram not sticking after reboots), but it helps to do backups of settings and be more prepared if problems happen.

Got it. Does a firmware flash also remove the backed up configuration data? At the moment, I'm using the utility simply to save my configuration settings. It is "safe hex." Fortunately, none of the recent (post 74.3SF) reboots necessitated by updated Voxel and Kamoj firmwares has resulted in any loss of my settings.

 

[HELLO_wORLD]

If you have a usb drive (or eSata) named optware, then your backups are saved in there as well (and are not deleted by firmware flashes).

If you don’t have such a drive, then the backup made on your router is lost after a new flash.

Then thing with defective chip is it sometimes works, sometimes does not. Seems that heat might be a factor, and intensive usage (like traffic-monitor).

So I hope your chip is fine, but if you have a newer model like me, I would do anything to prevent the problem to happen.

Maybe your problems with bandwidth monitoring are linked with chip or not.
I would recommend if you don’t have one to use a usb thumb drive and format it as mentioned in @Voxel ’s readme with the name ‘optware’ allowing the utility to save on the drive.

This would also allow you to automatically reinstall things after a firmware update (like the utility) with a little script.

Got it. Does a firmware flash also remove the backed up configuration data? At the moment, I'm using the utility simply to save my configuration settings. It is "safe hex." Fortunately, none of the recent (post 74.3SF) reboots necessitated by updated Voxel and Kamoj firmwares has resulted in any loss of my settings.