From a8c9e4613c18d8f754f8c731bf67b5c540e00ae0 Mon Sep 17 00:00:00 2001 From: rodrigc Date: Sun, 31 Jul 2011 03:18:36 +0000 Subject: Pull in some wording to the tftpd.8 man page from NetBSD, with some slight changes: ========================================================================================= http://cvsweb.netbsd.org/bsdweb.cgi/src/libexec/tftpd/tftpd.8?only_with_tag=MAIN#rev1.22 Revision 1.22 or diffs], Fri Jan 8 21:05:14 2010 UTC (18 months, 2 weeks ago) by christos Patrick Welche - add -p pathsep option - make wrap to zero work, but produce a warning While here: - fix gcc warnings, in particular variable clobbered warnings (compiling with fewer warnings does not really fix the problem) ========================================================================================= These wording changes clarify the default rollover behavior as a "kludge". Also, the block numbers and octet counts for 65535 blocks and 32767 blocks are more accurate than the existing documented numbers. Requested by: Pawan Gupta Obtained from: Juniper Networks Approved by: re (kib) --- libexec/tftpd/tftpd.8 | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/libexec/tftpd/tftpd.8 b/libexec/tftpd/tftpd.8 index 96bd24c..7c3da08 100644 --- a/libexec/tftpd/tftpd.8 +++ b/libexec/tftpd/tftpd.8 @@ -300,8 +300,15 @@ and .Xr tftp 1 code to support RFC2348. .Sh NOTES -Files larger than 33488896 octets (65535 blocks) cannot be transferred -without client and server supporting the TFTP blocksize option (RFC2348), +Files larger than 33,553,919 octets (65535 blocks, last one <512 +octets) cannot be correctly transferred without client and server +supporting blocksize negotiation (RFCs 2347 and 2348), or the non-standard TFTP rollover option. +As a kludge, +.Nm +accepts a sequence of block number which wrap to zero after 65535, +even if the rollover option is not specified. .Pp -Many tftp clients will not transfer files over 16744448 octets (32767 blocks). +Many tftp clients will not transfer files over 16,776,703 octets +(32767 blocks), as they incorrectly count the block number using +a signed rather than unsigned 16-bit integer. -- cgit v1.1