NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
Firmware Version 4.6.8.2 bricked my RBS750
I have an RBR750 and RBS750. Last week I noticed that none of my devices were connecting to my satellite. I checked the router's page and saw that the satellite was not on the network. I tried reboot...
I started going through the process for TFTP today, and had the RBS directly connected to my PC. I noticed the power LEDs weren't cycling in the way the TFTP guide suggests they would. Out of curiosity I checked for a web server at 192.168.1.1, no answer. I checked 192.168.1.250, which I found from another post that said .250 was the default IP for Satellites that couldn't connect. No answer. Then I tried 192.168.1.28, which is the IP that the RBS was last given via DNS from the RBR. It was responding there. Also, the status page now said that the RBS FW was v4.6.5.14, which I had attempted to flash the night before but didn't seem to boot successfully over the weekend (no answer on WiFi, would only connect as a device when hardwired, and could not report its status).
But today? Today it booted up as a functioning Satellite and connected to my RBR. It's now working as part of the mesh. I don't know what's different than yesterday when it didn't know its identity. My best guess is that the firmware downgrade actually worked but something was stuck in memory or some circuitry was behaving in a bad way. After being disconnected from power and ethernet for 12+ hours, something finally dissipated?
Anyway, working somehow, for now at least.
Another interesting piece of information: Over the weekend (both when on 4.6.8.2 and half-alive on 4.6.5.14) the RBS accepted the default login credentials of admin/password. But today it rejected those credentials and INSTEAD it accepted admin/<my personal password for the RBR>. Yeah, it went from "I only accept my default password" to "I only accept your customized password." It almost seems like 4.6.8.2 itself made the memory unreadable in a way that survives reboots but now after a night of rest the values are readable again. Weird.
I started going through the process for TFTP today, and had the RBS directly connected to my PC. I noticed the power LEDs weren't cycling in the way the TFTP guide suggests they would. Out of curiosity I checked for a web server at 192.168.1.1, no answer. I checked 192.168.1.250, which I found from another post that said .250 was the default IP for Satellites that couldn't connect. No answer. Then I tried 192.168.1.28, which is the IP that the RBS was last given via DNS from the RBR. It was responding there. Also, the status page now said that the RBS FW was v4.6.5.14, which I had attempted to flash the night before but didn't seem to boot successfully over the weekend (no answer on WiFi, would only connect as a device when hardwired, and could not report its status).
But today? Today it booted up as a functioning Satellite and connected to my RBR. It's now working as part of the mesh. I don't know what's different than yesterday when it didn't know its identity. My best guess is that the firmware downgrade actually worked but something was stuck in memory or some circuitry was behaving in a bad way. After being disconnected from power and ethernet for 12+ hours, something finally dissipated?
Anyway, working somehow, for now at least.
Another interesting piece of information: Over the weekend (both when on 4.6.8.2 and half-alive on 4.6.5.14) the RBS accepted the default login credentials of admin/password. But today it rejected those credentials and INSTEAD it accepted admin/<my personal password for the RBR>. Yeah, it went from "I only accept my default password" to "I only accept your customized password." It almost seems like 4.6.8.2 itself made the memory unreadable in a way that survives reboots but now after a night of rest the values are readable again. Weird.
Glad you got it working. Seems to have worked it self out.
I believe it's not the v.2 FW thats caused this, rather the auto update system and how it was applied that causes this. NG is experienced a high volume of bad updates that was recently pushed about two weekends ago. I believe it effected users that had not manually updated to v.2 prior that actually I posted about about a week prior to NG pushing it via the auto update path. Some of us included me had v.2 loaded on our systems manually and had not seen problems as expressed by you and others. v.2 FW is ok in it self when manually loaded. What ever caused the FW updates to go bad while being auto updated is still a mystery. Not the first time auto update has caused problems.
Glad you got it working. Be sure to save off a back up configuration to file for safe keeping. Saves time if a reset is needed.
https://kb.netgear.com/000062080/How-do-I-back-up-the-configuration-settings-on-my-Orbi-WiFi-System
Enjoy. 📡I've got the RBR850 - having the same problem. I've read the posts re: rolling out a fix - but also read about something called a 30/30/30
1. using a pin, press reset for 30 seconds. DO NOT STOP PRESSING
2. While still pressing reset (remember, do not let off) - unplug for 30 seconds. DO NOT STOP PRESSING
3. Plug back end - after 30 seconds, release pin
Bottom line, you're pressing the reset for a total of 90 seconds
When it came back online I was able to access via both the iOS app and 192.168.1.1
One user mentioned pressing the reset button for a total of 1 minute got them back in to the web page.
