NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Joey17
Nov 30, 2020Tutor
Orbi RBR50 Pulsing White and no Network Appearing
A week ago my Orbi mesh network completely went down (an RBR50 with 2 RBS50 satellites). The RBR50 was pulsing white and the network could not be found in any of my devices. I believe the satellietes...
Joey17
Nov 30, 2020Tutor
No, I've tried accessing the the web page at 192.168.1.1 via ethernet many times throughout the process and never been able to reach it. Will try connecting to the serial port and see what I can do.
FURRYe38
Nov 30, 2020Guru - Experienced User
Let us know if that works for you.
- Joey17Dec 02, 2020Tutor
Connecting to the serial ports at least gave me a bit more information about the problem. It looks like there's something corrupted about the OpenWrt image because it runs into an error verifying the checksum:
## Checking Image at 843bffc0 ... Legacy image found Image Name: ARM OpenWrt Linux-3.14.77 Image Type: ARM Linux Kernel Image (lzma compressed) Data Size: 39061504 Bytes = 37.3 MiB Load Address: 40908000 Entry Point: 40908000 Verifying Checksum ... Bad Data CRC rootfs checksum error ## Booting kernel from FIT Image at 84000000 ... Using 'config@1' configuration Trying 'kernel@1' kernel subimage Description: ARM OpenWrt Linux-3.14.77 Type: Kernel Image Compression: gzip compressed Data Start: 0x840000e4 Data Size: 3523429 Bytes = 3.4 MiB Architecture: ARM OS: Linux Load Address: 0x80208000 Entry Point: 0x80208000 Hash algo: crc32 Hash value: 8b1e9c99 Hash algo: sha1 Hash value: d3b5236481fead36da4d4b1da5363d14b5fb553e Verifying Hash Integrity ... crc32 error! Bad hash value for 'hash@1' hash node in 'kernel@1' image node Bad Data Hash
Is there a way to reinstall OpenWrt? I'm assuming the standard TFTP firware updates don't update OpenWrt but correct me if I'm wrong. Using TFTP to upload a new firmware version doesn't change this error message.
- pbarhamDec 03, 2020Apprentice
Joey17 wrote:Connecting to the serial ports at least gave me a bit more information about the problem. It looks like there's something corrupted about the OpenWrt image because it runs into an error verifying the checksum:
Is there a way to reinstall OpenWrt? I'm assuming the standard TFTP firware updates don't update OpenWrt but correct me if I'm wrong. Using TFTP to upload a new firmware version doesn't change this error message.
As far as I understand it, the `fw_reccovery` command of the U-Boot console should upload a firmware image (from the netgear site) that includes the OpenWrt firmware and various other firmware blobs that seem to be used for radio interfaces. (at least, that's what the log output seemed to show) But - just because you sent an image from a laptiop dooesn't necessarily mean the router will accept it!
What I did to recover my router was:
1) Press a key on the serial console to interrupt the boot process and drop you into the U-boot command line
2) There you can poke around and examine the various config settings (`board_data_show` and various related commands)
3) You can start a tftp server that will accept a firmware image and write it to the flash memory using the `fw_recovery` command. It will tell you the IP address it's listening on (whichi was 192.168.1.250 for my router!) and you'll see logging when it receives data .
4) You can get u-boot to check out the image and validate it using the `bootdni` command (this will show your the kernel, openwrt versions etc)
What console output do you get from step 3) ? The first few times I tried this the update process complained that the new firmware image wasn't valid for the device. This was because the hardware id and model id had been corrupted in the config memory. I got error messages telling me what was expected and what was found. I couldn't upload the new image successfully until I'd fixed all these.
[I wrote a post with more detailed info in the thread that you linked to in an earlier message.]
I also at one point found some relevant threads on an OpenWrt hacking site suggesting that the U-boot firmware can run diagnostic tests on your flash memory to see if the chip is damaged (I expect this is unlikely)
- pbarhamDec 03, 2020Apprentice
pbarham wrote:The first few times I tried this the update process complained that the new firmware image wasn't valid for the device. This was because the hardware id and model id had been corrupted in the config memory. I got error messages telling me what was expected and what was found. I couldn't upload the new image successfully until I'd fixed all these.
To clarify ... as far as the tftp client on my laptop was concerned, the firmware file had been sent (PUT) to the router successuflly. But the router was failing to validate the image file and refusing write it to the flash. It's impossible to tell whether this is happening without looking at the serial console output! (three things were going wrong for me .... not setting 'binary mode' on the TFTP transfer, and the router not believing that it was the correct image file ... for two different reasons)
So long as you're happy you have the correct firmware image from Netgear for your router (RBR50 vs RBR50v2), you can just set the router's hardware ID to the ID that the firmarare image file contains and the error messages go away. Once the firmware is written to flash succesfully you should (hopefully) see different behavior after a reset.
Of course, there may be something totally differnt happening in your case - but from what I read on the OpenWrt sites, it's pretty hard to get the router into a totally unreoverable state. So long as U-boot it working you ought to be able to get things back (so long as there's no actiual hardware failure).
The uboot help command shows commands callled 'nand' and 'mmc' that I think are the ones where the tests and utilities live for the flash. The firmware gets uploaded to the MMC memory.