What's new

[R7800] Will no longer save settings after reboot.

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

@verbageWell, I may be wrong, but there's no v2 or v3 revision of the R7800 like there is for some models. I know this because if you go to the support site of NETGEAR, usually if there are revisions, the site asks you to select it (v1, v2, v3, etc). There is no such thing for the R7800 and a few other models. Why they didn't stuck with only one brand of NAND chips is still a mystery for me

Thanks for confirming that there are no major revisions, @microchip! Would this preclude more subtle revisions, for example, a simple rework of the power circuitry that nominally does not change anything functional about the router so that the same firmware will work for any and all subtle revisions? Again, this is complete and utter speculation on my part, but something like simplifying the power circuitry would not necessarily result in a large revision like v1, v2, v3. In fact, it might not even rise to the level of a sub-revision like v1a, v1b, v1c, etc. (if those were even to exist). Such a change might only be visible by direct observation of the circuit board--like either a direct observation of different circuitry, or a version or sub-revision number in silkscreening.

As a non-expert, I have not done anything to explore the immutable MTD partitions on the R7800 (i.e. mtd0: through mtd4: with the calibration data, the factory default SSID and password, etc.), But maybe somebody familiar with that low-level of hardware would know about a sub-revision variable or similar stored somewhere in those partitions? Maybe this would actually be available in dmesg logs, too? Again, this is all just complete and utter speculation on my part--I am just thinking about how more data could be collected in the easiest way possible.
 
I think if the changes are very minor, like using another brand of NAND chips, and no other modifications are made to the circuits layout, NETGEAR won't lable it as a new version/revision
 
I think if the changes are very minor, like using another brand of NAND chips, and no other modifications are made to the circuits layout, NETGEAR won't lable it as a new version/revision
If they're anything like most other manufacturers then they'll have a NG part number for the chip and will use parts from different suppliers that meet their spec. So as far as NG are concerned there is no change.
 
Perhaps @kamoj knows, I was wondering with Traffic Meter enabled, if there are a huge number of write operations to the nvram?

That may affect the useful life of the nvram especially if a particular brand or lot code is not living up to spec.

How many of us have had Traffic Meter enabled for a long period of time that are being affected with loss of settings on reboot?

Another question, is there any task besides TM that may write to the nvram excessively?
 
Last edited:
It is not very long after I started to use TM than the problem started.
TM is definitely writing to NAND.

Perhaps @kamoj knows, I was wondering with Traffic Meter enabled, if there are a huge number of write operations to the nvram?

That may affect the useful life of the nvram especially if a particular brand or lot code is not living up to spec.

How many of us have had Traffic Meter enabled for a long period of time that are being affected with loss of settings on reboot?

Another question, is there any task besides TM that may write to the nvram excessively?
 
I have been mulling over the possible suggested interpretations to explain the observations--either a less robust batch of Macronix-brand NAND flash chips that made it into production, or perhaps a subtle change in power circuitry that would not have been enough to be classified as a revision nor even sub-revision, but would have left the NAND flash distinctly more susceptible to power fluctuations. Since this affects multiple router models, wouldn't the simplest explanation be the former, i.e. that a less robust batch of Macronix-brand NAND flash chips made it into production, and was used for various router models?
 
I have been mulling over the possible suggested interpretations to explain the observations--either a less robust batch of Macronix-brand NAND flash chips that made it into production, or perhaps a subtle change in power circuitry that would not have been enough to be classified as a revision nor even sub-revision, but would have left the NAND flash distinctly more susceptible to power fluctuations. Since this affects multiple router models, wouldn't the simplest explanation be the former, i.e. that a less robust batch of Macronix-brand NAND flash chips made it into production, and was used for various router models?
Personally I'd take a punt on the NAND being at fault but another option the may not be considered a change but could have a major effect would be the A/C adapter.....
 
WARNING: These commands will erase all your settings and should not be tried out if you are under warranty.

To make a real "Factory reset" issue these commands:

For R7800:
Code:
nvram default
nvram commit
mtd erase netgear
reboot

For the R9000 the mtd command does not exist so you should try these commands instead:
Code:
nvram default
nvram commit
ngmtd="$(awk -F: '/"netgear"$/ {print $1}' /proc/mtd | grep mtd)"
[ -n "$ngmtd" ] && flash_erase /dev/"$ngmtd" 0 0
reboot
@kamoj I did find following code segment in /etc/preinstall for flashing
ubi0: overlay_volume (R9000), not just use flash_erase command.

