Hi Fu Siyuan, Thank you for explanation and hope you enjoyed vacation. I am using 32K block size for file transfer. IP layer divides the 32K block size into 23 number of fragments(with last fragment of less size indicating no more fragments)
Using tcpdump and debug code the flow is: NIC interface receives 23 fragments and pass it to upper layer. Mtftp4 Client receives the data block 'x' with expected block number 'x+1' Mtftp4 Client Sends ACK for received data block 'x' After receiving approximate 900x block, NIC interface receive 22 fragments instead of 23(One packet drop),At this point function MnpReceivePacket() didn't receive more packets with status as 'EFI_NOT_READY' with <>TFTP Server keeps on sending data(23 fragments) block 'x+1'(900) expecting ACK for data block 'x+1'(900),Whereas <>Mtftp4 Client retransmit acknowledgement six times for data block 'x'(899) before going to timeout expecting next data block 'x+1'(900). Added debug logs in the below code and Mtft4 client didn't receive data once MnpReceivePacket() status is set to 'EFI_NOT_READY' causing timeout. Is this expected if one frame is dropped at Ethernet Layer than whole packet will be discarded at IP layer? Regards, Vabhav -----Original Message----- From: Fu, Siyuan [mailto:siyuan...@intel.com] Sent: Monday, October 09, 2017 7:28 AM To: Vabhav Sharma <vabhav.sha...@nxp.com>; edk2-devel@lists.01.org Subject: RE: MTFTP file transfer timeout error Hi, Vabhav Sorry for the late response, I just came back from the vacation. The default retry count for tftp shell command is 6, which means the ACK packet will be retransmitted 6 times before the code goes to the Mtftp4CleanOperation() you marked below. The MTFTP driver always saves the last transmitted packet in Instance->LastPacket, and the Mtftp4Retransmit() will try to retransmit it if not reach the max retry count. As you mentioned 1K block size is always success, I guess it's may because the IP fragment. A MTFTP(UDP) packet which is larger than 1.5K (the default MTU) will be fragmented to several IP frame. During the transmit, the whole UDP packet will be discarded by the IP layer if any of the IP fragment is lost in the network. As a result, using large MTFTP block size will increase the possibility of timeout in bad network connection. I suggest you add some debug in Mtftp4RrqInput() in below lines to confirm if the EFI client can receive the MTFTP packet correctly, also you could use Wireshark in your server to check whether it receives the ACK from client. switch (Opcode) { case EFI_MTFTP4_OPCODE_DATA: if ((Len > (UINT32) (MTFTP4_DATA_HEAD_LEN + Instance->BlkSize)) || (Len < (UINT32) MTFTP4_DATA_HEAD_LEN)) { goto ON_EXIT; } Status = Mtftp4RrqHandleData (Instance, Packet, Len, Multicast, &Completed); break; BestRegards Fu Siyuan -----Original Message----- From: Vabhav Sharma [mailto:vabhav.sha...@nxp.com] Sent: Friday, October 6, 2017 1:26 AM To: Fu, Siyuan <siyuan...@intel.com>; edk2-devel@lists.01.org Subject: RE: MTFTP file transfer timeout error Dear Experts, I traced that timeout error for different block size during file transfer using tftp(rrq opcode) is returned from function Mtftp4OnTimerTick() TFTP layer in UEFI network stack. Mtftp4OnTimerTick() // // Retransmit the packet if haven't reach the maxmium retry count, // otherwise exit the transfer. // if (++Instance->CurRetry < Instance->MaxRetry) { Mtftp4Retransmit (Instance); Mtftp4SetTimeout (Instance); } else { Mtftp4CleanOperation (Instance, EFI_TIMEOUT); //Timeout is set continue; } Once this is set, It gets populated to downloadfile() function in tftp shellpkg library. There seems to be issue(corruption) with tfp client state machine -Not sending ACK for received data blocks -Sending duplicate ACK If server don't receive ACK, It stops sending data packets and timeout occurs after maximum retry. Please suggest if this is new or known issue to be fixed? Regards, Vabhav -----Original Message----- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Vabhav Sharma Sent: Thursday, September 28, 2017 5:04 PM To: siyuan...@intel.com Cc: edk2-devel@lists.01.org; edk2-devel <edk2-devel-boun...@lists.01.org> Subject: Re: [edk2] MTFTP file transfer timeout error [This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing] Hello Fu Siyuan, I see that blocksize option with tftp command is introduced with commit 2be45bfe2779043bc3566e879e7ec279412012dc. Could you please help me clarify with the timeout error behavior observed in previous mail Please note the behavior varies for different file type(Attached sheet) Regards, Vabhav -----Original Message----- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Vabhav Sharma Sent: Saturday, September 23, 2017 4:21 PM To: edk2-devel@lists.01.org; edk2-devel <edk2-devel-boun...@lists.01.org> Subject: [edk2] MTFTP file transfer timeout error [This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing] Hi All, I am facing timeout error with file transfer using tftp on UEFI shell with ARM based SoCs Command used: tftp -s <blocksize> -i <interface> <server ip> <filename> File transfer with file size greater 50 or 60 MB is returning timeout(Also depends on type of file like data file, ASCII file, boot sector) I verified by playing around with blocksize from 32K to 42K for different file size(100MB,200MB,500MB) and identify that increasing the block size for large file size helps with successful transfer. File transfer is always successful with 1K blocksize but file transfer time is increased. Please suggest if there is any link between block size with file size or anyone faced such issue? I assume expectation is to use any blocksize from 512(default) to 64K. Regards, Vabhav _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
