topic Re: tftp in Operating System - Linux

tftp

all star — Wed, 21 Mar 2007 10:27:39 GMT

Hi,

how to increase tftp file transfer size.

i believe in linux default size limit is 32MB. i would like to increase it to higher value

Re: tftp

all star — Wed, 21 Mar 2007 16:26:16 GMT

i'm using atftpd 0.7

Re: tftp

Matti_Kurkela — Wed, 21 Mar 2007 17:46:36 GMT

The limit is in the basic TFTP protocol specification, as defined by RFC1350.

The TFTP specification was later enhanced by RFC2347, RFC2348, and RFC2349. Looks like atftpd already supported these enhancements back in year 2000. So, your server is probably ready for larger files, unless you've disabled the support with --no-tsize and --no-blksize options.

Now you only need to get the clients to understand and use these enhancements.

Re: tftp

Stuart Browne — Wed, 21 Mar 2007 17:48:47 GMT

After reading through all the available documentation of 'atftpd', there are no references to file size limits, nor any bug reports of limits.

There's no "linux" limit of 32M transfer limit. There's also no limits defined in the 'tftp' RFC.

The only thing I can think of that would be creating such a limit would be the timeout's for the read/write's due to network latency.

Re: tftp

Matti_Kurkela — Tue, 27 Mar 2007 18:48:00 GMT

The limit of 32MB comes from the overflow of the TFTP block number counter. It is not explicitly mentioned in the RFC1350, but will be obvious when you examine the protocol.

The original block size of the TFTP protocol is 512 bytes, and the block number field in the protocol is only 2 octets long (values can be 0-65535).

This forms the limit:
65536 x 512 bytes = exactly 32 MB.

As TFTP uses UDP as a transfer protocol, the block number is the only thing that makes the data packets uniquely identifiable, so that the receiver can detect if the packet order is scrambled in the network.

If the sender allows the block number to wrap around, the expected behavior at the receiver end would be to discard the "new block 0" as an out-of-order packet, as a block 0 is already received.

Allowing the wrap-around would also make it impossible to uniquely identify the packets, which might cause problems if the packets can be duplicated and/or delayed by IP routing changes.

The basic protocol of RFC1350 has no provisions for negotiating a larger block size: the option negotiation mechanism was described in RFC2347, and the blocksize option in RFC2348.

The maximum blocksize allowed by RFC2348 is 65464 octets (bytes).

The new limit would be:
65536 x 65464 bytes = almost 4 GB.

See for yourself if you don't believe me:
http://rfc.net/rfc1350.html
http://rfc.net/rfc2348.html

Re: tftp

Stuart Browne — Tue, 27 Mar 2007 20:01:06 GMT

Ahh, I missed the block-number limit.