if [ "x`grep overlay_volume /proc/mtd`" = "x" -a "x`grep netgear /proc/mtd`" != "x" ]; then
ubinize -m 2048 -p 128KiB -o /tmp/ubi.image /etc/netgear.cfg
mtdn=`grep netgear /proc/mtd | awk -F ':' '{print $1}' | awk -F 'd' '{print $2}'`
ubidetach /dev/ubi_ctrl -m $mtdn
flash_erase /dev/mtd$mtdn 0 0
nandwrite -p /dev/mtd$mtdn /tmp/ubi.image
ubiattach /dev/ubi_ctrl -m $mtdn
if [ "x`grep overlay_volume /proc/mtd`" = "x" ]; then
echo "Error: attach overlay_volume mtd device fail!"
fi
fi
 
but another option the may not be considered a change but could have a major effect would be the A/C adapter.....

Interesting possibility--the A/C adapter for my current R7800 is indeed different than the one that came with my original R7800. So as I understand your suggestion, another potential interpretation is that--instead of a subtle change in the power circuitry--a change in the A/C adapter might have left the system more susceptible to power fluctuations. In fact, I can easily imagine that A/C adapters might be interchangeable between systems, i.e. different models. So maybe Netgear swapped suppliers for the A/C adapter, and unknowingly/unintentionally ended up making a whole suite of their routers more susceptible to power fluctuations? The result would (could?) be electronic damage to only a segment of the NAND flash (i.e. the mtd11 partition where configuration data is stored), and that would be what is actually causing the problem--and the only way to fix it would be via an RMA swap. But at least it could be traced back to a changed A/C adapter vs. something else. Very interesting possibility!!!

More data is needed--are the only systems affected still those with Macronix chips, or something else???
 
If it is related to the heat. Why is the "losing memory" occurred pretty much around the same time? Suddenly that weekend, everyone experienced the lost. If i remember, my router was on at that time. It lost its configuration and not bc of the reboot.
 
Last edited:
If it is related to the heat. Why is the "losing memory" occurred pretty much around the same time? Suddenly that weekend, everyone experienced the lost. If i remember, my router was on at that time. It lost its configuration and not bc of the reboot.

Hi @tommytqt, yeah, the heat issue has sort of fallen by the wayside over the last few days as discussion has shifted direction a bit, but like @HELLO_wORLD observed several pages of comments back, it may be that heat exacerbates the issue, but is not necessarily the main cause. For example, it would explain why some routers that are afflicted with the issue out-of-blue have apparently been able to resume normality--at least temporarily--after sitting around unplugged for a few days. At least that is what I observed with my original R7800 though @HELLO_wORLD's R7800 had a temporary revival without being unplugged and cooling down. Another great observation that he made was that there seem to be a lot of cases where this issue is triggered right after a flashing operation because presumably, the flashing operation causes the chip to heat up...

Yeah, it is odd that many people started talking about it at the same time. But to be fair, it was also a moment when many folks were stuck working at home due to COVID-19, with an Internet connection critical for themselves and their families. So maybe folks were supersensitized to issues.

It would definitely be helpful for someone to do a meta-analysis of all the data that is out there. As I mentioned, I have flagged like 30+ threads on the Netgear forum in which this issue is mentioned, but I have simply not had time to read through them yet.
 
Not to mention that more people home means more devices connected, more traffic, for longer periods of time than usual, therefore likely more heat.

Quite frankly, we don’t know for sure what is the problem, and only analysis of data will show a pattern.

We know that heat is not good for electronics, and it is likely to contribute to failures.

Hi @tommytqt, yeah, the heat issue has sort of fallen by the wayside over the last few days as discussion has shifted direction a bit, but like @HELLO_wORLD observed several pages of comments back, it may be that heat exacerbates the issue, but is not necessarily the main cause. For example, it would explain why some routers that are afflicted with the issue out-of-blue have apparently been able to resume normality--at least temporarily--after sitting around unplugged for a few days. At least that is what I observed with my original R7800 though @HELLO_wORLD's R7800 had a temporary revival without being unplugged and cooling down. Another great observation that he made was that there seem to be a lot of cases where this issue is triggered right after a flashing operation because presumably, the flashing operation causes the chip to heat up...

Yeah, it is odd that many people started talking about it at the same time. But to be fair, it was also a moment when many folks were stuck working at home due to COVID-19, with an Internet connection critical for themselves and their families. So maybe folks were supersensitized to issues.

