NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Reliable way to put an Orbi Satellite (RBS50) in TFTP Server mode where I can push firmware
Hello, Can someone please describe reliable and repeatable steps to put an Orbi Satellite (RBS50) into a mode where I can tftp put the firmware image to it. I can get it to a state where it has...
No luck. nmrpflash also relies on TFTP but its unable to send the firmware to the device. I see this in tcpdump
00:13:07.177431 IP 192.168.2.2.62444 > 192.168.2.1.tftp: 30 WRQ "firmwareoctetblksize1456" [|tftp]
00:13:09.178786 IP 192.168.2.2.62444 > 192.168.2.1.tftp: 30 WRQ "firmwareoctetblksize1456" [|tftp]
00:13:11.180535 IP 192.168.2.2.62444 > 192.168.2.1.tftp: 30 WRQ "firmwareoctetblksize1456" [|tftp]
00:13:13.185118 IP 192.168.2.2.62444 > 192.168.2.1.tftp: 30 WRQ "firmwareoctetblksize1456" [|tftp]
00:13:15.187482 IP 192.168.2.2.62444 > 192.168.2.1.tftp: 30 WRQ "firmwareoctetblksize1456" [|tftp]
00:13:17.189839 IP 192.168.2.2.62444 > 192.168.2.1.tftp: 30 WRQ "firmwareoctetblksize1456" [|tftp]
I need a brute force way to get the Orbi Satellite to get into TFTP server mode. Or is there an alternate way where it can act as a TFTP client and download firmware?
screwgauge wrote:
No luck. nmrpflash also relies on TFTP but its unable to send the firmware to the device. I see this in tcpdump
00:13:07.177431 IP 192.168.2.2.62444 > 192.168.2.1.tftp: 30 WRQ "firmwareoctetblksize1456" [|tftp]
Maybe I'm reading this incorrectly. Flashing firmware is sort of a chore because the device and TFTP machine have to be disconnected from everything else, the computer has to be changed to a static IP, etc. Afterwards, it all has to be put back the way it was before.
If the satellite is at 192.168.1.250 (this is before it loads the firmware image and changes to the IP address that it has been assigned, usually using DHCP to learn what that IP address is), what is the point of sending packets from 192.168.2.2 to 192.168.2.1 ?
was wondering about the 2.1 address as well. Doesn't really follow the guide
This article claims that U-Boot used by Netgear routers waits for 3 seconds in case an NMRP firmware load might happen.
p.s. I had not realized that NMRPFlash is in active development. The latest version was released only 16 days ago!
p.p.s. It is also not clear (to me) whether NMRP protocol encapsulates TFTP or is in addition to TFTP.
When trying to tftp directly (not via nmrpflash), I had assigned a static IP of 192.168.1.1 to my Macbook (ethernet interface). Then I keep pinging 192.168.1.250 and at one point there is consistent ping but I cannot tftp to it since nothing on the Satellite is listening on port 69.
When you use nmrpflash it wants to assign a separate IP to the ethernet interface (on the Mac) and also assign one to the target (Satellite).
For this it aliases an IP (in my case 191.168.2.2 to the same Ethernet interface on the Macbook) and tries to offer 192.168.2.1 to the Satellite when it comes up. If you run nmrpflash without the -a and -A options, it does the same on a 10.xx subnet.
screwgauge wrote:
Then I keep pinging 192.168.1.250
(If there were merit badges for network expertise, I would not have one yet....)
I think the point is that during that three seconds, the satellite has not yet booted the firmware, and thus cannot respond to ICMP. The only firmware that is running is U-Boot and it waits only three seconds for a TFTP connection. After that, it is no longer 192.168.1.250. And, if the firmware that gets loaded is corrupted, it might not be anything at all.
