[U-Boot-Users] tftp errors/times out on large files
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!
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.
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.
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.
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.
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
participants (4)
-
Andrew Dyer -
Jerry Van Baren -
mitsy -
Tolunay Orkun