1 .\" -*- nroff -*- --------------------------------------------------------- *
4 .\" Copyright (c) 1990, 1993, 1994
5 .\" The Regents of the University of California. All rights reserved.
7 .\" Copyright 2001 H. Peter Anvin - All Rights Reserved
9 .\" Redistribution and use in source and binary forms, with or without
10 .\" modification, are permitted provided that the following conditions
12 .\" 1. Redistributions of source code must retain the above copyright
13 .\" notice, this list of conditions and the following disclaimer.
14 .\" 2. Redistributions in binary form must reproduce the above copyright
15 .\" notice, this list of conditions and the following disclaimer in the
16 .\" documentation and/or other materials provided with the distribution.
17 .\" 3. Neither the name of the University nor the names of its contributors
18 .\" may be used to endorse or promote products derived from this software
19 .\" without specific prior written permission.
21 .\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
22 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
23 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
24 .\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
25 .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
26 .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
27 .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
28 .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
29 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
30 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
33 .\"----------------------------------------------------------------------- */
34 .TH TFTPD 8 "13 November 2001" "tftp-hpa" "UNIX System Manager's Manual"
37 \- IPv4 Trivial File Transfer Protocol server
44 is a server for the IPv4 Trivial File Transfer Protocol. The TFTP
45 protocol is extensively used to support remote booting of diskless
46 devices. The server is normally started by
48 but can also run standalone.
53 Run the server in standalone (listen) mode, rather than run from
57 option is ignored, and the
59 option can be used to specify a specific local address or port to
62 \fB\-a\fP \fI[address][:port]\fP
67 to listen to when called with the
69 option. The default is to listen to the
73 on all local addresses.
76 Allow new files to be created. By default,
78 will only allow upload of files that already exist. Files are created
79 with default permissions allowing anyone to read or write them.
82 Change root directory on startup. This means the remote host does not
83 need to pass along the directory as part of the transfer, and may add
86 is specified, exactly one
88 should be specified on the command line. The use of this option is
89 recommended for security as well as compatibility with some boot ROMs
90 which cannot be easily made to include a directory name in its request.
92 \fB\-u\fP \fIusername\fP
93 Specify the username which
95 will run as; the default is "nobody".
97 \fB\-t\fP \fItimeout\fP
100 this specifies how long, in seconds, to wait for a second connection
101 before terminating the server.
103 will then respawn the server when another request comes in. The
104 default is 900 (15 minutes.)
106 \fB\-m\fP \fIremap-file\fP
107 Specify the use of filename remapping. The
109 is a file containing the remapping rules. See the section on filename
110 remapping below. This option may not be compiled in, see
112 to verify whether or not it is available.
115 Increase the logging verbosity of
117 This flag can be specified multiple times for even higher verbosity.
119 \fB\-r\fP \fItftp-option\fP
120 Indicate that a specific RFC 2347 TFTP option should never be
124 Print the version number and configuration to standard output, then
126 .SH "RFC 2347 OPTION NEGOTIATION"
129 supports RFC 2347 option negotation. Currently implemented options
140 option can be used to disable specific options; this may be necessary
141 to work around bugs in specific TFTP client implementations.
142 .SH "FILENAME REMAPPING"
145 option specifies a file which contains filename remapping rules. Each
146 non-comment line (comments begin with hash marks,
152 a regular expression in the style of
155 .IR "replacement pattern" .
156 The operation indicated by
160 matches all or part of the filename. Rules are processed from the top
161 down, and by default, all rules are processed even if there is a
166 can be any combination of the following letters:
169 Replace the substring matched by
172 .IR "replacement pattern" .
175 can be used to copy the entire matched string, and the sequences
177 copies parenthesized subexpressions. To specify a backslash, white
178 space or hash mark, you need to \\-escape it.
181 Repeat this rule until it no longer matches. This is always used with
187 case-insensitively. By default it is case sensitive.
190 If this rule matches, end rule processing after executing the rule.
193 If this rule matches, start rule processing over from the very first
194 rule after executing this rule.
197 If this rule matches, refuse the request and send an access denied
201 This rule applies to GET (RRQ) requests only.
204 This rule applies to PUT (WRQ) requests only.
206 If the mapping file is changed, you need to send
212 The use of TFTP services does not require an account or password on
213 the server system. Due to the lack of authentication information,
215 will allow only publicly readable files (o+r) to be accessed. Files
216 may be written only if they already exist and are publicly writable,
219 option is specified. Note that this extends the concept of ``public''
220 to include all users on all hosts that can be reached through the
221 network; this may not be appropriate on all systems, and its
222 implications should be considered before enabling TFTP service.
223 Typically, some kind of firewall or packet-filter solution should be
224 employed. If appropriately compiled (see the output of
229 database for access control information. This may be slow; sites
230 requiring maximum performance may want to compile without this option
231 and rely on firewalling or kernel-based packet filters instead.
233 The server should be set to have the user ID with the lowest possible
234 privilege; please see the
238 Access to files can, and should, be restricted by invoking
240 with a list of directories by including pathnames as server program
241 arguments on the command line. In this case access is restricted to
242 files whole names are prefixed by one of the given directories. If
243 possible, it is recommended that the
245 flag is used to set up a chroot() environment for the server to run in
246 once a connection has been set up.
248 Finally, the filename remapping
250 flag) support can be used to provide a limited amount of additional
253 It is unclear at this point if the retransmission algorithm used is
254 sufficient to satisfy the RFC 1123 requirement that TFTP
255 implementations use adaptive retransmission timeout. Furthermore, it
256 is unclear how to combine the adaptive timeout of RFC 1123 with the
258 option specified by RFC 2349.
261 .IR "Requirements for Internet Hosts \- Application and Support" .
264 .IR "The TFTP Protocol (revision 2)" .
267 .IR "TFTP Option Extension" .
270 .IR "TFTP Blocksize Option" .
273 .IR "TFTP Timeout Interval and Transfer Size Options" .
277 TFTP option is functionally identical to the
279 option specified in RFC 2349, with the additional constraint that the
280 blocksize is constrained to be a power of 2.
284 is maintained by H. Peter Anvin <hpa@zytor.com>. It was derived from,
285 but has substantially diverged from, an OpenBSD source base, with
286 added patches by Markus Gutschke and Gero Kulhman.
290 .BR hosts_access (5),