AGAIN - URGENT - Auto-update repeatable failure killing nvram!!!

[SLK-Purdue]

I now have a REPEATABLE failure from the auto-update to v2.7.3.22.

I completely reset my config (1 RBR50 and 3 RBS50) to v2.5.1.16 yesterday with full firmware reload and factory reset.  Last night the config auto-updated again to v2.7.3.22 and AGAIN my config parameters (nvram) are corrupted.   Dumping the config parameters via the WebUI produces a file that can not be reloaded wia the WebUI because of errors.   Decoding the cfg file shows non-ASCII junk in the file.   This is the same results as my last auto-upgrade last Saturday.

NETGEAR - PLEASE STOP THE AUTO-UPDATE!!   This is breaking my configuration.

[FURRYe38]

What happens if you factory reset the RBS and RBR with v22 loaded and setup from scratch then back a new back up config to file? 

[SLK-Purdue]

Factory reset is not a viable option for me at this time as I have a complex config with static DHCP and port forwarding that would be a complete pain to enter by hand. I do have some additional data, however. I have a repeatable scenarion 1. Firmware load and factory reset to v2.5.1.16 2. load parameters 3. come up with router only and go to update page on WebUI 4. v2.7.3.22 available 5. do update 6. nvram has junk THen Factory reset and firmware load v2.7.3.22 Come up and load old parameter file nvram OK and running difficult to absolutely confirm without telnet but look good Bottom line - something is not right doing auto-update with existing parameter file. Seems to support what others are saying too.

[SLK-Purdue]

Factory reset is not a viable option for me at this time as I have a complex config with static DHCP and port forwarding that would be a complete pain to enter by hand. I do have some additional data, however. I have a repeatable scenarion 1. Firmware load and factory reset to v2.5.1.16 2. load parameters 3. come up with router only and go to update page on WebUI 4. v2.7.3.22 available 5. do update 6. nvram has junk THen Factory reset and firmware load v2.7.3.22 Come up and load old parameter file nvram OK and running difficult to absolutely confirm without telnet but look good Bottom line - something is not right doing auto-update with existing parameter file. Seems to support what others are saying too.

[SLK-Purdue]

Sorry post is hard to read and interface is not showing linefeed between steps.  Hope you can decrypt.

Scott

[FURRYe38]

A reset and set up from scratch would be needed to verify if from new configuration is reproducing this issue or not. We've seen historical experiences and post where older config files no longer work with newer versions of FW. A reset and a clean setup from scratch is needed to avoid this. Espeically on major version updates vs minor version updates. 

Something to open a support ticket and let NG know about. 

Good Luck. 

[SLK-Purdue]

I am out of warranty so i can't open a support ticket.

[SLK-Purdue]

And one last dig - this is just an unacceptable behaviour by Netgear.   They can't just decide to do a auto-update on their schedule that then required a factory reset and full configuration reload on my part via the WebUI.   It wasn't a huge problem when I had telnet and could run scripts with static DHCPs and Port Forwarding set via "nvram set".   Now that option is gone too.

AGAIN - force auto-upgrade is this an unacceptable procedure and is now even worse since there is no reasonable way to reset parameters in bulk.  If NETGEAR doesn't listen here, how do we make this point?  I know someone mentioned a lawsuit but that just makes money for lawyers.  I would rather deal at a technical level and get things done.

Scott

[FURRYe38]

Understand man. Historically, this has been a problem and NG doesn't seem to want to change anything. And with the removal of of telnet, needs they want there Orbi system to work in a specific way and it's there way. NG removed telnet soon after Orbi AX was released. That didn't even get the disable SSID broadcast at all so Orbi AC is the only series that still has this feature. 

I recommned for users that are out of warranty, try Voxels FW for the 50 series Orbi: https://community.netgear.com/t5/Orbi/Voxels-FW-available-for-50-series-Orbi-only-available/td-p/183...

He seem to offer what most advanced users and users that want more control over orbi need, if users don't like how NG does stock FW. 

[mmz06]

Hi there,

Facing the same issue, I could restore telnet access using the updated version of telnet-enable2.py, enabling back Telnet using V2.7.3.22: https://github.com/bkerler/netgear_telnet

I could push all my existing custom configuration (upnpc, automation, etc.) from here.

Hope this will help you as well...