Posted: Tue Dec 01, 2015 0:50 Post subject: Post-Peacock WRT54G2 V1 tftp issues
Hello,
Some facts to kick us off. I have successfully reset the stock firmware, and upgraded to the VxWorksKiller-G2V1-new.bin package. After a 30-30-30 reset, I am able to ping the router at 192.168.1.1 with ttl=100. I am using the tftp commands: connect 192.168.1.1 and put <FIRMWARE>. I have tried the generic micro firmware, and the firmware recommended here http://www.dd-wrt.com/wiki/index.php/Linksys_WRT54G2, which is dd-wrt.v24-10709_NEWD_micro.bin
First ping output at poweron:
Code:
64 bytes from 192.168.1.1: icmp_seq=54 ttl=100 time=1001 ms
64 bytes from 192.168.1.1: icmp_seq=55 ttl=100 time=1.13 ms
64 bytes from 192.168.1.1: icmp_seq=56 ttl=100 time=0.716 ms
64 bytes from 192.168.1.1: icmp_seq=57 ttl=100 time=0.700 ms
64 bytes from 192.168.1.1: icmp_seq=58 ttl=100 time=0.713 ms
64 bytes from 192.168.1.1: icmp_seq=59 ttl=100 time=0.697 ms
64 bytes from 192.168.1.1: icmp_seq=60 ttl=100 time=0.713 ms
I have followed the wiki to put the firmware as soon as the first ping response is received. Like other users, I see my pings take much longer in the seconds following a tftp transfer, but the pings resume as usual with no apparent installation/reboot activity. I've waited 5 minutes and powered off/on, and I've repeated the transfer with the 30-30-30 reset. At each stage of the troubleshooting process, I am trying to connect to 192.168.1.1 through a browser without success.
At power-on, all the display icons light up. After booting, the only light on the unit is the port connected to ethernet. The power light does not come on at all. Of course, the unit still responds to pings so I have some hope.
Additional note:
In the Peacock thread I see the comment pertaining to common router default IP addresses:
Quote:
Some routers are 192.168.10.1 and some are 192.168.1.245.
But I believe the 192.168.1.245 was intended to be 192.168.1.254. The correction would make this consistent with my experiences anyway.
Thanks for providing such a helpful resource! I'll keep trying on my own. Grateful for any input you may have.
Last edited by mrquincy on Tue Dec 01, 2015 1:43; edited 2 times in total
G2 v1 is different than g v1. Check the wiki to see if a vxworks killer is needed for a 54g v1 _________________ SIG:
I'm trying to teach you to fish, not give you a fish. If you just want a fish, wait for a fisherman who hands them out. I'm more of a fishing instructor.
LOM: "If you show that you have not bothered to read the forum announcements or to follow the advices in them then the level of help available for you will drop substantially, also known as Murrkf's law.."
Last edited by Murrkf on Tue Dec 01, 2015 0:59; edited 1 time in total
I don't have that router but you might try another computer / different TFTP client --- make sure you have static IP set on your comper.
Not sure what may be wrong ---
or .... if all else fails I would try to get back to original following 'Reverting via VxWorksRevert'
towards bottom of your linked page.
Says you can use the VxWorksRevert-GSv7.bin -- I have used that many times -- it's harmless.
Generally you would use the dd-wrt GUI but you can try to TFTP it.... give it plenty of time.
If it works then you should be able to pull up firmware management page via 192.168.1.1 install
the GSv7 firmware and then the mod G2v1 firmware and be back to stock --- and if you can do all
that successfully you will have plenty of practice to start all over installing dd-wrt
EDIT:
The different IPs you mention are for different routers ..
the WRT54G2 v1 should have a 192.168.1.1 default IP
Thanks for the tips. Are there any error logs accessible via tftp, that we know about? I tried "get error" and received an immediate response of
Code:
"Error code 3: transfer cancelled"
However when I run the command "get log" it doesn't immediately fail, but the request times out. I wonder if there are additional parameters I can send to the tftp server that will give me some feedback on what I might be doing incorrectly?
In any case, I had an interesting result this time, when attempting to upload VxWorksRevert. When I booted the router, received the first ping response, and sent the VxWorksRevert package, I lost ping connectivity indefinitely. I thought this was a good sign, that things were updating in the background. However I waited about 10 minutes and no reboots were apparent. The power light never began to flash as the instructions indicate.
When I finally rebooted the router, the router began cheerfully responding to pings again with the ttl=100...so I'm still not dead in the water.
a.) tftp 192.168.1.1
b.) binary
c.) rexmt 1
d.) timeout 60
e.) trace
f.) put <FIRMWARE>
In my case, I used the dd-wrt.v24_micro_generic.bin
3.) Immediately, I noticed my power and wifi LED's blink. One or two automatic router reboots later, I was able to access the friendly and familiar dd-wrt web interface.
Some further thoughts:
There is a common line of discourse among dd-wrt users that they had to try tftp several times with different sized packages. This seems to indicate a lossy transfer...but I don't think this was my issue.
Working through my quoted code block from the bottom up...
e.) The trace command was fun because I could watch the transfer packets move in real-time, but wasn't especially useful.
d.) The "timeout 60" command set an upper limit of 1 minute to transfer the binary...but this transfer happened in 3 seconds, again, not necessary.
c.) "rexmt 1" set the retransmission timeout to 1 second, but the transfer went very smoothly so this is probably not my savior either.
b.) In the end...I think it was missing the "binary" command before putting the file...after all, if you're sending something over tftp, why should the tftp servers first inclination be to run it?
I think the binary command tells the tftpserver what to expect coming down the pipe, and to run it when it arrives. I was sending this package to the router as it was running the VxWorksKiller-G2V1-new.bin firmware.
Hope this helps others with this model. And I should also mention that there is a chance that my first half dozen transfers were indeed lossy, and my success was arbitrarily coincident with the "binary" tftp command. Hope not...but it's possible.
-----
Edit: It could also be that the VxKiller firmware was successfully replaced with the VxRevert firmware as performed in my post above this post, and the VxRevert firmware had no problems receiving and executing the generic_micro firmware. This might be the most likely explanation for my success after all.
-----
ps edit- I brought up the "192.168.1.245" router IP from the Peacock thread in particular because it's traditional to use a gateway IP of either the first available address in the last octet xxx.xxx.xxx.1 or to use the last ip address before the broadcast address, which is xxx.xxx.xxx.254. I don't know of any routers that use 192.168.1.245, but I might just be ignorant.
