NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
R6400V2 failed firmware
Ok all, I was recently (today) upgrading my frimware for the R6400v2 through the router's web portal. While uploading the firmware, it failed. No idea why it failed, but it did. Suddenly, I l...
> [...] what appears to be a cycle [...]
In some cases, the router can get into a (failing) boot loop, which
might mean that if it's ever receptive to a TFTP load, then you might
need to catch it at the right time. Some experimentation may be needed.> [...] (see attached).
You're running the "tftp" program, and then giving _it_ a command to
run the "tftp" program.> [...] But the "$" int he above is what confuses me.
What was on the line before what you posted? That "$" was supposed
to represent (abbreviated) the prompt from your shell (which, as your
"ping" picture showed, is pretty long, but does end in "$ ").So, the actual command should look like:
<blah-blah-blah> $ tftp 192.168.1.1of which you type only: tftp 192.168.1.1
The "tftp" program uses a "tftp> " prompt, and you type whatever
appears after that in the example.> [...] I'm sorry, I'm a bit novice at this. [...]
I noticed. Just bask in the education. Wheee.
> [...] I already did the /usr/bin/tftp bit to access the tftp.
That was what the "tftp 192.168.1.1" command was for. You could,
instead, do:$ tftp
tftp> connect 192.168.1.1which would be equivalent to (but more work than):
$ tftp 192.168.1.1
The "put fred.img" command assumes that your firmware image file (use
its actual name) is in the shell's current directory. Otherwise, you'd
need to specify an appropriate path to it (like the one (partially)
shown in your Tftpd64 screen shot, but with a Mac/unix syntax instead of
a PC\Windows syntax). For some shell navigation basics, see, for
example:
> [...] Came back with "Connect request failed"
> I just tried to ping the router (everything is static IP) 192.168.1.1
> and is came back as "Desitation host unreachable"
If the computer's Ethernet IP address is "192.168.1.x" (where
1 < x < 255), then it would seem that your router is not communicating
as expected.
> [...] only connected to my MacbookPro running OS High Sierra via USB
> to ethernet port.
Have you verified that the Ethernet adapter works? (Connect it to
some other router?) You connected the computer/adapter to a router LAN
Ethernet port?
> Does this essentially mean I'm bricked and need to buy a new one?
If you can't get it to respond to anything networkly, then the last
chance might be opening the box and using a serial port connection.
(Yet another adapter required.) A Web search for terms like "Netgear
serial" should find details on that possibility. I've never tried it.
A new(er) router might be a wiser choice in that case.
Here's the interesting thing. When I cmd ping the router (192.168.1.1), it's looking for replies from the computer IP (192.168.1.10).
See screen shot
Could this by why it's not communicating?
> [...] it's looking for replies from the computer IP (192.168.1.10).
I 'd read that not as it looking for replies from "192.168.1.10", but
that the system at "192.168.1.10" is complaining."destination host unreachable" suggests to me a bad IP/routing
configuration somewhere. Did you disable the Wi-Fi interface on this
Windows system, and properly configure its Ethernet interface? Having
both interfaces active (especially on the same subnet) could cause some
confusion.>Did you disable the Wi-Fi interface on this
>Windows system, and properly configure its Ethernet interface?I do believe so. Attached is my configuration on the Ethernet interface. I have been hotspotting on my phone throughout all of this, so I turned my hotspot off and set my Mac to the same Static IP info as what attached. I also turned off my MacBook Pro's wi-fi.
Again, I'm running parallels, so I thought perhaps both OS systems needed to be set to static.
Through all of this, setting both OS systems to static, turning off my hotspot, I am still receiving the "Destination host unreachable" message when attempting to ping the IP from Windows OS (I'm running Windows 8, btw).
> I do believe so. Attached is my configuration on the Ethernet
> interface. [...]Looks ok, but I'm still worried about the wireless interface.
> Again, I'm running parallels, [...]
I'm ignorant of it, and its implications for networking, but I'd bet
on there being some, what with the shared/virtual hardware, and all.
> When I ping from my Mac OS, I get this (see attached).That's how success looks. You might want to try the TFTP from there.
(Note that the syntax/usage is different between the Windows and Mac
TFTP clients.)> And it just doesn't stop. [...]
Hit "control/C" (hold "control", hit "C") to interrupt it.
man pingshould explain the "-c <count>" option, if you want to limit it in a
more controlled way.All hope may not yet be exhausted...
>You might want to try the TFTP from there.
Ok, I will give it a shot!
I assume the instructions are still the same (minus the different syntax for the command lines in Mac)?
If so, I have questions about the instructions from this guide.
- Turn router OFF for 10 seconds.
- Hold down the reset button on the back of router with a paper clip.
- Power ON the router while holding down the reset button.
- Watch the Power LED. It starts with an orange color, and then start flashing.
- Count at least 10 flashing power LED and release the reset button.
When I turnon the router while holding down the reset button, I don't get the Power LED flashing. What I get is what appears to be a cycle of all the lights flahsing on, then all off, then the Power LD on solid amber with the ethernetport I'm plugged into solid white, then all off, then all on and the cycle repeats.
Per the "Count at least 10 flashing [...]", am I to sit through 10 cycles of the above mentioned and then release the reset button, then press enter on the Terminal to push the firmware?
And another quesiton, on this post here, you have:
$ tftp 192.168.1.1
tftp> binary
tftp> put fred.img
tftp> quitWhen I attempt to type the above line, I get this error (see attached). How do I go about typing that whole thing into my terminal? I'm sorry, I'm a bit novice at this. I already did the /usr/bin/tftp bit to access the tftp. But the "$" int he above is what confuses me.
Thanks for sticking this out with me. I think we're really getting close to either fixing it, or understanding there's no hope!
> [...] what appears to be a cycle [...]
In some cases, the router can get into a (failing) boot loop, which
might mean that if it's ever receptive to a TFTP load, then you might
need to catch it at the right time. Some experimentation may be needed.> [...] (see attached).
You're running the "tftp" program, and then giving _it_ a command to
run the "tftp" program.> [...] But the "$" int he above is what confuses me.
What was on the line before what you posted? That "$" was supposed
to represent (abbreviated) the prompt from your shell (which, as your
"ping" picture showed, is pretty long, but does end in "$ ").So, the actual command should look like:
<blah-blah-blah> $ tftp 192.168.1.1of which you type only: tftp 192.168.1.1
The "tftp" program uses a "tftp> " prompt, and you type whatever
appears after that in the example.> [...] I'm sorry, I'm a bit novice at this. [...]
I noticed. Just bask in the education. Wheee.
> [...] I already did the /usr/bin/tftp bit to access the tftp.
That was what the "tftp 192.168.1.1" command was for. You could,
instead, do:$ tftp
tftp> connect 192.168.1.1which would be equivalent to (but more work than):
$ tftp 192.168.1.1
The "put fred.img" command assumes that your firmware image file (use
its actual name) is in the shell's current directory. Otherwise, you'd
need to specify an appropriate path to it (like the one (partially)
shown in your Tftpd64 screen shot, but with a Mac/unix syntax instead of
a PC\Windows syntax). For some shell navigation basics, see, for
example:> [...] do I need to indicate where in the computer the firmware file
> is? [...]One way or another, yes. You can "cd" your shell to the directory
(folder) where the firmware image file is, or you can specify a path to
the file in the "put" command. For example, if the "<long_name>.chk"
file is on your desktop, then a sequence like:cd # Returns to your home directory.
cd Desktop # Drops down to your "Desktop" subdirectory.then:
ls -l *.chk
should show you the firmware image file. And you could then specify
just that name in your "put" command.> https://community.netgear.com/t5/x/x/m-p/1694410
This is the guide that did it! Saved me money on a new router! Thank you!
I didn't need to power cycle anything to get put the firmware. I followed the steps in the above guide using the terminal and hit enter on the put. Took 56 seconds for the firmware to be uplaoded and about 3mins for the router to cycle through it's reboot and everything is now white.
I did however lose all my previous settings, but that might be from the multiple resets I attempted, the 30/30/30 I attempted, and the reboot cycle mentioned in an earlier comment. Doesn't matter, I can reset everything, just happy to be back up and running!
I'll be sure to manually update firmware from here on out.
> This is the guide that did it! [...]
The only problem there is avoiding the lame parts. (But what could
go wrong?)> [ I did however lose all my previous settings, but that might be from
> the multiple resets I attempted, [...]Any one settings reset would reset the settings.
> I'll be sure to manually update firmware from here on out.
It's not a guarantee, but it's probably safer. I wired connection
also might be more reliable than a wireless one.
