pbtran wrote:When you say "timeout" problem, do u mean when u try to re-flash the firmware with a designated "good" image build using tftp?

Yes that is what i am saying...
It answers the ping but i get timeout with whatever tool i use for tftp (and i used several ones)...
I thought i was not the only one having this problem...

Anyway i bought another one now so i'll be able to "play" all i want & can with this one. I'll let you know if i have some results ;)
But of course if anyone has an idea, i'm more than willing to learn ;)

All I can say is that it works fine if you are using Linux. I can't speak for any other OS or tftp client. Also make sure you don't have a firewall rule getting in your way on your client. Try and nmap the router and see what ports are open:

# nmap -sU -p 69 192.168.1.1

Last edited by Void Main on Sat Feb 04, 2006 8:26 pm, edited 2 times in total.

I don't use any firewall, and personally, I don't think it is a question of plateform, i'm on Mac OS X but i'm using the terminal (Basch) so in fact i think it is exactly the same thing as Linux.
Frankly i don't understand why tftp doesn't see the router when it pings correctly :/ But what makes me worry is the flashing power light...
I think i'll try the antenna short but Again, if someone has another idea...
:)

OK a little progress for me. Before with the pin 16 & 17 short, the router answered the ping but if i unplugged it, i had to do the short again. Now with the antenna trick, the router is pinging ok always, even if i unplug it. SO i'm happy BUT the problem is still the same, i mean the tftp still makes a time out :(
I don't know what else to try now :/ oops ! i'm sure to be close but still not there ...

Did you scan your router with nmap yet to see what ports are open like I asked in the last post? If the tftp port doesn't show up then your just wasting your time. And no, the tftp client on your Mac is not the same as the one on Linux, however it *should* work. I can't help you any more until I see the results of an nmap scan. If you don't have nmap you can get it from here:

The tftp server appears to be listening on port 69 which is good. I have to think it's a client issue. What are the *exact* commands you are giving when trying to tftp an image to your router? Have you ever successfully uploaded an image via tftp previously?

Yes i've done it once with a soft called "mactftp" wich is nothing more than a GUI for the OS X tftp client. There is a field for the password though...

Otherwise, with the terminal, i used exactly the same comands as you indicated for Linux (I confirmed it was the same for OS X on the man pages)
To be sure, here is what i do :
cd to the folder where the firmware is, check with a ls, then tftp 192.168.1.1, when it launches tftp, i go binary and then "put code.bin"

I wish so much that i'm forgeting something ;))

i don't know if this has something to do with the pass but sometimes it tells me "code pattern incorrect" Couldn't it be a password issue ?

No password required. Did you try and turn on verbose mode? What is the message you get when it fails, a timeout? It might also help to sniff out your network connection during the tftp to see what is actually going on. Do you have tcpdump or ethereal installed?

Well, you could do a capture to a file during the tftp and then upload it to my ftp server to look at. I don't know what your ethernet interface names are but if you only have one interface you shouldn't have to include it in the command line. So, open two shells. In one start up tcpdump and have it save the packets to/from 192.168.1.1 to a file called "wrt.cap":

# tcpdump -w wrt.cap host 192.168.1.1

In the other shell do your tftp. Make sure tcpdump is listening on the right interface. You may have to specify which one to listen on. On Linux the first ethernet interface is called "eth0", don't know what Mac uses so the command on Linux would be:

# tcpdump -i eth0 -w wrt.cap host 192.168.1.1

After the tftp transfer break out of the tcpdump command (CTRL+C). You can ftp that file to my server and I can look for anything unusual in it.

This is very kind of you man :)
I'll do that tomorrow, i mean in a few hours, it is almost 6 in the morning here in Paris, i have to get some sleep ;)
Thx again i'll send you the results during the day, you should have it when you'll wake up i guess :)

There are definitely 5 write requests and 0 response of any kind from your router. I guess the only other thing that may have been helpful is to have a ping before and after the tftp within the same capture. I have no doubt that pings work as you say though. There are only three possibilities that I can think of. 1) your router really is screwed or 2) you do have something on your Mac dropping outbound UDP 69 traffic (some sort of personal firewall setting) or 3) the router is not really in the shorted pin failsafe state but has booted up completely which is why you can ping it but tftp is not responding. However, then the nmap should show port 69 as "closed". Maybe it would also be good to get the nmap scan in the capture.

You can also just have tcpdump display it's output to the screen by not giving it the filename parameter. Ethereal is a little more visually pleasing though. I'll try and get a capture of a successful upload so you know what it *should* look like.