tftp

[all star]

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

[all star]

i'm using atftpd 0.7

[Matti_Kurkela]

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.

[Stuart Browne]

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.

[Matti_Kurkela]

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

[Stuart Browne]

Ahh, I missed the block-number limit.