From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=192.55.52.43; helo=mga05.intel.com; envelope-from=siyuan.fu@intel.com; receiver=edk2-devel@lists.01.org Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 82E42208F7903 for ; Mon, 9 Oct 2017 17:57:49 -0700 (PDT) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga105.fm.intel.com with ESMTP; 09 Oct 2017 18:01:16 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.42,502,1500966000"; d="scan'208";a="1204051632" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by fmsmga001.fm.intel.com with ESMTP; 09 Oct 2017 18:01:16 -0700 Received: from fmsmsx113.amr.corp.intel.com (10.18.116.7) by fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 9 Oct 2017 18:01:16 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by FMSMSX113.amr.corp.intel.com (10.18.116.7) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 9 Oct 2017 18:01:15 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.213]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.98]) with mapi id 14.03.0319.002; Tue, 10 Oct 2017 09:01:14 +0800 From: "Fu, Siyuan" To: Vabhav Sharma CC: "edk2-devel@lists.01.org" Thread-Topic: MTFTP file transfer timeout error Thread-Index: AdMziPrTGH6+Na2GSdiTFpRwROFIcwA0L1PgAPyz/iABa4zI4ACpChdgABoBtwAAFtL1cA== Date: Tue, 10 Oct 2017 01:01:14 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.0.116 dlp-reaction: no-action x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Subject: Re: MTFTP file transfer timeout error X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 00:57:49 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Vabhav Yes the IP layer should discard the whole packet if any frame is lost durin= g the transmit. Large TFTP blksize will reduce the the number of TFTP data/= ack packets, but add more overhead and risk of IP fragmentation and reassem= bly.=20 BestRegards Fu Siyuan -----Original Message----- From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Vabh= av Sharma Sent: Tuesday, October 10, 2017 1:13 AM To: Fu, Siyuan Cc: edk2-devel@lists.01.org Subject: Re: [edk2] MTFTP file transfer timeout error 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 f= ragment 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() di= dn't receive more packets with status as 'EFI_NOT_READY' with <>TFTP Server keeps on sending data(23 fragments) block 'x+1'(900) expectin= g 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 onc= e MnpReceivePacket() status is set to 'EFI_NOT_READY' causing timeout. Is this expected if one frame is dropped at Ethernet Layer than whole packe= t will be discarded at IP layer? Regards, Vabhav -----Original Message----- From: Fu, Siyuan [mailto:siyuan.fu@intel.com]=20 Sent: Monday, October 09, 2017 7:28 AM To: Vabhav Sharma ; 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 pa= cket will be retransmitted 6 times before the code goes to the Mtftp4CleanO= peration() you marked below. The MTFTP driver always saves the last transmi= tted 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 whol= e 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 increa= se 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 us= e 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 =3D Mtftp4RrqHandleData (Instance, Packet, Len, Multicast, &Com= pleted); break; BestRegards Fu Siyuan -----Original Message----- From: Vabhav Sharma [mailto:vabhav.sharma@nxp.com] Sent: Friday, October 6, 2017 1:26 AM To: Fu, Siyuan ; 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 u= sing 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 shel= lpkg library. There seems to be issue(corruption) with tfp client state machine -Not send= ing ACK for received data blocks -Sending duplicate ACK If server don't receive ACK, It stops sending data packets and timeout occu= rs 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-bounces@lists.01.org] On Behalf Of Vabh= av Sharma Sent: Thursday, September 28, 2017 5:04 PM To: siyuan.fu@intel.com Cc: edk2-devel@lists.01.org; edk2-devel Subject: Re: [edk2] MTFTP file transfer timeout error [This sender failed our fraud detection checks and may not be who they appe= ar 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 2be= 45bfe2779043bc3566e879e7ec279412012dc. Could you please help me clarify with the timeout error behavior observed i= n previous mail Please note the behavior varies for different file type(Attached sheet) Reg= ards, Vabhav -----Original Message----- From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Vabh= av Sharma Sent: Saturday, September 23, 2017 4:21 PM To: edk2-devel@lists.01.org; edk2-devel Subject: [edk2] MTFTP file transfer timeout error [This sender failed our fraud detection checks and may not be who they appe= ar 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 -i = 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 f= ile 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 an= yone faced such issue? I assume expectation is to use any blocksize from 51= 2(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