Posted: Tue May 25, 2010 15:36 Post subject: WNR3500v2 stuck in waiting for tftp mode [Solved]
First things first - I have read the peacock post at least 1/2 dozen times. :)
That's how I learned that when my router is replying 100% to pings with TTL=100, it's waiting for a tftp.
However, the problem is I can keep sending a .chk firmware file, it will always report success, but nothing will happen (I have waited 10+ minutes for it to do something). The green power LED will continue to blink and ping will continue to reply with TTL=100.
Some people have posted that sending the firmware twice does the trick, but not for me.
If I send it a .bin file, the router stops responding, and it essentially freezes (again, I have waited 10+ minutes for it to do something). I then proceed to power cycle it, and it goes back to green blinking LED and TTL=100.
How I got here:
I flashed dd-wrt.v24-14311_NEWD-2_K2.6_mini-WNR3500v2.chk, which I found in the router database, using the factory GUI. So far so good.
Then I flashed dd-wrt.v24-14311_NEWD-2_K2.6_mini.bin. So far so good.
But then I wanted to go back to factory firmware. When I tried flashing the factory .chk file, DD-WRT said "upgrade failed". I tried renaming .chk to .bin and still got "upgrade failed". OK, 30/30/30, tried again, still "upgrade failed".
So I got a shell and did
Code:
erase linux
reboot
...and now the router is stuck waiting for a tftp. No amount of "successful" tftp transfers will get the firmware to "stick" and load.
Please help!
Last edited by tsanga on Thu Jun 17, 2010 12:25; edited 1 time in total
If you cannot flash the trailed build, the mini build, or stock firmware, you need to erase the nvram and kernel with serial or jtag (if the router supports jtag).
Follow the instructions at note 11 of the peacock, starting with the k26 13527 mini, then the trailed build, then oem.
Make sure you make sure it isn't a browser issue by trying another browser, and check your power supply.
Thanks for the advice. At the moment I don't have a USB-TTL cable for this and there's no header on the board, so some soldering will be involved. I'll have to contemplate doing this when I have some time.
However, what I read about using JTAG involves interrupting the boot routine and starting the tftp service. Will this help my current situation? The signs (ping response, blinking LED, successful tftp) point to the tftp daemon already running and accepting communication.
Thanks for the heads up - sounds like serial is the way to go.
Can the same cfe bug cause the message "upgrade failed" when flashing through the DD-WRT GUI? Or was that a browser issue? I thought I was playing it safe with IE but still got that message. That's when I decided to stop trying with the GUI and go to tftp.
Also, since the router is apparently accepting tftp, does this confirm that the CFE is working properly? I read somewhere on here that if the CFE is broken, then even a serial connection will not fix it (cannot restore CFE if CFE is already broken).
CFE for WNR3500v2 version: v1.0.29
Build Date: Fri Jun 12 11:11:15 CST 2009
Init Arena
Init Devs.
Boot partition size = 262144(0x40000)
Found a 4MB ST compatible serial flash
et0: Broadcom BCM47XX 10/100/1000 Mbps Ethernet Controller 5.10.56.28
CPU type 0x19740: 453MHz
Tot mem: 32768 KBytes
Device eth0: hwaddr 00-26-F2-14-58-54, ipaddr 192.168.1.1, mask 255.255.255.0
gateway not set, nameserver not set
Checksum mismatch:
Image chksum: 0xFFFFFFFF
Calc chksum: 0x09F603FC
Invalid boot block on disk
Start TFTP server
Reading ::
Then I tried to flash:
Quote:
CFE for WNR3500v2 version: v1.0.29
Build Date: Fri Jun 12 11:11:15 CST 2009
Init Arena
Init Devs.
Boot partition size = 262144(0x40000)
Found a 4MB ST compatible serial flash
et0: Broadcom BCM47XX 10/100/1000 Mbps Ethernet Controller 5.10.56.28
CPU type 0x19740: 453MHz
Tot mem: 32768 KBytes
Device eth0: hwaddr 00-26-F2-14-58-54, ipaddr 192.168.1.1, mask 255.255.255.0
gateway not set, nameserver not set
Startup canceled
CFE> ^C
CFE> flash : flash1.trx
Reading :: Done. 3301434 bytes read
*** command status = -42
CFE> go
Checksum mismatch:
Image chksum: 0xFFFFFFFF
Calc chksum: 0x09F603FC
Invalid boot block on disk
Start TFTP server
Reading ::
Can anybody offer more pointers?
EDIT:
I then added some parameters to the flash command and got it to re-write the checksum, but it's still wrong:
Quote:
CFE> flash -noheader -writechksum : flash1.trx
Reading :: Done. 3461178 bytes read
Programming...done. 3461178 bytes written
Write len/chksum offset @ 0x0034FFF8...done.
*** command status = 0
CFE> go
Checksum mismatch:
Image chksum: 0x8074EE40
Calc chksum: 0x01B700CF
Invalid boot block on disk
Start TFTP server
...and then flashing green LED, running tftp server, and no response upon successful upload. Basically the same signs as before I hooked up the serial cable.
Then, one more try:
Quote:
CFE> flash -noheader -writechksum : flash1.trx
But made sure I uploaded the k26 13527 mini build. That worked!
This command didn't work without the -noheader switch to ignore header checking.
I still get a checksum error:
Quote:
CFE for WNR3500v2 version: v1.0.29
Build Date: Fri Jun 12 11:11:15 CST 2009
Init Arena
Init Devs.
Boot partition size = 262144(0x40000)
Found a 4MB ST compatible serial flash
et0: Broadcom BCM47XX 10/100/1000 Mbps Ethernet Controller 5.10.56.28
CPU type 0x19740: 453MHz
Tot mem: 32768 KBytes
Device eth0: hwaddr 00-26-F2-14-58-54, ipaddr 192.168.1.1, mask 255.255.255.0
gateway not set, nameserver not set
Loader:raw Filesys:tftp Dev:eth0 File:192.168.1.2:vmlinuz Options:(null)
Loading: Failed.
Could not load 192.168.1.2:vmlinuz: Timeout occured
Checksum mismatch:
Image chksum: 0x00000000
Calc chksum: 0x02C0010E
Loader:raw Filesys:raw Dev:flash0.os File: Options:(null)
Loading: .. 3856 bytes read
Entry at 0x80001000
Closing network.
Starting program at 0x80001000
Linux version 2.6.24.111 (root@dd-wrt) (gcc version 4.1.2) #57 Mon Dec 28 17:30:40 CET 2009
CPU revision is: 00019740
Found a 4MB ST compatible serial flash
Determined physical RAM map:
memory: 02000000 @ 00000000 (usable)
.
.
.
.
But somehow DD-WRT goes on working. I have tested flashing firmware with the GUI now, and any DD-WRT .bin file works. When I try to re-flash the factory firmware through the GUI, I get this:
Quote:
/tmp/uploadwmSowt: Bad trx header
uploading [3301482]
I have no way to revert back to factory firmware. Guess I'm stuck on DD-WRT.
