cURL / Mailing Lists / curl-library / Single Mail

curl-library

libcurl tftp problem with large files

From: NCarolina 350 <ncarolina350_at_gmail.com>
Date: Thu, 6 Aug 2009 13:21:09 -0400

Hi,
This is a followup to my message last week. The tftp client in libcurl
7.19.5 does not transfer files larger than 32MB correctly. After some
investigation, I found:
1. The default block size libcurl uses is 512 bytes and the block number in
the protocol is represented with 2 bytes.
2. When the rollover from block 0xFFF to 0x0 occurs, the new block is
discarded as being a duplicate. However, the rest of the blocks are
retrieved normally because the number of the last block received is reset
back to 0 (probably, not intentionally).

My first attempt was to use the option negotiation and oack (RFCs 2347 and
2348) to re-negotiate the block size if the file is too large to retrieve.
Unfortunately, the server side (tftp-hpa) acknowledges, but ignores the
re-negotiation and goes on w/ 512-byte packets. Moreover, the RFCs are
written vaguely -- I can't determine if re-negotiating is allowed or not.
Even if it is, it is not obvious what the sequence should be (see:
http://www.faqs.org/rfcs/rfc2347.html)

I traced busybox tftp and found out it rolls over to 0 when the count
reaches FFFF. The curl-7.19.5-rollover.patch attached implements the same
using a block mask. I ran the tests and passed. Note though, my
configuration ran 483 tests since I have some features disabled due to lack
of library support etc. All tftp tests passed. This patch corrects the large
file problem.

I also thought we could make better use of the option negotiation. In the
curl-7.19.5-desired.patch, I introduced a constant (desired block size =
1428). The client can now ask for blocks of 1428 bytes to the server. If the
server doesn't like or support the blksize option, we preserve the current
behavior -- 512 byte packets. This patch passed the tests too. I understand
there's a user option (CURLOPT_TFTP_BLKSIZE) so this second patch might not
be accepted. My thinking was the default case can be improved... but I don't
have a problem if you say "leave that decision to the user".

I apologize for the long message. Just wanted to make sure I captured
everything :)
kursad

Received on 2009-08-06