I am now convinced there is a very serious bug in v2.7.3.22 that is bashing nvram. You can see my issues in previous posts but here is the clean version of the test.
Step 1 - factory reset and firmware load router and 3 satellites. Everything at factor level with V2.7.3.22
Step 2 - bring up the router, let it stabilize, add my static DHCPs, then bring up the satellites one at a time with time between them for each to stabilize
Step 3 - I have a running config. Take an nvram dump via WebUI. Decode it and see that it is good.
Step 4 - wait 6 hours (10pm local time) and take another nvram dump via WebUI and verity that it is still good
Step 5 - wake up the next moring. Systems seems to be running fine. Take another nvram dump via WebUI and this time the verify shows non-ASCII junk towards the end of the file. The file can also not be used to reload via WebUI on any firmware version.
This bug may be out there and just not seen. The system seems to be running and unless a person is checking nvram, they won't know it. Garbage is nvram is eventually going to corrupt the system but that may take time and, by that time, there may be no way to even guess the root issue. Garbage nvram yield unpredicatable results.
I would LIKE to backup to a previous firmware version but last time I tried that the forced auto-upgrade got me right back into this situation the next night. I thought this was an auto-update bug but now believe this is a base V2.7.3.22 bug because the above scenario does not involve any auto-update.
In short, I have no way to bring up an Orbi configuration of any flavor that will stay good for more than 24 hours!! This stuff has taken countless hours since last Saturday morning. Get my frustation!! ...
I need a way to backup to a previous firmware version, get a running system, and stay there until Netgear can fix the issue with V2.7.3.22, That has to be possible.
Again, get my frustration?!!!! ..... I am still trying to be productive, however ....
Scott