It would definitely be helpful for someone to do a meta-analysis of all the data that is out there. As I mentioned, I have flagged like 30+ threads on the Netgear forum in which this issue is mentioned, but I have simply not had time to read through them yet.
 
Time for a laptop fan cooler under your router. o_O
 
Time for a laptop fan cooler under your router. o_O

Fair enough--this is probably a wise suggestion that may help avoid future problems. But let's not lose perspective here--there are many R7800s out there that have been running for years--through many flash cycles and undoubtedly a number a power aberrations, too--and they are still running like champions! And they have done this without any type of special cooling solution whatsover!

But there is also a certain population of R7800 out there (and other Netgear routers, too) that are apparently super-susceptible to this "loss of settings on reboot or power cycle" issue, and they can develop the condition very quickly--like on the order of days to weeks to months. THIS IS NOT NORMAL.

If you have been running an R7800 for years, and you have not developed this problem, I am really happy for you--you will probably never develop it. And gosh, I sure wish I could swap mine for yours :)

As a consumer, you can imagine the problem is pretty frustrating. When I bought my R7800 in 2019, it was certainly not cutting edge. But even after being several years old, it had proved itself to be a workhorse given all the stellar reviews and good words about it. And that's why I decided to buy a $200 router instead of a $100 one. If I had known that only older generation R7800s were robust workhorses, and that newer ones were more likely to succumb to this issue, well, to be honest, I would not have bought the R7800. Not being able to preserve its settings over a reboot or power cycle is a pretty severe limitation as you can imagine... If there were a way to reload an old configuration file when this happens, that would go an absolutely massive way towards mitigating the issue. But that is the real double-whammy here--when this happens, you also lose the ability to restore a configuration backup file, and thus, you must redo your whole configuration by hand.

As I have said several times, there are 30+ threads over at the Netgear forums so this is not an issue of just a few people experiencing it. Unless there is a majorly dysfunctional management, engineering, and public relations team at Netgear, they for sure, know about this, too!!!

To put this in COVID-19 terms, if you have 1000 confirmed cases of infection, you probably have way many more undiagnosed cases, too! For some less technically inclined people who have run into the problem, I bet they just threw away their router, and bought a new one. And for folks whose warranty coverage has already expired, they probably expect they have almost no recourse, which is realistically the case. So my point is that there are probably lots of unreported cases out there. Indeed, it is for the latter group (the ones with expired warranties) that I am so intent on figuring this out. If their R7800 can return to semi-normal functionality by retaining settings through a reboot or power cycle, and this can be done by flashing a different firmware distribution, or perhaps a Voxel-based version with a special flash layout map, let's work towards that!

I hope that it is also abundantly clear that I love my R7800--that's why I bought it in 2019 even though it was starting to get long in tooth. I just wish it were the same robust workhorse that all of you guys with older generation R7800s have.
 
Last edited:
Agree. After all due diligence, which you are tasked to do and prove. Troubleshooting and resets and testing with stock vs 3rd party FW to confirm the issues at hand. Then it would be something to hand over to NG for review. It would have to be reviewed by NG.

Yes I've had my R7800 since 3/2017 and haven't not seen anything like this with it. Taken care of it and worked with it well including using Voxels FW. Only as of late have I dived farther into loading Entware and using Netdata which is a really nice feature. Factory resets are standard practice for me. I've avoided many problems with resets. Ya, many don't like resets. There is a good reason for them.

I don't really believe this is a heat issue unless on chip that seems to exhibit this issue maybe more susceptible to heat over a short period of time vs the one chip that doesn't seem to experience this issue at all and those routers are working under similar conditions with out any additional air cooling. Of course, I've always have run a fan cooler under my router since finding out from using a different Mfr router that there was a heat design issue there that effected operation. That was about ten years ago. Since then I have a fan running under any router I use as the main host router as standard practice. Just makes good sense for keeping the electronics running longer.

At any rate, if this is something you feel that is a problem with a chip, something to bring to NGs attention. I don't know if NG will stop producing the R7800, if or when they will. Seems like the R7800 is a work horse for NG and enjoyed by many NG users. I still recommend this router for gamers at least. Its still being sold my NG on there store if that says anything. So I presume the R7800 still has some good mfg life from my perspective. So something to collected all of your trouble shooting and fact checking data and pass along to NG. See if NG will review and many any changes while there is still life in the R7800.
 
Agree. After all due diligence, which you are tasked to do and prove. Troubleshooting and resets and testing with stock vs 3rd party FW to confirm the issues at hand. Then it would be something to hand over to NG for review. It would have to be reviewed by NG.

