Forum Discussion

Tutor

May 30, 2019

Solved

Firmware update on R7000P fails; Difficulty using TFTP from Mac

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 t...

Pnurk
Jun 01, 2019
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

Pnurk

Tutor

May 31, 2019

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

Guru

May 31, 2019

> 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
Tutor
May 31, 2019
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
  Guru
  Jun 01, 2019
  > 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.