1994-05-27 12:39:25 +00:00
|
|
|
.\" Copyright (c) 1983, 1991, 1993
|
|
|
|
|
.\" The Regents of the University of California. All rights reserved.
|
|
|
|
|
.\"
|
|
|
|
|
.\" Redistribution and use in source and binary forms, with or without
|
|
|
|
|
.\" modification, are permitted provided that the following conditions
|
|
|
|
|
.\" are met:
|
|
|
|
|
.\" 1. Redistributions of source code must retain the above copyright
|
|
|
|
|
.\" notice, this list of conditions and the following disclaimer.
|
|
|
|
|
.\" 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
|
.\" notice, this list of conditions and the following disclaimer in the
|
|
|
|
|
.\" documentation and/or other materials provided with the distribution.
|
|
|
|
|
.\" 3. All advertising materials mentioning features or use of this software
|
|
|
|
|
.\" must display the following acknowledgement:
|
|
|
|
|
.\" This product includes software developed by the University of
|
|
|
|
|
.\" California, Berkeley and its contributors.
|
|
|
|
|
.\" 4. Neither the name of the University nor the names of its contributors
|
|
|
|
|
.\" may be used to endorse or promote products derived from this software
|
|
|
|
|
.\" without specific prior written permission.
|
|
|
|
|
.\"
|
|
|
|
|
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
|
|
|
|
|
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
|
|
|
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
|
|
|
|
.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
|
|
|
|
|
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
|
|
|
|
|
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
|
|
|
|
|
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
|
|
|
|
|
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
|
|
|
|
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
|
|
|
|
|
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
|
|
|
|
|
.\" SUCH DAMAGE.
|
|
|
|
|
.\"
|
|
|
|
|
.\" @(#)tftpd.8 8.1 (Berkeley) 6/4/93
|
1999-08-28 23:10:20 +00:00
|
|
|
.\" $FreeBSD$
|
1994-05-27 12:39:25 +00:00
|
|
|
.\"
|
2011-06-22 21:53:45 +00:00
|
|
|
.Dd June 22, 2011
|
1994-05-27 12:39:25 +00:00
|
|
|
.Dt TFTPD 8
|
2001-07-10 10:49:54 +00:00
|
|
|
.Os
|
1994-05-27 12:39:25 +00:00
|
|
|
.Sh NAME
|
|
|
|
|
.Nm tftpd
|
2001-04-18 15:54:10 +00:00
|
|
|
.Nd Internet Trivial File Transfer Protocol server
|
1994-05-27 12:39:25 +00:00
|
|
|
.Sh SYNOPSIS
|
2006-08-07 16:05:55 +00:00
|
|
|
.Nm tftpd
|
Go ahead and merge the work edwin@ on tftpd into the tree. It is a
lot better than what's in the tree now. Edwin tested it at a prior
employer, but can't test it today. I've found that it works a lot
better with the various uboot versions that I've used in my embedded
work. Here's the pkg-descr from the port that describes the changes:
It all started when we got some new routers, which told me the
following when trying to upload configuration or download images
from it: The TFTP server doesn't support the blocksize option.
My curiousity was triggered, it took me some reading of RFCs and
other documentation to find out what was possible and what could
be done. Was plain TFTP very simple in its handshake, TFTP with
options was kind of messy because of its backwards capability: The
first packet returned could either be an acknowledgement of options,
or the first data packet.
Going through the source code of src/libexec/tftpd and going through
the code of src/usr.bin/tftp showed that there was a lot of duplicate
code, and the addition of options would only increase the amount
of duplicate code. After all, both the client and the server can
act as a sender and receiver.
At the end, it ended up with a nearly complete rewrite of the tftp
client and server. It has been tested against the following TFTP
clients and servers:
- Itself (yay!)
- The standard FreeBSD tftp client and server
- The Fedora Core 6 tftp client and server
- Cisco router tftp client
- Extreme Networks tftp client
It supports the following RFCs:
RFC1350 - THE TFTP PROTOCOL (REVISION 2)
RFC2347 - TFTP Option Extension
RFC2348 - TFTP Blocksize Option
RFC2349 - TFTP Timeout Interval and Transfer Size Options
RFC3617 - Uniform Resource Identifier (URI) Scheme and Applicability
Statement for the Trivial File Transfer Protocol (TFTP)
It supports the following unofficial TFTP Options as described at
http://www.compuphase.com/tftp.htm:
blksize2 - Block size restricted to powers of 2, excluding protocol headers
rollover - Block counter roll-over (roll back to zero or to one)
From the tftp program point of view the following things are changed:
- New commands: "blocksize", "blocksize2", "rollover" and "options"
- Development features: "debug" and "packetdrop"
If you try this tftp/tftpd implementation, please let me know if
it works (or doesn't work) and against which implementaion so I can
get a list of confirmed working systems.
Author: Edwin Groothuis <edwin@FreeBSD.org>
2010-05-04 06:19:19 +00:00
|
|
|
.Op Fl cdClnow
|
2007-11-23 00:05:29 +00:00
|
|
|
.Op Fl F Ar strftime-format
|
1996-09-22 04:19:27 +00:00
|
|
|
.Op Fl s Ar directory
|
2000-09-14 19:08:29 +00:00
|
|
|
.Op Fl u Ar user
|
2004-05-24 22:56:15 +00:00
|
|
|
.Op Fl U Ar umask
|
1994-05-27 12:39:25 +00:00
|
|
|
.Op Ar directory ...
|
|
|
|
|
.Sh DESCRIPTION
|
2002-07-06 19:19:48 +00:00
|
|
|
The
|
|
|
|
|
.Nm
|
|
|
|
|
utility is a server which supports the
|
1994-05-27 12:39:25 +00:00
|
|
|
Internet Trivial File Transfer
|
2000-09-14 19:08:29 +00:00
|
|
|
Protocol
|
|
|
|
|
.Pq Tn RFC 1350 .
|
1994-05-27 12:39:25 +00:00
|
|
|
The
|
|
|
|
|
.Tn TFTP
|
|
|
|
|
server operates
|
|
|
|
|
at the port indicated in the
|
|
|
|
|
.Ql tftp
|
|
|
|
|
service description;
|
|
|
|
|
see
|
|
|
|
|
.Xr services 5 .
|
|
|
|
|
The server is normally started by
|
|
|
|
|
.Xr inetd 8 .
|
|
|
|
|
.Pp
|
|
|
|
|
The use of
|
|
|
|
|
.Xr tftp 1
|
|
|
|
|
does not require an account or password on the remote system.
|
2001-07-15 07:53:42 +00:00
|
|
|
Due to the lack of authentication information,
|
1997-12-03 07:19:58 +00:00
|
|
|
.Nm
|
1994-05-27 12:39:25 +00:00
|
|
|
will allow only publicly readable files to be
|
|
|
|
|
accessed.
|
2006-08-07 16:05:55 +00:00
|
|
|
Files containing the string
|
|
|
|
|
.Dq Li "/../"
|
|
|
|
|
or starting with
|
|
|
|
|
.Dq Li "../"
|
|
|
|
|
are not allowed.
|
1994-05-27 12:39:25 +00:00
|
|
|
Files may be written only if they already exist and are publicly writable.
|
|
|
|
|
Note that this extends the concept of
|
|
|
|
|
.Dq public
|
|
|
|
|
to include
|
|
|
|
|
all users on all hosts that can be reached through the network;
|
|
|
|
|
this may not be appropriate on all systems, and its implications
|
|
|
|
|
should be considered before enabling tftp service.
|
|
|
|
|
The server should have the user ID with the lowest possible privilege.
|
|
|
|
|
.Pp
|
|
|
|
|
Access to files may be restricted by invoking
|
1997-12-03 07:19:58 +00:00
|
|
|
.Nm
|
1994-05-27 12:39:25 +00:00
|
|
|
with a list of directories by including up to 20 pathnames
|
|
|
|
|
as server program arguments in
|
2006-08-07 16:05:55 +00:00
|
|
|
.Xr inetd.conf 5 .
|
1994-05-27 12:39:25 +00:00
|
|
|
In this case access is restricted to files whose
|
|
|
|
|
names are prefixed by the one of the given directories.
|
2001-07-15 07:53:42 +00:00
|
|
|
The given directories are also treated as a search path for
|
1994-05-27 12:39:25 +00:00
|
|
|
relative filename requests.
|
|
|
|
|
.Pp
|
2001-07-15 07:53:42 +00:00
|
|
|
The
|
1997-12-03 07:19:58 +00:00
|
|
|
.Fl s
|
2001-07-15 07:53:42 +00:00
|
|
|
option provides additional security by changing
|
2006-08-07 16:05:55 +00:00
|
|
|
the root directory of
|
|
|
|
|
.Nm ,
|
|
|
|
|
thereby prohibiting accesses to outside of the specified
|
2000-09-14 19:08:29 +00:00
|
|
|
.Ar directory .
|
|
|
|
|
Because
|
|
|
|
|
.Xr chroot 2
|
|
|
|
|
requires super-user privileges,
|
1997-12-03 07:19:58 +00:00
|
|
|
.Nm
|
2006-08-07 16:05:55 +00:00
|
|
|
must be run as
|
|
|
|
|
.Li root .
|
2000-09-14 19:08:29 +00:00
|
|
|
However, after performing the
|
2006-08-07 16:05:55 +00:00
|
|
|
.Xr chroot 2
|
|
|
|
|
call,
|
1997-12-03 07:19:58 +00:00
|
|
|
.Nm
|
2006-08-07 16:05:55 +00:00
|
|
|
will set its user ID to that of the specified
|
2000-09-14 19:08:29 +00:00
|
|
|
.Ar user ,
|
|
|
|
|
or
|
2006-08-07 16:05:55 +00:00
|
|
|
.Dq Li nobody
|
2000-09-14 19:08:29 +00:00
|
|
|
if no
|
|
|
|
|
.Fl u
|
|
|
|
|
option is specified.
|
1996-09-22 04:19:27 +00:00
|
|
|
.Pp
|
1994-05-27 12:39:25 +00:00
|
|
|
The options are:
|
|
|
|
|
.Bl -tag -width Ds
|
2001-01-25 04:20:25 +00:00
|
|
|
.It Fl c
|
2006-08-07 16:05:55 +00:00
|
|
|
Changes the default root directory of a connecting host via
|
|
|
|
|
.Xr chroot 2
|
|
|
|
|
based on the connecting IP address.
|
2001-01-25 04:20:25 +00:00
|
|
|
This prevents multiple clients from writing to the same file at the same time.
|
|
|
|
|
If the directory does not exist, the client connection is refused.
|
|
|
|
|
The
|
|
|
|
|
.Fl s
|
|
|
|
|
option is required for
|
|
|
|
|
.Fl c
|
2001-07-15 07:53:42 +00:00
|
|
|
and the specified
|
2001-01-25 04:20:25 +00:00
|
|
|
.Ar directory
|
|
|
|
|
is used as a base.
|
|
|
|
|
.It Fl C
|
|
|
|
|
Operates the same as
|
|
|
|
|
.Fl c
|
|
|
|
|
except it falls back to
|
|
|
|
|
.Ar directory
|
2006-08-07 16:05:55 +00:00
|
|
|
specified via
|
|
|
|
|
.Fl s
|
2001-01-25 04:20:25 +00:00
|
|
|
if a directory does not exist for the client's IP.
|
2007-11-23 00:05:29 +00:00
|
|
|
.It Fl F
|
|
|
|
|
Use this
|
|
|
|
|
.Xr strftime 3
|
|
|
|
|
compatible format string for the creation of the suffix if
|
|
|
|
|
.Fl W
|
|
|
|
|
is specified.
|
|
|
|
|
By default the string "%Y%m%d" is used.
|
2011-06-22 21:53:45 +00:00
|
|
|
.It Fl d, d Ar [value]
|
Go ahead and merge the work edwin@ on tftpd into the tree. It is a
lot better than what's in the tree now. Edwin tested it at a prior
employer, but can't test it today. I've found that it works a lot
better with the various uboot versions that I've used in my embedded
work. Here's the pkg-descr from the port that describes the changes:
It all started when we got some new routers, which told me the
following when trying to upload configuration or download images
from it: The TFTP server doesn't support the blocksize option.
My curiousity was triggered, it took me some reading of RFCs and
other documentation to find out what was possible and what could
be done. Was plain TFTP very simple in its handshake, TFTP with
options was kind of messy because of its backwards capability: The
first packet returned could either be an acknowledgement of options,
or the first data packet.
Going through the source code of src/libexec/tftpd and going through
the code of src/usr.bin/tftp showed that there was a lot of duplicate
code, and the addition of options would only increase the amount
of duplicate code. After all, both the client and the server can
act as a sender and receiver.
At the end, it ended up with a nearly complete rewrite of the tftp
client and server. It has been tested against the following TFTP
clients and servers:
- Itself (yay!)
- The standard FreeBSD tftp client and server
- The Fedora Core 6 tftp client and server
- Cisco router tftp client
- Extreme Networks tftp client
It supports the following RFCs:
RFC1350 - THE TFTP PROTOCOL (REVISION 2)
RFC2347 - TFTP Option Extension
RFC2348 - TFTP Blocksize Option
RFC2349 - TFTP Timeout Interval and Transfer Size Options
RFC3617 - Uniform Resource Identifier (URI) Scheme and Applicability
Statement for the Trivial File Transfer Protocol (TFTP)
It supports the following unofficial TFTP Options as described at
http://www.compuphase.com/tftp.htm:
blksize2 - Block size restricted to powers of 2, excluding protocol headers
rollover - Block counter roll-over (roll back to zero or to one)
From the tftp program point of view the following things are changed:
- New commands: "blocksize", "blocksize2", "rollover" and "options"
- Development features: "debug" and "packetdrop"
If you try this tftp/tftpd implementation, please let me know if
it works (or doesn't work) and against which implementaion so I can
get a list of confirmed working systems.
Author: Edwin Groothuis <edwin@FreeBSD.org>
2010-05-04 06:19:19 +00:00
|
|
|
Enables debug output.
|
2011-06-22 21:53:45 +00:00
|
|
|
If
|
|
|
|
|
.Ar value
|
|
|
|
|
is not specified, then the debug level is increased by one
|
|
|
|
|
for each instance of
|
|
|
|
|
.Fl d
|
|
|
|
|
which is specified.
|
|
|
|
|
.Pp
|
|
|
|
|
If
|
|
|
|
|
.Ar value
|
|
|
|
|
is specified, then the debug level is set to
|
|
|
|
|
.Ar value .
|
|
|
|
|
The debug level is a bitmask implemented in
|
|
|
|
|
.Pa src/libexec/tftpd/tftp-utils.h .
|
|
|
|
|
Valid values are 0 (DEBUG_NONE), 1 (DEBUG_PACKETS), 2, (DEBUG_SIMPLE),
|
|
|
|
|
4 (DEBUG_OPTIONS), and 8 (DEBUG_ACCESS). Multiple debug values can be combined
|
|
|
|
|
in the bitmask by logically OR'ing the values. For example, specifying
|
|
|
|
|
.Fl d
|
|
|
|
|
.Ar 15
|
|
|
|
|
will enable all the debug values.
|
1994-05-27 12:39:25 +00:00
|
|
|
.It Fl l
|
1997-12-03 07:19:58 +00:00
|
|
|
Log all requests using
|
2001-07-15 07:53:42 +00:00
|
|
|
.Xr syslog 3
|
|
|
|
|
with the facility of
|
2000-09-14 19:08:29 +00:00
|
|
|
.Dv LOG_FTP .
|
2006-08-07 16:05:55 +00:00
|
|
|
.Sy Note :
|
|
|
|
|
Logging of
|
2000-09-14 19:08:29 +00:00
|
|
|
.Dv LOG_FTP
|
|
|
|
|
messages
|
|
|
|
|
must also be enabled in the syslog configuration file,
|
1998-06-05 10:31:24 +00:00
|
|
|
.Xr syslog.conf 5 .
|
1994-05-27 12:39:25 +00:00
|
|
|
.It Fl n
|
1997-12-03 07:19:58 +00:00
|
|
|
Suppress negative acknowledgement of requests for nonexistent
|
1994-05-27 12:39:25 +00:00
|
|
|
relative filenames.
|
Go ahead and merge the work edwin@ on tftpd into the tree. It is a
lot better than what's in the tree now. Edwin tested it at a prior
employer, but can't test it today. I've found that it works a lot
better with the various uboot versions that I've used in my embedded
work. Here's the pkg-descr from the port that describes the changes:
It all started when we got some new routers, which told me the
following when trying to upload configuration or download images
from it: The TFTP server doesn't support the blocksize option.
My curiousity was triggered, it took me some reading of RFCs and
other documentation to find out what was possible and what could
be done. Was plain TFTP very simple in its handshake, TFTP with
options was kind of messy because of its backwards capability: The
first packet returned could either be an acknowledgement of options,
or the first data packet.
Going through the source code of src/libexec/tftpd and going through
the code of src/usr.bin/tftp showed that there was a lot of duplicate
code, and the addition of options would only increase the amount
of duplicate code. After all, both the client and the server can
act as a sender and receiver.
At the end, it ended up with a nearly complete rewrite of the tftp
client and server. It has been tested against the following TFTP
clients and servers:
- Itself (yay!)
- The standard FreeBSD tftp client and server
- The Fedora Core 6 tftp client and server
- Cisco router tftp client
- Extreme Networks tftp client
It supports the following RFCs:
RFC1350 - THE TFTP PROTOCOL (REVISION 2)
RFC2347 - TFTP Option Extension
RFC2348 - TFTP Blocksize Option
RFC2349 - TFTP Timeout Interval and Transfer Size Options
RFC3617 - Uniform Resource Identifier (URI) Scheme and Applicability
Statement for the Trivial File Transfer Protocol (TFTP)
It supports the following unofficial TFTP Options as described at
http://www.compuphase.com/tftp.htm:
blksize2 - Block size restricted to powers of 2, excluding protocol headers
rollover - Block counter roll-over (roll back to zero or to one)
From the tftp program point of view the following things are changed:
- New commands: "blocksize", "blocksize2", "rollover" and "options"
- Development features: "debug" and "packetdrop"
If you try this tftp/tftpd implementation, please let me know if
it works (or doesn't work) and against which implementaion so I can
get a list of confirmed working systems.
Author: Edwin Groothuis <edwin@FreeBSD.org>
2010-05-04 06:19:19 +00:00
|
|
|
.It Fl o
|
|
|
|
|
Disable support for RFC2347 style TFTP Options.
|
1996-09-22 04:19:27 +00:00
|
|
|
.It Fl s Ar directory
|
1997-12-03 07:19:58 +00:00
|
|
|
Cause
|
|
|
|
|
.Nm
|
2000-09-14 19:08:29 +00:00
|
|
|
to change its root directory to
|
2006-08-07 16:05:55 +00:00
|
|
|
.Ar directory .
|
|
|
|
|
After doing that but before accepting commands,
|
1997-12-03 07:19:58 +00:00
|
|
|
.Nm
|
2000-09-14 19:08:29 +00:00
|
|
|
will switch credentials to an unprivileged user.
|
|
|
|
|
.It Fl u Ar user
|
|
|
|
|
Switch credentials to
|
|
|
|
|
.Ar user
|
|
|
|
|
(default
|
2006-08-07 16:05:55 +00:00
|
|
|
.Dq Li nobody )
|
2000-09-14 19:08:29 +00:00
|
|
|
when the
|
|
|
|
|
.Fl s
|
|
|
|
|
option is used.
|
|
|
|
|
The user must be specified by name, not a numeric UID.
|
2004-05-24 22:56:15 +00:00
|
|
|
.It Fl U Ar umask
|
|
|
|
|
Set the
|
|
|
|
|
.Ar umask
|
2004-07-07 19:57:16 +00:00
|
|
|
for newly created files.
|
|
|
|
|
The default is 022
|
2006-09-17 21:48:47 +00:00
|
|
|
.Pq Dv S_IWGRP | S_IWOTH .
|
2004-05-24 22:56:15 +00:00
|
|
|
.It Fl w
|
2007-06-03 15:32:06 +00:00
|
|
|
Allow write requests to create new files.
|
2004-07-07 19:57:16 +00:00
|
|
|
By default
|
2004-05-24 22:56:15 +00:00
|
|
|
.Nm
|
|
|
|
|
requires that the file specified in a write request exist.
|
2007-11-23 00:05:29 +00:00
|
|
|
Note that this only works in directories writable by the user
|
|
|
|
|
specified with
|
|
|
|
|
.Fl u
|
|
|
|
|
option
|
|
|
|
|
.It Fl W
|
|
|
|
|
As
|
|
|
|
|
.Fl w
|
|
|
|
|
but append a YYYYMMDD.nn sequence number to the end of the filename.
|
2007-11-23 01:52:44 +00:00
|
|
|
Note that the string YYYYMMDD can be changed with the
|
2007-11-23 00:05:29 +00:00
|
|
|
.Fl F
|
|
|
|
|
option.
|
1994-05-27 12:39:25 +00:00
|
|
|
.El
|
|
|
|
|
.Sh SEE ALSO
|
|
|
|
|
.Xr tftp 1 ,
|
2000-09-14 19:08:29 +00:00
|
|
|
.Xr chroot 2 ,
|
2006-08-07 16:05:55 +00:00
|
|
|
.Xr syslog 3 ,
|
|
|
|
|
.Xr inetd.conf 5 ,
|
|
|
|
|
.Xr services 5 ,
|
|
|
|
|
.Xr syslog.conf 5 ,
|
|
|
|
|
.Xr inetd 8
|
2011-06-22 23:25:24 +00:00
|
|
|
.Pp
|
|
|
|
|
The following RFC's are supported:
|
2000-09-14 19:08:29 +00:00
|
|
|
.Rs
|
2011-06-22 23:25:24 +00:00
|
|
|
RFC 1350
|
2000-09-14 19:08:29 +00:00
|
|
|
.%T The TFTP Protocol (Revision 2)
|
|
|
|
|
.Re
|
2011-06-22 23:25:24 +00:00
|
|
|
.Rs
|
|
|
|
|
RFC 2347
|
|
|
|
|
.%T TFTP Option Extension
|
|
|
|
|
.Re
|
|
|
|
|
.Rs
|
|
|
|
|
RFC 2348
|
|
|
|
|
.%T TFTP Blocksize Option
|
|
|
|
|
.Re
|
|
|
|
|
.Rs
|
|
|
|
|
RFC 2349
|
|
|
|
|
.%T TFTP Timeout Interval and Transfer Size Options
|
|
|
|
|
.Re
|
|
|
|
|
.Pp
|
|
|
|
|
The non-standard
|
|
|
|
|
.Cm rollover
|
|
|
|
|
and
|
|
|
|
|
.Cm blksize2
|
|
|
|
|
TFTP options are mentioned here:
|
|
|
|
|
.Rs
|
|
|
|
|
.%T Extending TFTP
|
|
|
|
|
.%U http://www.compuphase.com/tftp.htm
|
|
|
|
|
.Re
|
1994-05-27 12:39:25 +00:00
|
|
|
.Sh HISTORY
|
|
|
|
|
The
|
|
|
|
|
.Nm
|
2002-07-06 19:19:48 +00:00
|
|
|
utility appeared in
|
2000-09-14 19:20:17 +00:00
|
|
|
.Bx 4.2 ;
|
|
|
|
|
the
|
|
|
|
|
.Fl s
|
|
|
|
|
option was introduced in
|
|
|
|
|
.Fx 2.2 ,
|
2001-01-25 04:20:25 +00:00
|
|
|
the
|
2000-09-14 19:20:17 +00:00
|
|
|
.Fl u
|
|
|
|
|
option was introduced in
|
2001-01-25 04:20:25 +00:00
|
|
|
.Fx 4.2 ,
|
2007-11-23 00:05:29 +00:00
|
|
|
the
|
2001-01-25 04:20:25 +00:00
|
|
|
.Fl c
|
|
|
|
|
option was introduced in
|
2007-11-23 00:05:29 +00:00
|
|
|
.Fx 4.3 ,
|
|
|
|
|
and the
|
|
|
|
|
.Fl F
|
|
|
|
|
and
|
|
|
|
|
.Fl W
|
|
|
|
|
options were introduced in
|
2010-10-06 18:20:39 +00:00
|
|
|
.Fx 7.4 .
|
2007-11-23 00:05:29 +00:00
|
|
|
.Pp
|
Go ahead and merge the work edwin@ on tftpd into the tree. It is a
lot better than what's in the tree now. Edwin tested it at a prior
employer, but can't test it today. I've found that it works a lot
better with the various uboot versions that I've used in my embedded
work. Here's the pkg-descr from the port that describes the changes:
It all started when we got some new routers, which told me the
following when trying to upload configuration or download images
from it: The TFTP server doesn't support the blocksize option.
My curiousity was triggered, it took me some reading of RFCs and
other documentation to find out what was possible and what could
be done. Was plain TFTP very simple in its handshake, TFTP with
options was kind of messy because of its backwards capability: The
first packet returned could either be an acknowledgement of options,
or the first data packet.
Going through the source code of src/libexec/tftpd and going through
the code of src/usr.bin/tftp showed that there was a lot of duplicate
code, and the addition of options would only increase the amount
of duplicate code. After all, both the client and the server can
act as a sender and receiver.
At the end, it ended up with a nearly complete rewrite of the tftp
client and server. It has been tested against the following TFTP
clients and servers:
- Itself (yay!)
- The standard FreeBSD tftp client and server
- The Fedora Core 6 tftp client and server
- Cisco router tftp client
- Extreme Networks tftp client
It supports the following RFCs:
RFC1350 - THE TFTP PROTOCOL (REVISION 2)
RFC2347 - TFTP Option Extension
RFC2348 - TFTP Blocksize Option
RFC2349 - TFTP Timeout Interval and Transfer Size Options
RFC3617 - Uniform Resource Identifier (URI) Scheme and Applicability
Statement for the Trivial File Transfer Protocol (TFTP)
It supports the following unofficial TFTP Options as described at
http://www.compuphase.com/tftp.htm:
blksize2 - Block size restricted to powers of 2, excluding protocol headers
rollover - Block counter roll-over (roll back to zero or to one)
From the tftp program point of view the following things are changed:
- New commands: "blocksize", "blocksize2", "rollover" and "options"
- Development features: "debug" and "packetdrop"
If you try this tftp/tftpd implementation, please let me know if
it works (or doesn't work) and against which implementaion so I can
get a list of confirmed working systems.
Author: Edwin Groothuis <edwin@FreeBSD.org>
2010-05-04 06:19:19 +00:00
|
|
|
Support for Timeout Interval and Transfer Size Options (RFC2349)
|
|
|
|
|
was introduced in
|
|
|
|
|
.Fx 5.0 ,
|
|
|
|
|
support for the TFTP Blocksize Option (RFC2348) and the blksize2 option
|
|
|
|
|
was introduced in
|
2010-10-06 18:20:39 +00:00
|
|
|
.Fx 7.4 .
|
2011-06-24 05:41:38 +00:00
|
|
|
.Pp
|
|
|
|
|
Edwin Groothuis <edwin@FreeBSD.org> performed a major rewrite of the
|
|
|
|
|
.Nm
|
|
|
|
|
and
|
|
|
|
|
.Xr tftp 1
|
|
|
|
|
code to support RFC2348.
|
2011-06-16 02:27:05 +00:00
|
|
|
.Sh NOTES
|
2011-07-31 03:18:36 +00:00
|
|
|
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),
|
2011-06-16 02:27:05 +00:00
|
|
|
or the non-standard TFTP rollover option.
|
2011-07-31 03:18:36 +00:00
|
|
|
As a kludge,
|
|
|
|
|
.Nm
|
|
|
|
|
accepts a sequence of block number which wrap to zero after 65535,
|
|
|
|
|
even if the rollover option is not specified.
|
2001-02-02 10:53:02 +00:00
|
|
|
.Pp
|
2011-07-31 03:18:36 +00:00
|
|
|
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.
|
