2011-07-28 16:45:29     uBoot TFTP stopped working

Document created by Aaronwu Employee on Sep 25, 2013
Version 1Show Document
  • View in full screen mode

2011-07-28 16:45:29     uBoot TFTP stopped working

Wojtek Skulski (UNITED STATES)

Message: 102703   

 

Hi:

 

a weird problem. Maybe someone has suggestions. Today I tried to tftp the uImage to the board using uBoot. I followed the same procedure and used the same equipment which worked a month ago. Today it does not work. The TFTP server reports a timeout and uBoot displays these dreaded "T". So I used Wireshark. It tells me that the data gets directed to some weird port 1595 (a radio port according to IANA). How could that happen? It is true that my Blackfin board and the TFTP server PC are connected to a netgear router, which has an antenna. But wireless is disabled. Both machines are connected with cables. TFTP used to work a month ago when I last reflashed the board.

 

I think that the data should be going to port 69, which is TFTP port. But in Wireshark record says that Dell TFTP server is sending data to port 1595 in response to the request from the board, which is coming from 1595 in frame 3.

 

Any idea how to force these guys to use port 69 ? Why is anything coming from the radio port in frame 3?

 

Here are the first few frames. The board is 192.168.1.3. The Dell TFTP server is 192.168.1.2. Look at frame 3 where Src Port: radio (1595).

 

No.     Time        Source                Destination           Protocol Info

1    0.000000    02:80:ad:20:31:b8     Broadcast             ARP      Who has 192.168.1.2?  Tell 192.168.1.3

 

Frame 1 (60 bytes on wire, 60 bytes captured)

Ethernet II, Src: 02:80:ad:20:31:b8 (02:80:ad:20:31:b8), Dst: Broadcast (ff:ff:ff:ff:ff:ff)

Address Resolution Protocol (request)

 

No.     Time        Source                Destination           Protocol Info

      2 0.000012    Dell_a5:ba:ed         02:80:ad:20:31:b8     ARP     192.168.1.2 is at 84:2b:2b:a5:ba:ed

 

Frame 2 (42 bytes on wire, 42 bytes captured)

Ethernet II, Src: Dell_a5:ba:ed (84:2b:2b:a5:ba:ed), Dst: 02:80:ad:20:31:b8 (02:80:ad:20:31:b8)

Address Resolution Protocol (reply)

 

No.     Time        Source                Destination           Protocol Info

      3 0.000366    192.168.1.3           192.168.1.2           TFTP  

Read Request, File: uImage\000, Transfer type: octet\000, 5=5\000, 1468=1468\000

 

Frame 3 (80 bytes on wire, 80 bytes captured)

Ethernet II, Src: 02:80:ad:20:31:b8 (02:80:ad:20:31:b8), Dst: Dell_a5:ba:ed (84:2b:2b:a5:ba:ed)

Internet Protocol, Src: 192.168.1.3 (192.168.1.3), Dst: 192.168.1.2 (192.168.1.2)

User Datagram Protocol, Src Port: radio (1595), Dst Port: tftp (69)

Trivial File Transfer Protocol

 

No.     Time        Source                Destination           Protocol Info

      4 0.000685    192.168.1.2           192.168.1.3           TFTP  

Option Acknowledgement, 1468=1468\000, 5=5\000

 

Frame 4 (67 bytes on wire, 67 bytes captured)

Ethernet II, Src: Dell_a5:ba:ed (84:2b:2b:a5:ba:ed), Dst:

02:80:ad:20:31:b8 (02:80:ad:20:31:b8)

Internet Protocol, Src: 192.168.1.2 (192.168.1.2), Dst: 192.168.1.3

(192.168.1.3)

User Datagram Protocol, Src Port: wfremotertm (1046), Dst Port: radio (1595)

Trivial File Transfer Protocol

QuoteReplyEditDelete

 

 

2011-07-28 22:07:29     Re: uBoot TFTP stopped working

Wojtek Skulski (UNITED STATES)

Message: 102705   

 

I made another observation. The TFTP server and the Blackfin board are connected via a LAN switch (HP procurve switch 408). The cable from the switch goes to the Netgear router. So I disconnected that cable. After doing so, the Blackfin and the TFTP server are now connected via the switch, but there is no gateway on the net. The wireshark record now shows, that the request from the uBoot comes from port 3984 in frame 3. The TFTP server sends the data packets to that port in frame 4. The packets are not received by the uBoot, and the TFTP fails with a timeout.

 

Also note that TFTP server sends its response in frame 4 not from port 69, but from port 1046. In frame 5 uBoot (again dutifully) responds to the same port 1046.

 

So it looks as if uBoot is sending the requests from a random port. The TFTP server dutifully sends the responses back to the same port rather than to the tftp port 69. Also note that TFTP server is also switching ports. In frame 4 the TFTP server is sending its answer from port 1046.

 

Why are the uBoot and TFTP server keep switching the ports in this semi-random way rather than keep using port 69?

 

Should I throw away the network switch which was working OK for more than a month? Could the switch have been damaged by Martians?

 

In the following the frames 1 and 2 are ARP frames. The real dialog starts in frame 3.

 

Frame 1 (60 bytes on wire, 60 bytes captured)

Ethernet II, Src: 02:80:ad:20:31:b8 (02:80:ad:20:31:b8), Dst: Broadcast (ff:ff:ff:ff:ff:ff)

Address Resolution Protocol (request)

 

No.     Time        Source                Destination           Protocol Info

      2 0.000010    Dell_a5:ba:ed         02:80:ad:20:31:b8     ARP      192.168.1.2 is at 84:2b:2b:a5:ba:ed

 

Frame 2 (42 bytes on wire, 42 bytes captured)

