Posted: Wed Jun 19, 2013 20:06 Post subject: Netgear R6300 testbuild rollback (to OEM firmware)
I didn't want to hijack the more general thread on testing dd-wrt on the Netgear R6300 so I've started this thread. I thought it may prove useful for those trying the dd-wrt solution and then needing to revert.
I've tried the various "how to" directives on the site that I've been able to find, and as the R6300 is still in testing it makes some of the information not applicable.
At this time, the release by Kong does not allow for reinstalling Netgear OEM firmware through the web interface.
I've tried to push the OEM .chk file by TFTP but have been unsuccessful so far.
If anyone can comment, is there a "delete" step necessary between running with dd-wrt and then pushing the OEM firmware back? I was running with the assumption that if you tftp'd during the loader period it would overwrite automatically. I didn't know if this may be the cause of the inability to transfer.
Specifically the following has failed:
OS: Windows 8
TFTP clients: Windows generic, tftp2, tftpd32, tftpd64, Winagents.com tftp.exe
I tried lowering the e'net to 100mbs. I tried a switch between PC and router. I tried various 30-30-30 / reset button / power cycle attempts.
The router does show the TTL=100 for about 14 iterations which I believe is indicative of the TFTP server startup. Unfortunately none of these pushes the image.
Posted: Thu Jun 20, 2013 3:13 Post subject: Re: Netgear R6300 testbuild rollback (to OEM firmware)
javamarket wrote:
I didn't want to hijack the more general thread on testing dd-wrt on the Netgear R6300 so I've started this thread. I thought it may prove useful for those trying the dd-wrt solution and then needing to revert.
I've tried the various "how to" directives on the site that I've been able to find, and as the R6300 is still in testing it makes some of the information not applicable.
At this time, the release by Kong does not allow for reinstalling Netgear OEM firmware through the web interface.
I've tried to push the OEM .chk file by TFTP but have been unsuccessful so far.
If anyone can comment, is there a "delete" step necessary between running with dd-wrt and then pushing the OEM firmware back? I was running with the assumption that if you tftp'd during the loader period it would overwrite automatically. I didn't know if this may be the cause of the inability to transfer.
Specifically the following has failed:
OS: Windows 8
TFTP clients: Windows generic, tftp2, tftpd32, tftpd64, Winagents.com tftp.exe
I tried lowering the e'net to 100mbs. I tried a switch between PC and router. I tried various 30-30-30 / reset button / power cycle attempts.
The router does show the TTL=100 for about 14 iterations which I believe is indicative of the TFTP server startup. Unfortunately none of these pushes the image.
Does the router come back up after the 14 TTL=100 and run DD-WRT?
I recently restored my original firmware from a bricked R6300 (would reboot all the time, shows a second of TTL=100ms pings, but doesn't accept a tftp connection).
I bought a $5 USB-TTL converter from ebay. The R6300 has a serial header on the board. Use a voltmeter to see what's +5V and what's GND. Connect TX, RX and GND. Skip the 5V.
Install the appropriate prolific driver (available also for the Mac), connected using some terminal program ('screen' in terminal, if you have a unix-like system) with, I think, 115200bps. Fire up the router. Fix baud rate or TX/RX connections if gibberish seen. Hit Control-C early in the boot phase to get to the CFE prompt. Start tftp server (see below) and upload with tftp via ethernet (and static 192.168.1.2 IP). The unbrick guide is below, and the process was really much simpler than trying to upload via tftp at just the right in the boot process (and I tried this way too often...)
Posted: Sun Jun 23, 2013 23:30 Post subject: rollback
davidswelt wrote:
I recently restored my original firmware from a bricked R6300 (would reboot all the time, shows a second of TTL=100ms pings, but doesn't accept a tftp connection).
Thank for the information. I'm trying to do it without having to open the unit. I was hoping I may be missing a part of the TFTP process but I don't think I am.
Hopefully Kong or another will incorporate rolling back through the GUI. I'm lucky in that I'm not bricked, it is usable. The problem is it doesn't have WDS functionality which is what I need.
If it comes to it at least we have a reference for those who search out the process.
Try the tftp32 program. It worked on a Netgear wndr3300 with ttl=100 where the other tftp programs didn't work. _________________ I am far from a guru, I'm barely a novice.
Try the tftp32 program. It worked on a Netgear wndr3300 with ttl=100 where the other tftp programs didn't work.
Thanks for the suggestion... unfortunately no go. I had tried both the 32bit and 64bit versions (that is assuming you mean tftpd32 / 64 open source)
I met the same situation as you, the light stay in amber and the router reboot every 20-30 seconds.
I have tried the Ctrl-c via USB-TTL, but failed. However, after I connected the Samsung K9F1G08 pin 41 and 42, then power on, the light became to blinking blue, then the TFTP works.
But I tried serval times to make the TFTP success finally.
The theory is that the connection in flash memory chip will make the CRC check failed, then the system go to the TFTP automatically.
I think Netgear locked the Ctrl-C in CFE, it's useless for me.
Try the tftp32 program. It worked on a Netgear wndr3300 with ttl=100 where the other tftp programs didn't work.
Thanks for the suggestion... unfortunately no go. I had tried both the 32bit and 64bit versions (that is assuming you mean tftpd32 / 64 open source)
I met the same situation as you, the light stay in amber and the router reboot every 20-30 seconds.
I have tried the Ctrl-c via USB-TTL, but failed. However, after I connected the Samsung K9F1G08 pin 41 and 42, then power on, the light became to blinking blue, then the TFTP works.
But I tried serval times to make the TFTP success finally.
The theory is that the connection in flash memory chip will make the CRC check failed, then the system go to the TFTP automatically.
I think Netgear locked the Ctrl-C in CFE, it's useless for me.
Thank for Kong's theory support.
No you are just too slow pressing CTRL-C. You have to hit it right at the moment you power on.
In addition to that make sure you only use my current chk for initial flashing. Older chk maycause a brick if you change anything at the Administration Management Tab. _________________ KONG PB's: http://www.desipro.de/ddwrt/
KONG Info: http://tips.desipro.de/
I didn't want to hijack the more general thread on testing dd-wrt on the Netgear R6300 so I've started this thread. I thought it may prove useful for those trying the dd-wrt solution and then needing to revert.
I've tried the various "how to" directives on the site that I've been able to find, and as the R6300 is still in testing it makes some of the information not applicable.
At this time, the release by Kong does not allow for reinstalling Netgear OEM firmware through the web interface.
I've tried to push the OEM .chk file by TFTP but have been unsuccessful so far.
If anyone can comment, is there a "delete" step necessary between running with dd-wrt and then pushing the OEM firmware back? I was running with the assumption that if you tftp'd during the loader period it would overwrite automatically. I didn't know if this may be the cause of the inability to transfer.
Specifically the following has failed:
OS: Windows 8
TFTP clients: Windows generic, tftp2, tftpd32, tftpd64, Winagents.com tftp.exe
I tried lowering the e'net to 100mbs. I tried a switch between PC and router. I tried various 30-30-30 / reset button / power cycle attempts.
The router does show the TTL=100 for about 14 iterations which I believe is indicative of the TFTP server startup. Unfortunately none of these pushes the image.
Not sure if this would help but when trying to go to OEM from the other dd-wrt firmware before Kong's, I finally got it to pop by putting the 30-30-30 somewhere in the sequence. I can't remember what I did because I was working on it for hours on a few days and it finally popped to install the OEM.
Thanks for the history ... if I find a low-frustration day perhaps I'll try once again. I think I went at it for the better of 8 hours before quitting.
I'm sure BS or Kong will get around to incorporating it into the webpage at some point...
