Re: tftp protocol

[Havard Eidnes <he%uninett.no@localhost>]

> On Wed, Oct 14, 2009 at 04:01:13PM +0100, Patrick Welche wrote:
> > Looks like tsize negotiation - it looks as though the client sends tsize 0
> > with the RRQ, then our opcode 6(?) offers a large tsize which client
> > responds to with an error, then the client sends a RRQ with tsize 0, blksize
> > 1420, and the server replies with opcode 6 blksize 1420 and the same large
> > tsize as before. Block number is bound to roll over in this particular
> > large file case...
>
> and of course this is all described in the fine manual:
>
> BUGS
>      Files larger than 33488896 octets (65535 blocks) cannot be transferred
>      without client and server supporting blocksize negotiation (RFCs 2347 and
>      2348).

Actually...  I suspect that the BUGS statement is in actual fact
wrong, if it implies that the protocol spec makes it impossible
to transfer files larger than 32MiB using tftp with the default
block size of 512 bytes.  I've experienced that same problem,
when trying to tftp updates for Cisco wireless controllers, which
also have image files larger than 32MiB.

Cisco's "fix" for this problem is to point to a particular
implementation of tftp daemon functionality in the form of a
Windows program (yuk!) (and, yes, the source is available as
well, but it has Windows-specific code littering the code, if I
recall correctly).  The tftp client in the Cisco case uses the
default block size of 512 bytes, and with this combination, it
can actually transfer the wireless controller image file.

The "block numbers" in the tftp protocol are actually not
designed to do "random access" in the server-side file, it's
designed to distinguish between duplicate blocks and new blocks
at the client.  If the client and server implements a 0.5 * 2^16
"block number window", and they allow the block number to wrap
around the 2^16 mark, it may actually work to transfer files
larger than 32MiB without increasing the block size above the
default 512 bytes.

The RFCs specifying the block size extension mention speed as a
motivation for the extension, not the ability to transfer files
larger than 32MiB...

I've not actually had the time to sit down to see if a patch
could be made to the NetBSD tftp daemon (and client) to allow
such operation.


Regards,

- Håvard