Firmware update on R7000P fails; Difficulty using TFTP from Mac

Pnurk · ‎2019-05-30

Hi all - haven't found the precise issue here, so I'm posting.

New router here. Last night on the web UI connected by wifi, I got the notification that a firmware update was available. Thinking this sounded like a smart idea, I clicked yes.

(I did turn off auto-update)

The web UI said to wait aprox 4 min. I did.
Web screen not updating.
Other devices not able to access internet.
Mysteriously, OOMA VOIP devices does not show offline.
Lights on router looking normal.
I went to bed, thinking this could take a while.
woke up in AM to message from "circle" that my router was disconnected
Lights on router still looking normal.
WiFi SSID not visible on iphone or macbook pro.
5g WiFi SSID appearing sporadically; Attempted to connect, connection not possible.

Thinking firmware update must be stuck, I turned off then on the router.
Orange flashing power button = firmware corrupted.
(Mystery of the year... why is there no onboard firmware restore?)

Find info for updating FW via TFTP.
Wire macbook pro to Router with straight Ethernet cable,
set Macbook pro to static IP 192.168.0.10
Successful PINGing 192.168.1.1 from macbook pro terminal

Download recommended Mac TFPT client, firmware files.
Do the 10-second Router turn-off as recommended.
Start pushing firmware file to Router; progress is very slow.

After 35 to 40 minutes, times out.
Tried again about five times over the course of a day or two.

Any other suggestions?
Mac only.
I might have a Windows XP virtual machine somewhere I can run in VMWare Fusion, but mac is preferable. Command line tools OK.

I've lost hours to this! gah.

thx for any help or wisdom.
tonight I will try the TFTP again, just for the sake of trying.

Pnurk · ‎2019-06-01

Success!

Perhaps I was being too rushed previously, but this time I got it to work first try.

I'll post steps below.

TL;TR:

- I used the OSX command line version of TFTP.

- It took about 40 minutes for the firmware to push to the router.

- ping was useful to know that my computer was communicating properly w the router.

- I put the firmware file at the top level of my user home directory (user folder)

- I had no luck w/ the GUI software recommended elsewhere in the forum and officially by netgear. It began the transfer then timed out and failed repeatedly for me and wasted many, many hours.

STEPS

- set computer to static IP in network settings. Lots of helpful instructions here but don't use their instructions for the tftp part on mac.

- turn off wifi, connect computer to router using an ethernet cable, to one of the downstream ports NOT the yellow upstream port. You may need an ethernet adapter if your computer does not have an ethernet port.

- download the firmware. I placed the firmware file (R7000P-V1.3.1.64_10.1.36.chk here) on the root level of my user directory. In the mac finder, you can navigate to this with keyboard shortcut shift-command-H or by picking "home" under the "go" menu.

- open two terminal windows. One is for Ping, one is for TFTP.

- in the first terminal, type "ping 192.168.1.1" and watch responses while booting. Once you have a flashing amber power light, ping should also be steadily responding.

- in the second terminal window, open a TFTP session to the router and once router is booted, begin sending file.

- it's ok to shut off ping by pressing control-c, or closing the ping window.

- if you want to see if data is travelling over the wire, watch the ethernet light on the router. Packets on that wire cause a flash in the light. This will show both ping packets and TFTP packets, so if you want to know your firmware is being sent, turn off ping.

- there is no status or progress info when transmitting. You simply have to wait. Here it took 40 minutes, on a 2012 macbok pro with gigabit ethernet.

- if successful, eventually you will see something like "Sent 48996410 bytes in 2249.1 seconds" in the terminal window.

TERMINAL TRANSCRIPT OF TFTP SESSION

mbp:~ ear$
mbp:~ ear$ tftp 192.168.1.1
tftp> binary
tftp> put R7000P-V1.3.1.64_10.1.36.chk
Sent 48996410 bytes in 2249.1 seconds
tftp> quit
mbp:~ ear$

the command "tftp 192.168.1.1" creates the connection.

the command "binary" causes it to use binary mode

the command "put R7000P-V1.3.1.64_10.1.36.chk" begins transmitting the firmware

****if you see no response, it's probably working****

to be sure data is being sent, look for flashing on the router's ethernet status light.

TERMINAL TRANSCRIPT FOR PING WINDOWN

