[R7800] Will no longer save settings after reboot.

[HELLO_wORLD]

As far as I know, it is permanent.
It can intermittently reboot without loosing data, but then it happens again, and probably get worse over time.

Just a quick update on my R7800...it is one of the older batches purchased on Amazon Nov 26, 2018. I did flash and am running the latest Voxels FW and Kamojs add-on (5.0). Things have been stable for a couple of weeks. I did end up getting a laptop cooler, which according to Kamojs add-on dropped my Router's CPU temp by 10 degrees celsius. I never re-enabled the Trafic Monitor or plugged the external USB drive back in (still need to figure out how to use it without ReadyShare).

I do plan on trying the latest beta Kamoj add-on when it is available, so I can at least give you some data on which flash chip my router has.

As I am one of the folks whose router is out of Warranty, thanks for creating the scripts/methods to restore settings early on in boot. If I confirm that my NVRAM is indeed bad, I will be working on implementing that.

Last a quick question, for those of you that see the issue, is it intermittent, or once it happens it stays bad?

 

[Redbot]

kamoj didn't need it (he needs an R9000 if anyone has one), and I don't have the patience of some of you, so I put mine eBay for parts/not working. Thank you everyone for the help and ideas, hopefully whoever gets it next will put it to use.

 

[LSM]

kamoj didn't need it (he needs an R9000 if anyone has one), and I don't have the patience of some of you, so I put mine eBay for parts/not working. Thank you everyone for the help and ideas, hopefully whoever gets it next will put it to use.

As a newcomer I've read this discussion with great interest. I bought an openbox R7800 about 4 months ago and had a similar sort of adventure. As a dd-wrt user I was hoping to get better OpenVPN performance with it. Basic functioning worked fine with the stock firmware but it appeared crippled compared to dd-wrt so I tried flashing it. Wouldn't work or even boot. I tried various stock versions of the firmware. No problem. Then I tried Voxel no problem. Then, I tried OpenWRT. It worked too! However, no matter what I did (and I did everything repeatedly) dd-wrt would not flash successfully while stock, Voxel, and OpenWRT would. I used the R7800 as an AP with Kong's version of OpenWRT without any problems, and with lots of setting changes, for several months. It is a newer model made in Thailand on 2019/07/06 so it has the newer flash chip.

I also discovered that it appears stock and Voxel use the same formatting while dd-wrt and OpenWRT are both different. Apparently during the flashing process stock firware (and Voxel) check the various partitions and, if it finds bad blocks in the nvram, then it installs the firmware so as to avoid those blocks (This may not be exactly technically correct, but I hope it is clear what I mean). dd-wrt does not appear to have that code; hence my experience. OpenWRT apparently used the same or similar code to resolve the bad block problem. I trust that this may add something useful to this discussion.

I am back to the latest Voxel firmware as I discovered the Kamoj add-on which makes this updated stock firmware a very interesting option. I'm still working through the VPN setup and such so I haven't declared victory yet but it looks very promising. My Linksys EA8500 is still my main gateway but I'm hoping to transition the R7800 to my provider (PureVPN), which is, of course, another adventure. At least I can try to get the R7800 fully functional without disturbing the EA8500, thereby preventing the otherwise inevitable cries thoughout the house "Is the internet down?"

LSM

 

[kamoj]

I looked at PureVPN once long time ago.
Then you could download their zip-file with the configurations.
https://support.purevpn.com/openvpn-files
Select Linux, Recommended OpenVPN files.
https://s3-us-west-1.amazonaws.com/heartbleed/windows/New+OVPN+Files.zip

Unzip this file to an USB device into a directory named openvpn-client
(Only the UDP-directory with its files, and no sub-directories in the USB openvpn-client dir.)
Then insert this USB device into the router and all configs are copied to the correct directory
in the router! (Thank you @Voxel !)
After that you can easy change between these configurations through the add-on.
You can edit the files from within it, and as well set your ID and Password.
Good Luck!

