NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
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 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.
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
8 Replies
- Can you still return it?
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
> (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.- 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> 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 *.chkIf 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.)
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.