Last login: Fri May 31 18:08:23 on ttys000
mbp:~ ear$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
64 bytes from 192.168.1.1: icmp_seq=0 ttl=100 time=4477.386 ms
64 bytes from 192.168.1.1: icmp_seq=1 ttl=100 time=3473.919 ms
64 bytes from 192.168.1.1: icmp_seq=5 ttl=100 time=1.665 ms
64 bytes from 192.168.1.1: icmp_seq=6 ttl=100 time=1.662 ms
64 bytes from 192.168.1.1: icmp_seq=7 ttl=100 time=1.676 ms
64 bytes from 192.168.1.1: icmp_seq=8 ttl=100 time=1.664 ms
Request timeout for icmp_seq 10
Request timeout for icmp_seq 11
Request timeout for icmp_seq 12
Request timeout for icmp_seq 13
Request timeout for icmp_seq 14
Request timeout for icmp_seq 15
Request timeout for icmp_seq 16
Request timeout for icmp_seq 17
Request timeout for icmp_seq 18
Request timeout for icmp_seq 19
Request timeout for icmp_seq 20
Request timeout for icmp_seq 21
Request timeout for icmp_seq 22
Request timeout for icmp_seq 23
64 bytes from 192.168.1.1: icmp_seq=24 ttl=100 time=4.522 ms
64 bytes from 192.168.1.1: icmp_seq=25 ttl=100 time=1.690 ms
64 bytes from 192.168.1.1: icmp_seq=26 ttl=100 time=1.653 ms
64 bytes from 192.168.1.1: icmp_seq=27 ttl=100 time=2.079 ms
64 bytes from 192.168.1.1: icmp_seq=28 ttl=100 time=1.679 ms
64 bytes from 192.168.1.1: icmp_seq=29 ttl=100 time=1.653 ms
64 bytes from 192.168.1.1: icmp_seq=30 ttl=100 time=1.686 ms
64 bytes from 192.168.1.1: icmp_seq=31 ttl=100 time=1.612 ms
64 bytes from 192.168.1.1: icmp_seq=32 ttl=100 time=1.643 ms
64 bytes from 192.168.1.1: icmp_seq=33 ttl=100 time=2.083 ms
64 bytes from 192.168.1.1: icmp_seq=34 ttl=100 time=1.635 ms

...etc

View solution in original post

shadowsports · ‎2019-05-30

In most cases, timing plays the biggest role along with proper execution. It sounds like you are very close.

Open two terminal windows. Set one to ping the gateway continiously. Now restart your router and watch the replies.

There is only a 1-3 sec period where the router is "listening" and will accept the FW during start up. If you miss it, no amount of tries or waiting will work.

Once you feel confident about the timing... Set the other terminal prompt up with the command.

Now restart the router and when the 1st window shows a reply, switch to the other window poised with the command and press enter.

Remember, it all comes down to timing.

antinode · ‎2019-05-30

> (Mystery of the year... why is there no onboard firmware restore?)

Adding more hardware and soft/firmware may not increase reliability,
but it will increase cost.

> Download recommended Mac TFPT client, [...]

Not necessary. You should be able to use the built-in command-line
TFTP client program.

https://community.netgear.com/t5/x/x/m-p/1622096

Pnurk · ‎2019-05-31

Thx, I discovered cruising through linked threads that there is TFTP client resident in Mac OSX, though I could not get it to work.

- Attempted one more time w/ “TFTP Client” mac app. Ran for about an hour then the client app quit. Flashing amber light continues.

- Set up a ping to router at 192.168.1.1, getting successful pings every 1 sec.. Watched it while turning off then back on.

Tried “timing” my TFTP start, but nothing has worked or seems a logical time to me.

Here is the sequence:
(Sequence step / router lights / term response)

1 - Power off. / no lights / “no route to host / request timeout”

2 - Power on / first only ether port led then all white led’s flash / “request timeout for icmp_seq” but with no “no route to host”

3 - few seconds later / A few secs of “request timeout for icmp_seq” alone

4 - few sec later / solid amber power led / (successful pings but only for about 3 seconds)

5 - four sec later / still solid amber led / “request timeout..”

6 - about 12 sec later / flashing amber power led / (successful 64byte pings which continue indefinitely.)

Using “TFTP client” OS X app:
I’ve attempted to start transmission at steps 3, 4, 5, and 6. Only at step 6 has there been any successful transmission. (The app has a status display “sent block nnn of 95,697” which holds at zero until packet tx starts getting ack).

Packets go out at roughly 20 per second. This would mean about 80 minutes to send all, and it’s never NOT timed out or failed somehow.

Attempted using OS X command line TFTP.
But I cannot for the life of me get it to accept the path to the firmware file, no matter what directory I place it in, etc it just reports “firmware.chk: No such file or directory”

Got the manpage for TFTP, don’t see anything unusual. I’m getting path to file every possible way, I’ve tried probably 20 ways, and other Unix apps see the path fine, no telling what’s up w that.

