* [U-Boot-Users] tftp errors/times out on large files
@ 2006-08-14 17:03 mitsy
2006-08-14 18:11 ` Andrew Dyer
2006-08-14 22:25 ` Tolunay Orkun
0 siblings, 2 replies; 7+ messages in thread
From: mitsy @ 2006-08-14 17:03 UTC (permalink / raw)
To: u-boot
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!
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot-Users] tftp errors/times out on large files
2006-08-14 17:03 [U-Boot-Users] tftp errors/times out on large files mitsy
@ 2006-08-14 18:11 ` Andrew Dyer
2006-08-14 22:25 ` Tolunay Orkun
1 sibling, 0 replies; 7+ messages in thread
From: Andrew Dyer @ 2006-08-14 18:11 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot-Users] tftp errors/times out on large files
@ 2006-08-14 20:07 mitsy
0 siblings, 0 replies; 7+ messages in thread
From: mitsy @ 2006-08-14 20:07 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot-Users] tftp errors/times out on large files
2006-08-14 17:03 [U-Boot-Users] tftp errors/times out on large files mitsy
2006-08-14 18:11 ` Andrew Dyer
@ 2006-08-14 22:25 ` Tolunay Orkun
2006-08-15 15:53 ` mitsy
1 sibling, 1 reply; 7+ messages in thread
From: Tolunay Orkun @ 2006-08-14 22:25 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot-Users] tftp errors/times out on large files
2006-08-14 22:25 ` Tolunay Orkun
@ 2006-08-15 15:53 ` mitsy
2006-08-15 17:13 ` Jerry Van Baren
0 siblings, 1 reply; 7+ messages in thread
From: mitsy @ 2006-08-15 15:53 UTC (permalink / raw)
To: u-boot
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
>
>
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot-Users] tftp errors/times out on large files
2006-08-15 15:53 ` mitsy
@ 2006-08-15 17:13 ` Jerry Van Baren
0 siblings, 0 replies; 7+ messages in thread
From: Jerry Van Baren @ 2006-08-15 17:13 UTC (permalink / raw)
To: u-boot
> 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot-Users] tftp errors/times out on large files
@ 2006-08-15 19:29 mitsy
0 siblings, 0 replies; 7+ messages in thread
From: mitsy @ 2006-08-15 19:29 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2006-08-15 19:29 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-08-14 17:03 [U-Boot-Users] tftp errors/times out on large files mitsy
2006-08-14 18:11 ` Andrew Dyer
2006-08-14 22:25 ` Tolunay Orkun
2006-08-15 15:53 ` mitsy
2006-08-15 17:13 ` Jerry Van Baren
-- strict thread matches above, loose matches on Subject: below --
2006-08-14 20:07 mitsy
2006-08-15 19:29 mitsy
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox