public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Vabhav Sharma <vabhav.sharma@nxp.com>
To: "siyuan.fu@intel.com" <siyuan.fu@intel.com>
Cc: "edk2-devel@lists.01.org" <edk2-devel@lists.01.org>
Subject: Re: MTFTP file transfer timeout error
Date: Mon, 9 Oct 2017 17:12:49 +0000	[thread overview]
Message-ID: <DB4PR04MB29920359C1078C6B3AD2AD1F3740@DB4PR04MB299.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <B1FF2E9001CE9041BD10B825821D5BC58B3C775C@SHSMSX103.ccr.corp.intel.com>

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.fu@intel.com] 
Sent: Monday, October 09, 2017 7:28 AM
To: Vabhav Sharma <vabhav.sharma@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.sharma@nxp.com]
Sent: Friday, October 6, 2017 1:26 AM
To: Fu, Siyuan <siyuan.fu@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-bounces@lists.01.org] On Behalf Of Vabhav Sharma
Sent: Thursday, September 28, 2017 5:04 PM
To: siyuan.fu@intel.com
Cc: edk2-devel@lists.01.org; edk2-devel <edk2-devel-bounces@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-bounces@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-bounces@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


  reply	other threads:[~2017-10-09 17:09 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-22 10:10 MTFTP file transfer timeout error Vabhav Sharma
2017-09-23 10:50 ` Vabhav Sharma
2017-09-28 11:34   ` Vabhav Sharma
2017-09-28 11:36     ` FW: " Vabhav Sharma
2017-10-05 17:25     ` Vabhav Sharma
2017-10-06 12:06       ` Sakar Arora
2017-10-09  1:58       ` Fu, Siyuan
2017-10-09 17:12         ` Vabhav Sharma [this message]
2017-10-10  1:01           ` Fu, Siyuan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DB4PR04MB29920359C1078C6B3AD2AD1F3740@DB4PR04MB299.eurprd04.prod.outlook.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox