[U-Boot-Users] tftp errors/times out on large files

[Jerry Van Baren]

> On 8/14/06, Tolunay Orkun <listmember at orkun.us> wrote:
>> mitsy wrote:
>>> Hi all,
>>>
>>> I am having problem tftping large files (>30M.) The tftp will start
>>> download, and then immediately get an error, and it will say:
>>> (snip)
>>> and repeat. I can download smaller files just fine. What could it be
>>> the problem? Increasing the MALLOC_LEN doesn't seem to help, and I
>>> need some advice. (FYI, I have 128M ram.)
>>>
>>> Any suggestions will be greatly appreciated!
>> The original TFTP protocol is limited to file sizes of 32MB. A later RFC
>>   compliant TFTP allows file sizes of up to 4GB but I am not sure if
>> U-Boot and/or your TFTP server implements the new RFC. Details are in
>> Wikipedia.
>>
>> http://en.wikipedia.org/wiki/Trivial_File_Transfer_Protocol
>
> mitsy wrote:
>> Thank you Tolunay. Since nfs isn't an option for what I'm doing (as
>> Andrew suggested yesterday,) I think I need to either add gzip
>> decompression support and/or modify tftp to support larger files.

FWIIW, most of the problem is because the authors of the RFC apparently 
didn't contemplate more than 64K data packets and so did not describe 
handling sequence number overflow/wrap around.

RFC-1350 p.3 Section 4 (first paragraph) states:
"Each data packet has associated with it a block number; block numbers 
are consecutive and begin with one. Since the positive response to a 
write request is an acknowledgment packet, in this special case the 
block number will be zero."

The above is somewhat ambiguous (to me) whether the wrap-around should 
wrap to zero (0) or one (1).  If you decide it should be zero (0), see
   <http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=23725>

FWIIW, ARINC-615A aircraft data loader has specified it to wrap to one (1).
   <https://www.arinc.com/cf/store/catalog_detail.cfm?item_id=71>

Perhaps you (mitsy) should write a RFC to superceed 1350 to fix the 
problem.  Here is your chance to be famous!

Most (buggy) implementations use a 32 bit (default) integer as the local 
variable and don't address the wrap-around issue, so the local variable 
goes from 65535 to 65536 while the block number in the packet goes from 
65535 to 0 (buggy or wrap-to-zero implementation) or 65535 to 1 
(wrap-to-one implementation).

When we addressed this problem (several years ago), we found a couple of 
TFTP clients that support wrap-around on the block numbers, but it has 
been a long time since I looked at this and I cannot find the 
information any more. :-(

gvb