From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=134.134.136.24; helo=mga09.intel.com; envelope-from=siyuan.fu@intel.com; receiver=edk2-devel@lists.01.org Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) (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 C160B21FC7477 for ; Sun, 8 Oct 2017 18:54:52 -0700 (PDT) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Oct 2017 18:58:18 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.42,498,1500966000"; d="scan'208";a="144218885" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by orsmga002.jf.intel.com with ESMTP; 08 Oct 2017 18:58:18 -0700 Received: from fmsmsx156.amr.corp.intel.com (10.18.116.74) by fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sun, 8 Oct 2017 18:58:06 -0700 Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by fmsmsx156.amr.corp.intel.com (10.18.116.74) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sun, 8 Oct 2017 18:58:06 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.213]) by SHSMSX152.ccr.corp.intel.com ([169.254.6.93]) with mapi id 14.03.0319.002; Mon, 9 Oct 2017 09:58:02 +0800 From: "Fu, Siyuan" To: Vabhav Sharma , "edk2-devel@lists.01.org" Thread-Topic: MTFTP file transfer timeout error Thread-Index: AdMziPrTGH6+Na2GSdiTFpRwROFIcwA0L1PgAPyz/iABa4zI4ACpChdg Date: Mon, 9 Oct 2017 01:58:02 +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: Mon, 09 Oct 2017 01:54:52 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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]=20 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=20 -Not sending 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