Ethernet II, Src: Dell_a5:ba:ed (84:2b:2b:a5:ba:ed), Dst: 02:80:ad:20:31:b8 (02:80:ad:20:31:b8)

Address Resolution Protocol (reply)

 

No.     Time        Source                Destination           Protocol Info

      3 0.000371    192.168.1.3           192.168.1.2           TFTP     Read Request, File: uImage\000, Transfer type: octet\000, 5=5\000, 1468=1468\000

 

Frame 3 (80 bytes on wire, 80 bytes captured)

Ethernet II, Src: 02:80:ad:20:31:b8 (02:80:ad:20:31:b8), Dst: Dell_a5:ba:ed (84:2b:2b:a5:ba:ed)

Internet Protocol, Src: 192.168.1.3 (192.168.1.3), Dst: 192.168.1.2 (192.168.1.2)

User Datagram Protocol, Src Port: mapper-nodemgr (3984), Dst Port: tftp (69)

Trivial File Transfer Protocol

 

No.     Time        Source                Destination           Protocol Info

      4 0.000685    192.168.1.2           192.168.1.3           TFTP     Option Acknowledgement, 1468=1468\000, 5=5\000

 

Frame 4 (67 bytes on wire, 67 bytes captured)

Ethernet II, Src: Dell_a5:ba:ed (84:2b:2b:a5:ba:ed), Dst: 02:80:ad:20:31:b8 (02:80:ad:20:31:b8)

Internet Protocol, Src: 192.168.1.2 (192.168.1.2), Dst: 192.168.1.3 (192.168.1.3)

User Datagram Protocol, Src Port: wfremotertm (1046), Dst Port: mapper-nodemgr (3984)

Trivial File Transfer Protocol

 

No.     Time        Source                Destination           Protocol Info

      5 0.001012    192.168.1.3           192.168.1.2           TFTP     Acknowledgement, Block: 0

 

Frame 5 (60 bytes on wire, 60 bytes captured)

Ethernet II, Src: 02:80:ad:20:31:b8 (02:80:ad:20:31:b8), Dst: Dell_a5:ba:ed (84:2b:2b:a5:ba:ed)

Internet Protocol, Src: 192.168.1.3 (192.168.1.3), Dst: 192.168.1.2 (192.168.1.2)

User Datagram Protocol, Src Port: mapper-nodemgr (3984), Dst Port: wfremotertm (1046)

Trivial File Transfer Protocol

QuoteReplyEditDelete

 

 

2011-07-28 22:45:13     Re: uBoot TFTP stopped working

Wojtek Skulski (UNITED STATES)

Message: 102706   

 

I repeated the same exercise a few times. uBoot keeps changing the Src ports in a random fashion in frame 3 (the one immediately after the ARP address resolution). I have seen port mao (2908), port nattyserver (3753), call-sig-trans (2517).

 

The TFTP server is nicer. It always responds from port wfremotertm (1046). So the TFTP session gets carried away from port 69 to a dialog between a random port proposed by the uBoot and port 1046, which seems to be the favorite port of the TFTP server.

 

I am using software setup which worked impeccably a month ago. I would have believed that M$ has screwed the TFTP server which is running under Windows, but how the uBoot? Both ends of the link are choosing not to use port 69.

 

It is weird...

QuoteReplyEditDelete

 

 

2011-07-29 03:13:22     Re: uBoot TFTP stopped working

Mike Frysinger (UNITED STATES)

Message: 102708   

 

the src port that u-boot uses should be irrelevant.  the only thing that matters is that the server is listening on the standard port 69 which u-boot attempts to contact.

QuoteReplyEditDelete

 

 

2011-07-30 20:09:05     Re: uBoot TFTP stopped working

Wojtek Skulski (UNITED STATES)

Message: 102732   

 

Hi, Mike.

 

Today I tried again with a different board. I used BlackStamp which is using a different uBoot and different MAC.  I reinstalled TFTP turbo and rebooted the Windows machine. The result is just the same. TFTP does not work. The SRC and Dst ports are again different. It tells me that either (a) there is a complete screwup somewhere, or (b) these ports do not matter and therefore the variables are not set and their content is indeed random.

 

I will attach the complete Wireshark record. The TFTP server is attempting to send the uImage file. There is a dialog between the BlackStamp board and the TFTP server. So the networking is working. These machines do see each other. However, the uImage sent by the TFTP server does not reach its destination.

 

I tried turning off the firewall, what is of course the first piece of advice if anything happens. There is an exception defined in the firewall for the tftpt.exe, but nevertheless I tried turning off the firewall. It did not help.

 

I am completely lost. This setup used to work very reliably. And now it does not. I have not changed anything that I know of. The fact that it does not work with two different boards tells me that the Blackfin side is OK.

 

Any suggestions will be welcome.  - Wojtek

 

Wireshark_BlackStamp.txt

QuoteReplyEditDelete

 

 

2011-08-01 00:01:27     Re: uBoot TFTP stopped working

Wojtek Skulski (UNITED STATES)

Message: 102737   

 

Mike:

 

I learned a few things. First, switching ports is normal for TFTP. No idea, why. But it is the way it is supposed to be.

 

2nd, the problem was narrowed down to the PC I am using. I swapped everything, including the network switch, router, and cables. Finally I connected my old laptop to the same network, changed the serverip to that machine, and bingo. UBoot downloaded the uImage on the first try, as it used to. (The laptop is fully configured for Blackfin development.)

 

It is mind boggling because: (a) It all used to work on the new machine. (b) I am using the same TFTP Turbo build on both machines. (c) Up to my knowledge, I did not touch this part of the setup for a month. It used to work back then.

Attachments

    Outcomes