summaryrefslogtreecommitdiffstats
path: root/usr.sbin/bootpd/bootpd.8
diff options
context:
space:
mode:
Diffstat (limited to 'usr.sbin/bootpd/bootpd.8')
-rw-r--r--usr.sbin/bootpd/bootpd.8305
1 files changed, 0 insertions, 305 deletions
diff --git a/usr.sbin/bootpd/bootpd.8 b/usr.sbin/bootpd/bootpd.8
deleted file mode 100644
index da59c21..0000000
--- a/usr.sbin/bootpd/bootpd.8
+++ /dev/null
@@ -1,305 +0,0 @@
-.\" Copyright (c) 1988, 1989, 1991 Carnegie Mellon University
-.\"
-.\" $Header: /b/source/CVS/src/usr.sbin/bootpd/bootpd.8,v 1.2 1994/08/22 22:14:41 gwr Exp $
-.\"
-.TH BOOTPD 8 "November 06, 1993" "Carnegie Mellon University"
-.SH NAME
-bootpd, bootpgw \- Internet Boot Protocol server/gateway
-.SH SYNOPSIS
-.B bootpd
-[
-.B \-i
-.B \-s
-.B \-t
-timeout
-.B \-d
-level
-.B \-c
-chdir\-path
-]
-[
-.I bootptab
-[
-.I dumpfile
-] ]
-.br
-.B bootpgw
-[
-.B \-i
-.B \-s
-.B \-t
-timeout
-.B \-d
-level
-] server
-.SH DESCRIPTION
-.I Bootpd
-implements an Internet Bootstrap Protocol (BOOTP) server as defined in
-RFC951, RFC1532, and RFC1533.
-.I Bootpgw
-implements a simple BOOTP gateway which can be used to forward
-requests and responses between clients on one subnet and a
-BOOTP server (i.e.
-.IR bootpd )
-on another subnet. While either
-.I bootpd
-or
-.I bootpgw
-will forward BOOTREPLY packets, only
-.I bootpgw
-will forward BOOTREQUEST packets.
-.PP
-One host on each network segment is normally configured to run either
-.I bootpd
-or
-.I bootpgw
-from
-.I inetd
-by including one of the following lines in the file
-.IR /etc/inetd.conf :
-.IP
-bootps dgram udp wait root /etc/bootpd bootpd bootptab
-.br
-bootps dgram udp wait root /etc/bootpgw bootpgw server
-.PP
-This mode of operation is referred to as "inetd mode" and causes
-.I bootpd
-(or
-.IR bootpgw )
-to be started only when a boot request arrives. If it does not
-receive another packet within fifteen minutes of the last one
-it received, it will exit to conserve system resources. The
-.B \-t
-option controls this timeout (see OPTIONS).
-.PP
-It is also possible to run
-.I bootpd
-(or
-.IR bootpgw )
-in "standalone mode" (without
-.IR inetd )
-by simply invoking it from a shell like any other regular command.
-Standalone mode is particularly useful when
-.I bootpd
-is used with a large configuration database, where the start up
-delay might otherwise prevent timely response to client requests.
-(Automatic start up in standalone mode can be done by invoking
-.I bootpd
-from within
-.IR /etc/rc.local ,
-for example.)
-Standalone mode is less useful for
-.I bootgw
-which
-has very little start up delay because
-it does not read a configuration file.
-.PP
-Either program automatically detects whether it was invoked from inetd
-or from a shell and automatically selects the appropriate mode.
-The
-.B \-s
-or
-.B \-i
-option may be used to force standalone or inetd mode respectively
-(see OPTIONS).
-.SH OPTIONS
-.TP
-.BI \-t \ timeout
-Specifies the
-.I timeout
-value (in minutes) that a
-.I bootpd
-or
-.I bootpgw
-process will wait for a BOOTP packet before exiting.
-If no packets are recieved for
-.I timeout
-seconds, then the program will exit.
-A timeout value of zero means "run forever".
-In standalone mode, this option is forced to zero.
-.TP
-.BI \-d \ debug\-level
-Sets the
-.I debug\-level
-variable that controls the amount of debugging messages generated.
-For example, -d4 or -d 4 will set the debugging level to 4.
-For compatibility with older versions of
-.IR bootpd ,
-omitting the numeric parameter (i.e. just -d) will
-simply increment the debug level by one.
-.TP
-.BI \-c \ chdir\-path
-Sets the current directory used by
-.I bootpd
-while checking the existence and size of client boot files. This is
-useful when client boot files are specified as relative pathnames, and
-.I bootpd
-needs to use the same current directory as the TFTP server
-(typically /tftpboot). This option is not recoginzed by
-.IR bootpgw .
-.TP
-.B \-i
-Force inetd mode. This option is obsolete, but remains for
-compatibility with older versions of
-.IR bootpd .
-.TP
-.B \-s
-Force standalone mode. This option is obsolete, but remains for
-compatibility with older versions of
-.IR bootpd .
-.TP
-.I bootptab
-Specifies the name of the configuration file from which
-.I bootpd
-loads its database of known clients and client options
-.RI ( bootpd
-only).
-.TP
-.I dumpfile
-Specifies the name of the file that
-.I bootpd
-will dump its internal database into when it receives a
-SIGUSR1 signal
-.RI ( bootpd
-only). This option is only recognized if
-.I bootpd
-was compiled with the -DDEBUG flag.
-.TP
-.I server
-Specifies the name of a BOOTP server to which
-.I bootpgw
-will forward all BOOTREQUEST packets it receives
-.RI ( bootpgw
-only).
-.SH OPERATION
-.PP
-Both
-.I bootpd
-and
-.I bootpgw
-operate similarly in that both listen for any packets sent to the
-.I bootps
-port, and both simply forward any BOOTREPLY packets.
-They differ in their handling of BOOTREQUEST packets.
-.PP
-When
-.I bootpgw
-is started, it determines the address of a BOOTP server
-whose name is provided as a command line parameter. When
-.I bootpgw
-receives a BOOTREQUEST packet, it sets the "gateway address"
-and "hop count" fields in the packet and forwards the packet
-to the BOOTP server at the address determined earlier.
-Requests are forwarded only if they indicate that
-the client has been waiting for at least three seconds.
-.PP
-When
-.I bootpd
-is started it reads a configuration file, (normally
-.IR /etc/bootptab )
-that initializes the internal database of known clients and client
-options. This internal database is reloaded
-from the configuration file when
-.I bootpd
-receives a hangup signal (SIGHUP) or when it discovers that the
-configuration file has changed.
-.PP
-When
-.I bootpd
-receives a BOOTREQUEST packet, it
-.\" checks the modification time of the
-.\" configuration file and reloads the database if necessary. Then it
-looks for a database entry matching the client request.
-If the client is known,
-.I bootpd
-composes a BOOTREPLY packet using the database entry found above,
-and sends the reply to the client (possibly using a gateway).
-If the client is unknown, the request is discarded
-(with a notice if debug > 0).
-.PP
-If
-.I bootpd
-is compiled with the -DDEBUG option, receipt of a SIGUSR1 signal causes
-it to dump its internal database to the file
-.I /etc/bootpd.dump
-or the dumpfile specified as a command line parameter.
-.PP
-During initialization, both programs
-determine the UDP port numbers to be used by calling
-.I getservbyname
-(which nomally uses
-.IR /etc/services).
-Two service names (and port numbers) are used:
-.IP
-bootps \- BOOTP Server listening port
-.br
-bootpc \- BOOTP Client destination port
-.LP
-If the port numbers cannot
-be determined using
-.I getservbyname
-then the values default to boopts=67 and bootpc=68.
-.SH FILES
-.TP 20
-/etc/bootptab
-Database file read by
-.IR bootpd .
-.TP
-/etc/bootpd.dump
-Debugging dump file created by
-.IR bootpd .
-.TP
-/etc/services
-Internet service numbers.
-.TP
-/tftpboot
-Current directory typically used by the TFTP server and
-.IR bootpd .
-
-.SH BUGS
-Individual host entries must not exceed 1024 characters.
-
-.SH CREDITS
-.PP
-This distribution is currently maintained by
-Walter L. Wimer <walt+@cmu.edu>.
-.PP
-The original BOOTP server was created by
-Bill Croft at Stanford University in January 1986.
-.PP
-The current version of
-.I bootpd
-is primarily the work of David Kovar,
-Drew D. Perkins, and Walter L. Wimer,
-at Carnegie Mellon University.
-.TP
-Enhancements and bug\-fixes have been contributed by:
-(in alphabetical order)
-.br
-Danny Backx <db@sunbim.be>
-.br
-John Brezak <brezak@ch.hp.com>
-.br
-Frank da Cruz <fdc@cc.columbia.edu>
-.br
-David R. Linn <drl@vuse.vanderbilt.edu>
-.br
-Jim McKim <mckim@lerc.nasa.gov>
-.br
-Gordon W. Ross <gwr@mc.com>
-.br
-Jason Zions <jazz@hal.com>
-.SH "SEE ALSO"
-.LP
-bootptab(5), inetd(8), tftpd(8)
-.LP
-DARPA Internet Request For Comments:
-.TP 10
-RFC951
-Bootstrap Protocol
-.TP 10
-RFC1532
-Clarifications and Extensions for the Bootstrap Protocol
-.TP 10
-RFC1533
-DHCP Options and BOOTP Vendor Extensions
OpenPOWER on IntegriCloud