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

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

[mitsy]

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:

Load address: 0x80100000
Loading: *
TFTP error: 'Undefined error code' (0)
Starting again

or sometimes I get the 'T' (timeout) and it will repeat again.

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!

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

[Andrew Dyer]

On 8/14/06, mitsy <mitsy12@gmail.com> 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:

the TFTP protocol has a file size limit of 32M unless one of the later
RFC versions is followed.  Try configuring/using NFS instead.

-- 
Hardware, n.:
        The parts of a computer system that can be kicked.

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

[Tolunay Orkun]

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

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

[mitsy]

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.



On 8/14/06, Tolunay Orkun <listmember@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
>
>
>

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

[Jerry Van Baren]

> On 8/14/06, Tolunay Orkun <listmember@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

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

[mitsy]

Andrew,

Thank you so much for the help as always. I was wondering why it works
with nfs but not tftp, if it was a memory issue.

Mitsy

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

[mitsy]

Jerry,

It looks like Redboot's tftp client and atftp's client both support
large files. I am planning on studying up their code and see what they
are doing.

Thank you very much for the informative comment.