As a newcomer I've read this discussion with great interest. I bought an openbox R7800 about 4 months ago and had a similar sort of adventure. As a dd-wrt user I was hoping to get better OpenVPN performance with it. Basic functioning worked fine with the stock firmware but it appeared crippled compared to dd-wrt so I tried flashing it. Wouldn't work or even boot. I tried various stock versions of the firmware. No problem. Then I tried Voxel no problem. Then, I tried OpenWRT. It worked too! However, no matter what I did (and I did everything repeatedly) dd-wrt would not flash successfully while stock, Voxel, and OpenWRT would. I used the R7800 as an AP with Kong's version of OpenWRT without any problems, and with lots of setting changes, for several months. It is a newer model made in Thailand on 2019/07/06 so it has the newer flash chip.

I also discovered that it appears stock and Voxel use the same formatting while dd-wrt and OpenWRT are both different. Apparently during the flashing process stock firware (and Voxel) check the various partitions and, if it finds bad blocks in the nvram, then it installs the firmware so as to avoid those blocks (This may not be exactly technically correct, but I hope it is clear what I mean). dd-wrt does not appear to have that code; hence my experience. OpenWRT apparently used the same or similar code to resolve the bad block problem. I trust that this may add something useful to this discussion.

I am back to the latest Voxel firmware as I discovered the Kamoj add-on which makes this updated stock firmware a very interesting option. I'm still working through the VPN setup and such so I haven't declared victory yet but it looks very promising. My Linksys EA8500 is still my main gateway but I'm hoping to transition the R7800 to my provider (PureVPN), which is, of course, another adventure. At least I can try to get the R7800 fully functional without disturbing the EA8500, thereby preventing the otherwise inevitable cries thoughout the house "Is the internet down?"

LSM

 

[Alex Tzonkov]

Is there any know correlation to this issue with enabling/using ReadyShare? I know there was mentions of Traffic meter doing lots of writes to NVRAM, is the same true of the ReadyShare feature?

Since I can't seem to get NFS enabled, I am considering using the ReadyShare option, I know @Voxel says SMB is much faster with his FW, than stock. My main concern was the NVRAM overuse.

 

[microchip]

Is there any know correlation to this issue with enabling/using ReadyShare? I know there was mentions of Traffic meter doing lots of writes to NVRAM, is the same true of the ReadyShare feature?

Since I can't seem to get NFS enabled, I am considering using the ReadyShare option, I know @Voxel says SMB is much faster with his FW, than stock. My main concern was the NVRAM overuse.

The NVRAM is only a small, reserved part of the Flash chip where only configuration settings are stored and nothing else. ReadyShare and Traffic Meter write to other parts of the Flash chip

 

[HELLO_wORLD]

True, traffic meter even has its own space on the Flash chip (NAND).
However, NAND write operations (particularly recurrent and frequent ones) are to avoid as much as possible.
The NVRAM data loss (subject of this topic) is revealing the NAND problem. In my case, I am sure traffic meter was responsible somehow (and I do remember that when NAND started to show problems, the traffic reported was always zero). So @Alex Tzonkov is right to worry about something writing or not in NAND, as when the NAND turns bad, the NVRAM is affected.

Maybe that tells us something about the problem: it might not be about some specific sectors on NAND wearing off and not working but something affecting the entire R/W access (either the NAND itself or some components essential to its function). More tests with a defective router would help (testing the NAND, etc...).

The NVRAM is only a small, reserved part of the Flash chip where only configuration settings are stored and nothing else. ReadyShare and Traffic Meter write to other parts of the Flash chip

 

[Alex Tzonkov]

So is there a way to get access to the attached USB drive without ReadyShare? Or is there a way to minimize the ReadyShare usage of NAND? Relative to Traffic Monitor how bad is ReadyShare what specifically does it write to NAND and how often? I was under the impression that NAND access goes through some wear-leveling algorithm to prevent prematurely wearing it out. If NAND is indeed wearing out, wouldn't the FW be able to read some internal registers that would indicate too many bad blocks?

 