Still stuck, hours ticking away.
Have to try again tonight or weekend.

Thx - maybe this all makes sense to someone.

Pnurk

antinode · ‎2019-05-31

> Attempted using OS X command line TFTP.
> But I cannot for the life of me get it to accept the path to the
> firmware file, no matter what directory I place it in, etc it just
> reports "firmware.chk: No such file or directory"

Where is the file? Where are you? What is the actual name of the
".chk" file? Are you using that, or are you literally specifying
"firmware.chk"?

pwd
ls -l *.chk

If you leave "firmware.chk" on your desktop, then it should be at
"/Users/<user_name>/Desktop/firmware.chk". You could specify that
absolute path, or you could set your shell's current directory there:

cd # Go to your HOME directory.
cd Desktop # Go to your Desktop subdirectory.

From there, specifying plain-old "firmware.chk" in the command should
work. (Where "firmware.chk" represents the actual file name.)

> [...] I'm getting path to file every possible way, [...]

I hope not, but, with my weak psychic powers, I can't see any of what
you did. As usual, showing actual actions with their actual results
(commands, error messages, ...) can be more helpful than vague
descriptions or interpretations. Copy+paste is your friend.

> [...] maybe this all makes sense to someone.

I'd expect it to make sense to you, eventually. (After you reveal
exactly what fails.)

Pnurk · ‎2019-05-31

Yes, I hear you.

Alas, posting from phone because computer is offline because it's connected to the router.

Fairly certain I've not made a mistake w/ paths.

Firmware file was named as it came.

But also I made a duplicate and renamed it "firmware.chk" as that is easier to type.

Both are located in downloads folder

Transcript from terminal (username is "ear"):

mpb:~ ear$ ls -l *.chk
-rwxr-xr-x 1 ear staff 3639 Oct 26 2015 firmware.chk
mpb:~ ear$ ls -l *.chk
-rwxr-xr-x@ 1 ear staff 48996410 Mar 25 14:38 R7000P-V1.3.1.64_10.1.36.chk
-rwxr-xr-x@ 1 ear staff 48996410 Mar 25 14:38 firmware.chk
mpb:~ ear$
mpb:~ ear$ tftp 192.168.1.1
tftp> binary
tftp> put firmware.chk
tftp: firmware.chk: No such file or directory
tftp> put /Users/ear/Downloads/R7000P/firmware.chk
tftp: firmware.chk: No such file or directory
tftp> quit
mpb:~ ear$
mpb:~ ear$

antinode · ‎2019-06-01

> Fairly certain I've not made a mistake w/ paths.

Fairly confident that you have.

> But also I made a duplicate and renamed it "firmware.chk" as that is
> easier to type.

That's yet another reason why copy+paste is your friend. (Cmd+C,
Cmd+V in the Terminal app.)

I'm not sure that the router will accept that other name, but the
cause of a message like "tftp: firmware.chk: No such file or directory"
is certainly that "firmware.chk" does not exist (or, less likely, you
lack permission to read it, or something similar).

In my playing around, the only way I can get a "No such file or
directory" complaint from "tftp" is by specifying a nonexistent
file/path.

> Both are located in downloads folder

Or somewhere under it. "/Users/ear/Downloads/" is your Downloads
folder. "/Users/ear/Downloads/R7000P/" is a different folder, _under_
your Downloads folder.

> mpb:~ ear$ ls -l *.chk
> -rwxr-xr-x 1 ear staff 3639 Oct 26 2015 firmware.chk

> mpb:~ ear$ ls -l *.chk
> -rwxr-xr-x@ 1 ear staff 48996410 Mar 25 14:38 R7000P-V1.3.1.64_10.1.36.chk
> -rwxr-xr-x@ 1 ear staff 48996410 Mar 25 14:38 firmware.chk

A "pwd" command (or many more "pwd" commands) in there would be
better than trusting the prompt string, and that looks like two
different results from the same command, which also does not inspire
confidence. And "mpb:~ ear$ " looks fishy, and suggests that you're in
your HOME directory, not in "/Users/ear/Downloads/R7000P/".

> tftp> put /Users/ear/Downloads/R7000P/firmware.chk
> tftp: firmware.chk: No such file or directory

At that point (and back at the shell prompt):

ls -l /Users/ear/Downloads/R7000P/firmware.chk

would be more convincing. But, again, I'd stick with the original file
name.

My current guess is that you're making clerical errors, now.

r6700v1 · ‎2019-06-01

Can you still return it?

Pnurk · ‎2019-06-01