1994-06-28 01:25:48 +04:00
|
|
|
.\" Copyright (c) 1988, 1989, 1991 Carnegie Mellon University
|
|
|
|
.\"
|
1997-04-18 09:22:35 +04:00
|
|
|
.\" $Header: /cvsroot/src/usr.sbin/bootp/bootpd/bootpd.8,v 1.4 1997/04/18 05:22:35 mikel Exp $
|
1994-06-28 01:25:48 +04:00
|
|
|
.\"
|
|
|
|
.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
|
1996-09-27 05:38:55 +04:00
|
|
|
bootps dgram udp wait root /usr/sbin/bootpd bootpd bootptab
|
1994-06-28 01:25:48 +04:00
|
|
|
.br
|
1996-09-27 05:38:55 +04:00
|
|
|
bootps dgram udp wait root /usr/sbin/bootpgw bootpgw server
|
1994-06-28 01:25:48 +04:00
|
|
|
.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.
|
1997-04-18 09:22:35 +04:00
|
|
|
If no packets are received for
|
1994-06-28 01:25:48 +04:00
|
|
|
.I timeout
|
1997-04-18 09:22:35 +04:00
|
|
|
minutes, then the program will exit.
|
1994-06-28 01:25:48 +04:00
|
|
|
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
|