[HELLO_wORLD]

I use ReadyShare only at the minimum settings:

• ReadyShare->Basic Settings->Basic
• ReadyShare->Advanced Settings->Network Neighborhood/MacShare (only)
• for Available Network Folders, I added my USB.
• ReadyShare->Media Server->all Off

And in the nvram:

• log_readyshare=0
• readycloud_enable=0

I don’t think it is using NAND with these settings.
The sole purpose of this for me is SMB access.

So is there a way to get access to the attached USB drive without ReadyShare? Or is there a way to minimize the ReadyShare usage of NAND? Relative to Traffic Monitor how bad is ReadyShare what specifically does it write to NAND and how often? I was under the impression that NAND access goes through some wear-leveling algorithm to prevent prematurely wearing it out. If NAND is indeed wearing out, wouldn't the FW be able to read some internal registers that would indicate too many bad blocks?

 

[AlexTee]

Hi everyone. I came across this thread and realized, I can be in this risk group potentially, since my router is manufactured at around 07.2019, but I got it only a month ago brand new. I'm currently using pure stock firmware, and actually, it is still working fine, however, just to be on safe side, I nanddumped the critical partitions, and also tested the NVRAM, which showed 1 bad sector already present.

Now, to get better understating of what's going on under the hood I would like to ask you few questions regarding how things work on stock firmware. Would be rather thankful, if you share some of your knowledge in replies to my questions below:

