[BusyBox] tftp quits after 33553920 bytes

[tom at ceisystems.com]

Hello all,

	TFTP is not a sequential protocol _only_ when using the
multicast protocol, and even then it is still partially sequential.  If
you read the MultiCast extension RFC, you will notice that clients are
allowed to re-request a particular block (or any of a series of blocks)
they may require to complete their transfer.  Once this client has
completed said transfer, it sends a final ACK to the server, which then
looks for the next "Master Client".

	Implementations of TFTP that are operating in UniCast mode, and
wrap the counter value are perfectly compliant with the RFC.  The TFTP
protocol RFC states that a client ACKS packets as they are received,
meaning the next packet is not transferred until the previous is
acknowledged.  If you really wanted to, you could simply use the
sequence 0,1 and 2 for packet acknowledgement (even though there would
be no clear benefit).

	I am going to look at the TFTP server and client code now, and
see if I can make heads or tails of it.  Good luck.

Thomas Cameron
CEI Systems, Inc.


> -----Original Message-----
> From: Stewart Brodie [mailto:stewart.brodie at pace.co.uk] 
> Sent: Thursday, May 01, 2003 5:14 AM
> To: busybox at busybox.net
> Subject: Re: [BusyBox] tftp quits after 33553920 bytes
> 
> 
> In message <20030430192706.R1856 at brecis.com>
>           Steve Wahl <swahl at brecis.com> wrote:
> 
> > On Thu, May 01, 2003 at 02:18:00AM +0200, Wolfgang Denk wrote:
> > > In message 
> <432296A5CDF78D4FA6B47869124755FBCF187F at communicator.troikanet
> works.com> you wrote:
> > > > version: 0.60.5
> > > > 
> > > > tftp times out with the message:
> > > > 	tftp: timeout
> > > > 	tftp: last timeout
> > > > 
> > > > after transferring 33553920 bytes.
> > > > 
> > > > Is this a known issue? 
> > > 
> > > It's a limitation of the TFTP protocol which uses a  16  
> bit  counter
> > > for data block of 512 bytes each.
> > > 
> > > You cannot transfer files bigger than 32 MB using TFTP.
> > 
> > That is incorrect.
> 
> It is incorrect (but not for the reason you gave :-)
> 
> To transfer more than 32MB, you need a client and server 
> which both honour
> the blksize extension.  In that way, your client can request 
> blocks larger
> than the default 512 bytes.
> 
> > Lots of implementations just let the counter wrap like TCP 
> does with its 16
> > bit counter.  The specification does not say that this is 
> not allowed.
> 
> Such implementations are broken.  The ACK messages are used 
> to request the
> next block.  i.e. ACKing block 2 is always a request for 
> block 3, not block
> 65539.
> 
> TFTP is not necessarily a sequential protocol, particularly 
> when you are
> using the multicasting extensions.  If you are using the 
> tsize extension,
> then clients can speculatively send ACKs for blocks it hasn't actually
> received yet to try and counter round-trip delays (because it 
> can make sure
> that it doesn't accidentally ACK the last block).  If you are 
> using the
> multicast extensions, you need to ACK arbitrary blocks to 
> fill in holes in
> the image that you are missing once you become the master client.
> 
> 
> -- 
> Stewart Brodie, Senior Software Engineer, available from the 
> end of June
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://busybox.net/mailman/listinfo/busybox
>