Yes I've had my R7800 since 3/2017 and haven't not seen anything like this with it. Taken care of it and worked with it well including using Voxels FW. Only as of late have I dived farther into loading Entware and using Netdata which is a really nice feature. Factory resets are standard practice for me. I've avoided many problems with resets. Ya, many don't like resets. There is a good reason for them.

I don't really believe this is a heat issue unless on chip that seems to exhibit this issue maybe more susceptible to heat over a short period of time vs the one chip that doesn't seem to experience this issue at all and those routers are working under similar conditions with out any additional air cooling. Of course, I've always have run a fan cooler under my router since finding out from using a different Mfr router that there was a heat design issue there that effected operation. That was about ten years ago. Since then I have a fan running under any router I use as the main host router as standard practice. Just makes good sense for keeping the electronics running longer.

At any rate, if this is something you feel that is a problem with a chip, something to bring to NGs attention. I don't know if NG will stop producing the R7800, if or when they will. Seems like the R7800 is a work horse for NG and enjoyed by many NG users. I still recommend this router for gamers at least. Its still being sold my NG on there store if that says anything. So I presume the R7800 still has some good mfg life from my perspective. So something to collected all of your trouble shooting and fact checking data and pass along to NG. See if NG will review and many any changes while there is still life in the R7800.

The R7800 will be supported for a long time. It came out in 2016 while the R7000 in 2013 and the latter still gets firmware updates. Both of these models are very popular. I don't think NG will stop unless it is not longer viable to support them, like way too old or some other reason. AC routers are still the norm at the moment and will take a few years until AX ones surpass them
 
Yep. There's still a R7000 at my work that I connect to. Runs great for wireless.
 
Seems like the R7800 is a work horse for NG and enjoyed by many NG users. I still recommend this router for gamers at least. Its still being sold my NG on there store if that says anything. So I presume the R7800 still has some good mfg life from my perspective. So something to collected all of your trouble shooting and fact checking data and pass along to NG.

I agree with you about the R7800 still being very functional and useful--as I mentioned, I still love my R7800! It is fantastic except for the fact that it loses its settings, which is a major headache. At the beginning, I had no option for mitigation--but now I do with OpenWRT. Whether OpenWRT's ability to retain its settings on a reboot or power cycle is due to a significantly different flash layout map versus the layout map used by official Netgear/Voxel firmware, we do not know at this point. But I am just happy that is does work for whatever reason!

Unfortunately, there is a whole batch of consumers out there who are not willing to load OpenWRT, and if they are past their warranty coverage, they essentially have no option--repeat, no option for a $200+ router, which is a shame.

If we are ever able to collect a significant amount of data, for sure, I would be willing to present the information to Netgear. But at this point, for example, less than a handful of forum participants have been able to contribute information about the manufacturer ID of the NAND flash chip in their routers. And we can't really go to Netgear with just five observations and make a compelling case. But I am optimistic--given that @kamoj's add-on spits out ever more information, it may soon be possible to collect this type of data more easily. And if we can get to a very strongly supported case, for sure, then it makes sense to bring it directly to the attention of Netgear.

But why not do it now? Again, there is no question that Netgear absolutely knows about the issue by this point... And so they have made a business decision that it is obviously in their best interests not to say anything, and potentially just run out the clock with warranty coverages. Whether one thinks this is a good idea or not completely depends on their perspective. It obviously stinks for consumers who have plunked down their money for this device. But from Netgear's perspective, they probably made a calculation that the PR and financial impact are more manageable by generally ignoring the issue than by doing a recall. This also gives one some food for thought--if it is less painful to not deal with the problem or ignore it, the problem must be pretty darn big!!!

As with my other ramblings, all of the above is complete speculation on my part :):):)
 
Yes it maybe worth at least making contact with NG and letting them know. Point to this thread and any others that have this problem. You can talk about and beat around the bush about it here in the forums however it's not going to make any changes or any progression. Its worth making contact with NG support and start something. I'm sure NG would like to know that there work horse router may have some problems for some of you. You don't know for sure that NG knows about this. So for your satisfaction and others, let them know. After than this it's in NG ball park.

Yes, maybe they are taking a lesser thought of well, it works up to a point. Would be costly to recall. Maybe they have made a change. Would be hard to collect data to find out what recent routers use and what has changed if anything. Alot goes into making changes, testing, legalities, approvals and mfr'g. Just can't change the chip and send it out the door.

I would at least make contact with NetGearGuy and have him review this and forward it on to NG were it needs to go.
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top