[BusyBox] tftp quits after 33553920 bytes

[Stewart Brodie]

Steve Wahl wrote:
> On Thu, May 01, 2003 at 10:13:52AM +0100, Stewart Brodie wrote:
>> In message <20030430192706.R1856 at brecis.com>
>>           Steve Wahl <swahl at brecis.com> wrote:
>>
>>> 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.
>
> Is RFC 1350 Obsoleted?  I could not find an indication that it was...

Not as far as I know, only updated by the various option extensions.

> It specifically says that TFTP is a lock step protocol.  "This
> protocol is very restrictive, in order to simplify implementation.
> For example, the fixed length blocks make allocation straight forward,
> and the lock step acknowledgement provides flow control and eliminates
> the need to reorder incoming data packets."  Also, "The sender has to
> keep just one packet on hand for retransmission, since the lock step
> acknowledgment guarantees that all older packets have been received."
>
> Nowhere does it say that the block number cannot wrap.
[snip: we both agree that multicasting is a special case]
> Show me otherwise, if you will...

It does not mention the word wrap, but ...

Section 4 says that block numbers are consecutive and begin with one.
Section 5 says that block numbers start at one and increase by one for each
new block.  The transition from 65535 to zero breaks both of those
constraints.

Section 4 also says that ACKs for block 0 are a special case for response to
WRQ packets, but I concede that it does not say that that is their *only*
use (and indeed the multicast extensions do use ACK #0 to respond to OACK
messages).

If you are going to wrap the number, how do you satisfy "the block numbers
on data packets begin with one and increase by one for each new block of
data.  This restriction allows the program to use a single number to
discriminate between new packets and duplicates."   A long lost packet might
have been winging around the network and finally arrive just at the wrong
time and mess up the transfer.

>> 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).
>
> As I read it, this is valid only under the multicast extensions.

On reflection, I think I disagree with myself.  I don't think it's valid at
all except for non-master clients in the multicast case acking the last
block once they have a complete image.  In some closed environments where
the client & server software are both tightly controlled, it might be a
worthwhile enhancement.  Then again, there's lots of rules you can bend in
such environments if you are careful.

--Stewart