> > Have you tried 5.10 in your environment on a BIOS machine to see whether > that works and which port numbers it uses? > > -- > Matt Fleming, Intel Open Source Technology Center >Hi Matt, I think I've found the problem. In /core/fs/pxe/tftp.c in function tftp_open: First you do a core_udp_connect to port 69 (TFTP) at line 264. -> source port = x After that you sent the filerequest at line 265 You receive the fileinfo and also the used port (y) for the transfer in line 273 Than you perform a core_udp_disconnect at line 286 Now you perform a new core_udp_connect to port y which set the source port to x + 1 at line 287 for example: Client | Server TFTP get file 2900 > 69 Response tsize 2900 < 7012 ACK blk 0 2901 > 7012 <-- wrong source port Now the TFTP is failing, because he expect the filetransfer client port as the same as the initial filerequest. Maybe that help to solve the problem Regards Michael
On Tue, 25 Jun, at 01:51:52PM, Michael Szerencsits wrote:> Hi Matt, > > I think I've found the problem.Thanks for doing this analysis.> In /core/fs/pxe/tftp.c in function tftp_open: > First you do a core_udp_connect to port 69 (TFTP) at line 264. -> source port = x > After that you sent the filerequest at line 265 > You receive the fileinfo and also the used port (y) for the transfer in line 273 > Than you perform a core_udp_disconnect at line 286 > Now you perform a new core_udp_connect to port y which set the source port to x + 1 at line 287 > > for example: > Client | Server > TFTP get file 2900 > 69 > Response tsize 2900 < 7012 > ACK blk 0 2901 > 7012 <-- wrong source port > > Now the TFTP is failing, because he expect the filetransfer client port as the same as the initial filerequest.Isn't the server complaining because port 7012 is unreachable? Not the other way around? It really doesn't matter to the server what the value of the source port is from the client. Looking at your network packet dump from a previous email, Source Destination Protocal SPort DPort Description 10.0.0.100 10.0.0.1 tftp 1479 69 Read Request:File /syslinux/ldlinux.e32, Transfer type: octet, tsize\000=0\000,blksize\000=1408\000 10.0.0.1 10.0.0.100 tftp 7018 1479 Option Acknoledgment, tsize\000=117160\000, blksize\000=1408\000 10.0.0.100 10.0.0.1 udp 1480 7018 Source port:1480 Destination port: 7018 The client is trying to connect to port 7018 on the server, but the server responds with... 10.0.0.1 10.0.0.100 icmp Destination unreachable (Port unreachable) because a connection cannot be made to port 7018 on 10.0.0.1. No? -- Matt Fleming, Intel Open Source Technology Center
> Isn't the server complaining because port 7012 is unreachable? Not the > other way around? It really doesn't matter to the server what the value > of the source port is from the client. > > Looking at your network packet dump from a previous email, > > Source Destination Protocal SPort DPort Description > 10.0.0.100 10.0.0.1 tftp 1479 69 Read Request:File /syslinux/ldlinux.e32, Transfer type: octet, tsize\000=0\000,blksize\000=1408\000 > 10.0.0.1 10.0.0.100 tftp 7018 1479 Option Acknoledgment, tsize\000=117160\000, blksize\000=1408\000 > 10.0.0.100 10.0.0.1 udp 1480 7018 Source port:1480 Destination port: 7018 > > > The client is trying to connect to port 7018 on the server, but the > server responds with... > > > 10.0.0.1 10.0.0.100 icmp Destination unreachable (Port unreachable) > > > because a connection cannot be made to port 7018 on 10.0.0.1. No? > > -- > Matt Fleming, Intel Open Source Technology Center >Hi Matt, the server is listening on the port. I reviewed the RFC for TFTP and it say that the server would response with an error if the source TID is not correct: 1. Host A sends a "RRQ" or "WRQ" to host B with source= A's TID, destination= 69. 2. Host B sends a "ACK" (with block number= 0) to host A with source= B's TID, destination= A's TID. At this point the connection has been established and the first data packet can be sent by Host A with a sequence number of 1. In the next step, and in all succeeding steps, the hosts should make sure that the source TID matches the value that was agreed on in steps 1 and 2. If a source TID does not match, the packet should be discarded as erroneously sent from somewhere else. An error packet should be sent to the source of the incorrect packet, while not disturbing the transfer. I also review how you do this for BIOS mode, but there you use a other methode (re_connect with different source port) Regards Michael