1. When the OS boots up, it executes the S* scripts under /etc/rc.d, and as far as I can see, the S10boot is the biggest script out there, which configures the wireless and other stuff. I can also spot the /bin/config conditionally writing wireless default parameters to NVRAM, and I can also see some traces of /etc/config/*, which is essentially the UCI directory, speaking OpenWrt terminology. However, I don't have the whole picture of how the interaction with NVRAM happens. Which processes use them? Is it always accessed via /bin/config or some separate processes and the kernel itself can read/write to it directly? Does the GUI also use it somehow?
2. What is the reason of using NVRAM and UCI simultaneously? As per OpenWrt, they ceased using NVRAM partitions long ago, and entirely switched over to UCI, but this Netgear stock firmware still uses both, from what I see. For example, it keeps the wireless settings both in UCI and NVRAM. No idea why...
3. Is there any possibility to check the installed Flash model, without disassembling the unit and connecting to the Serial header to get Uboot output?

BTW, JFYI, I found some lines, which indicate that changes, maybe even significant ones, were introduced to motherboard after 07/07/2018 (something tells me, this is the day they swapped the original flash for the new vendor supplies). Not sure, if this info might be of any use, just sharing it:

#get Production time to /tmp/protime
        pro_time1=`/sbin/artmtd -r protime|grep Usage`
        pro_time2=`/sbin/artmtd -r protime|cut -d ":" -f 2`
        pro_oldtime=20180717
        if [ "x$pro_time1" != "xUsage" ] && [ $pro_time2 -gt $pro_oldtime ]; the
                /bin/config set new_sold_board=1
        fi

Thanks!
Alex

 

[kamoj]

Welcome and enjoy this community!
https://www.snbforums.com/threads/r...ettings-after-reboot.62773/page-7#post-569160
https://www.snbforums.com/threads/r...ettings-after-reboot.62773/page-7#post-569826

 

[AlexTee]

Welcome and enjoy this community!
https://www.snbforums.com/threads/r...ettings-after-reboot.62773/page-7#post-569160
https://www.snbforums.com/threads/r...ettings-after-reboot.62773/page-7#post-569826

Hi @kamoj, thanks for welcoming!
Somehow missed the first post I was confident, the kernel ring buffer size is not enough to keep the early lines! I was wrong) So, just collected the logs, and it appears to be MX30UF1G18AC - Macronix.
The second post, yes, I read it. Hope, I can also get some comments over my questions.

Cheers!

 

[kamoj]

Very good to have you among us others.
We need some "fresh blood"!

So, I don't understand.
I thought UCI was some old thing relating to the old technique JFFS2.
The R7800 don't use that.
So can you explain the UCI thing, please.

To access the "NVRAM" you can use /bin/config or /bin/nvram.
I don't now the difference - if any - between them.

The Macronix chips are suspected to be "not so good" by some people.

Did you use "nandtest -M" to test the nvram MTD partition, or how did you do it?

Do you understand why the nvram area i 3 times bigger than the allocated MTD?

 

[kamoj]

I have modified the code and tested it.
I added a confirmation after restore to reboot or not.
Is this of interest to add to the kamoj add-on, or should I just show the the code change?
Do we want the possibility to decide reboot or not even for the R9000?
PS
I don't know but I presume that the cgi-bin doing all restore already has done "nvram commit". I can not change that.

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)?

 

[AlexTee]

Very good to have you among us others.
We need some "fresh blood"!

So, I don't understand.
I thought UCI was some old thing relating to the old technique JFFS2.
The R7800 don't use that.
So can you explain the UCI thing, please.

To access the "NVRAM" you can use /bin/config or /bin/nvram.
I don't now the difference - if any - between them.

The Macronix chips are suspected to be "not so good" by some people.

Did you use "nandtest -M" to test the nvram MTD partition, or how did you do it?

Do you understand why the nvram area i 3 times bigger than the allocated MTD?

OpenWrt article describes UCI in detail. And R7800 stock firmware is definitely using it to some extent: uci show lists all the configs, found in /etc/config/*
The advantage of UCI is that you don't need a small dedicated partition for settings, as is the case with NVRAM, as a result, using a common big partition for UCI configs significantly reduces the wear level, as the data is now evenly distributed across the vast area of volume (thanks to ubifs' LEB to PEB mapping), instead of frequently hitting same cells all the time in NVRAM because of its small size (about 1MB).

No, I didn't really tested it (read at dd-wrt forum, that someone killed his flash with testing), just dumped it, and read the report:

root@R7800:/# nanddump --file /root/mtd11 /dev/mtd11
ECC failed: 0
ECC corrected: 0
Number of bad blocks: 1
Number of bbt blocks: 0
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x00120000...

Regarding the size, frankly speaking, can't comment on this. How did you figure out that?

 

[HELLO_wORLD]

Welcome @AlexTee

Very interesting this UCI.

@kamoj /bin/config is an alias to /bin/nvram

I think we can easily make this router 100% UCI and not use NVRAM at all...
For that, we simply need to hijack /bin/nvram to get and set the values with UCI in a section named nvram for example.

BUT: how are UCI settings surviving a firmware update?
It seems that /etc/config is on the root fs and therefore would be wiped out at any firmware update. NVRAM survives that. Any idea on that ? How is OpenWrt dealing with that?

 

[HELLO_wORLD]

Ok, according to UCI doc from OpenWrt, and some readings, uci settings would not survive a firmware flash.

This is not necessarily a big deal, but some extra steps would have to be made before and after flashing a firmware update to backup/restore settings.

Here is an idea on how a nvram hack could work:
First, a file named nvram would need to be created in /etc/config/
A call to nvram set setting=value would call behind
uci set nvram.$setting=$(echo $value | base64)

And a call to nvram get $setting would call behind
uci get nvram.$setting | base64 -d

Calling nvram commit would call behind
uci commit nvram

etc...

base64 is to avoid spaces problems as some nvram settings values have spaces. It might slow a bit any call to nvram, so there is space there for improvement.

Well, that is a quick thinking, it probably could be improved, but there is a way to get rid of nvram or at least nvram partition.

 

[spiderjuka]

Hello,

I have one question regarding to full backup of my R7800 (Voxel ROM).
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]

I just added some more flash info for next add-on beta release. Example of output:

FLASH TYPE NAND:
mtd0 : qcadata    nand   worn bad:0  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:0  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:0  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:36  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

 

[AlexTee]

Does anybody know, what's the purpose of NOR flash (mtd13)? Maybe to keep the NAND erase counters?