bootpd(1M) SYSTEM ADMINISTRATION COMMANDS bootpd(1M)
NAME
bootpd - Internet Boot Protocol server
SYNOPSIS
in.bootpd [ -s -ttimeout -d ] [ configfile [ dumpfile ] ]
DESCRIPTION
Bootpd implements an Internet Boot Protocol server as
defined in RFC951 and RFC1048. It is normally run by
/usr/sbin/inetd by including the following line in the file
/etc/inet/inetd.conf:
bootps dgram udp wait root /usr/sbin/in.bootpd
bootpd
This causes bootpd to be started only when a boot request
arrives. If bootpd does not receive another boot request
within fifteen minutes of the last one it received, it will
exit to conserve system resources. The -t switch may be
used to specify a different timeout value in minutes (e.g.
-t20). A timeout value of zero means forever.
It is also possible to run bootpd in a standalone configura-
tion using the -s switch (for example, at boot time from
/etc/rc2.d). This is probably the desired mode of operation
for large network installations with many hosts. In this
case, the -t switch has no effect since bootpd will never
exit.
Each instance of the -d switch increases the level of debug-
ging output.
Upon startup, bootpd first reads its configuration file,
/etc/inet/bootptab, and then begins listening for BOOTRE-
QUEST packets. The configuration file has a format similar
to that of termcap(5) in which two-character case-sensitive
tag symbols are used to represent host parameters. These
parameter declarations are separated by colons (:). The
general format is:
hostname:tg=value. . . :tg=value. . . :tg=value. . . .
where hostname is the actual name of a bootp client and tg
is a two-character tag symbol. Most tags must be followed
by an equals-sign and a value as above. Some may also
appear in a boolean form with no value (i.e. :tg:). The
currently recognized tags are:
bf Bootfile
bs Bootfile size in 512-octet blocks
cs Cookie server address list
ds Domain name server address list
1
bootpd(1M) SYSTEM ADMINISTRATION COMMANDS bootpd(1M)
gw Gateway address list
ha Host hardware address
hd Bootfile home directory
hn Send hostname
ht Host hardware type (see Assigned Numbers RFC)
im Impress server address list
ip Host IP address
lg Log server address list
lp LPR server address list
ns IEN-116 name server address list
rl Resource location protocol server address list
sm Host subnet mask
tc Table continuation (points to similar "template"
host entry)
to Time offset in seconds from UTC
ts Time server address list
vm Vendor magic cookie selector
There is also a generic tag, Tn, where n is an RFC1048 ven-
dor field tag number. Thus it is possible to immediately
take advantage of future extensions to RFC1048 without being
forced to modify bootpd first. Generic data may be
represented as either a stream of hexadecimal numbers or as
a quoted string of ASCII characters. The length of the gen-
eric data is automatically determined and inserted into the
proper field(s) of the RFC1048-style bootp reply.
The following tags take a whitespace-separated list of IP
addresses: cs, ds, gw, im, lg, lp, ns, rl, and ts. The ip
and sm tags each take a single IP address. All IP addresses
are specified in standard Internet "dot" notation and may
use decimal, octal, or hexadecimal numbers (octal numbers
begin with 0, hexadecimal numbers begin with '0x' or '0X').
The ht tag specifies the hardware type code as either an
unsigned decimal, octal, or hexadecimal integer or one of
the following symbolic names: ethernet or ether for 10Mb
Ethernet, ethernet3 or ether3 for 3Mb experimental Ethernet,
ieee802, tr, or token-ring for IEEE 802 networks, pronet for
Proteon ProNET Token Ring, or chaos, arcnet, or ax.25 for
Chaos, ARCNET, and AX.25 Amateur Radio networks, respec-
tively. The ha tag takes a hardware address which must be
specified in hexadecimal; optional periods and/or a leading
'0x' may be included for readability. The ha tag must be
preceded by the ht tag (either explicitly or implicitly; see
tc below).
The hostname, home directory, and bootfile are ASCII strings
which may be optionally surrounded by double quotes (").
The client's request and the values of the hd and bf symbols
determine how the server fills in the bootfile field of the
2
bootpd(1M) SYSTEM ADMINISTRATION COMMANDS bootpd(1M)
bootp reply packet.
If the client specifies an absolute pathname and that file
exists on the server machine, that pathname is returned in
the reply packet. If the file cannot be found, the request
is discarded; no reply is sent. If the client specifies a
relative pathname, a full pathname is formed by prepending
the value of the hd tag and testing for existence of the
file. If the hd tag is not supplied in the configuration
file or if the resulting boot file cannot be found, then the
request is discarded.
Clients which specify null boot files will always elicit a
reply from the server. The exact reply will again depend
upon the hd and bf tags. If the bf tag gives an absolute
pathname and the file exists, that pathname is returned in
the reply packet. Otherwise, if the hd and bf tags together
specify an accessible file, that filename is returned in the
reply. If a complete filename cannot be determined or the
file does not exist, the reply will contain a zeroed-out
bootfile field.
In all these cases, existence of the file means that, in
addition to actually being present, the file must have its
public read access bit set, since this is required by
tftpd(8) to permit the file transfer. Also, all filenames
are first tried as filename.hostname and then simply as
filename, thus providing for individual per-host bootfiles.
The time offset to may be either a signed decimal integer
specifying the client's time zone offset in seconds from
UTC, or the keyword auto which uses the server's time zone
offset. Specifying the to symbol as a boolean has the same
effect as specifying auto as its value.
The bootfile size bs may be either a decimal, octal, or hex-
adecimal integer specifying the size of the bootfile in
512-octet blocks, or the keyword auto which causes the
server to automatically calculate the bootfile size at each
request. As with the time offset, specifying the bs symbol
as a boolean has the same effect as specifying auto as its
value.
The vendor magic cookie selector (the vm tag) may take one
of the following keywords: auto (indicating that vendor
information is determined by the client's request), rfc1048
(which always forces an RFC1048-style reply), or cmu (which
always forces a CMU-style reply).
The hn tag is strictly a boolean tag; it does not take the
usual equals-sign and value. It's presence indicates that
the hostname should be sent to RFC1048 clients. Bootpd
3
bootpd(1M) SYSTEM ADMINISTRATION COMMANDS bootpd(1M)
attempts to send the entire hostname as it is specified in
the configuration file; if this will not fit into the reply
packet, the name is shortened to just the host field (up to
the first period, if present) and then tried. In no case is
an arbitrarily-truncated hostname sent (if nothing reason-
able will fit, nothing is sent).
Often, many host entries share common values for certain
tags (such as name servers, etc.). Rather than repeatedly
specifying these tags, a full specification can be listed
for one host entry and shared by others via the tc (table
continuation) mechanism. Often, the template entry is a
dummy host which doesn't actually exist and never sends
bootp requests. This feature is similar to the tc feature
of termcap(5) for similar terminals. Note that bootpd
allows the tc tag symbol to appear anywhere in the host
entry, unlike termcap which requires it to be the last tag.
Information explicitly specified for a host always overrides
information implied by a tc tag symbol, regardless of its
location within the entry. The value of the tc tag may be
the hostname or IP address of any host entry previously
listed in the configuration file.
Sometimes it is necessary to delete a specific tag after it
has been inferred via tc. This can be done using the con-
struction tag@ which removes the effect of tag as in
termcap(5). For example, to completely undo an IEN-116 name
server specification, use ":ns@:" at an appropriate place in
the configuration entry. After removal with @, a tag is
eligible to be set again through the tc mechanism.
Blank lines and lines beginning with "#" are ignored in the
configuration file. Host entries are separated from one
another by newlines; a single host entry may be extended
over multiple lines if the lines end with a backslash (\).
It is also acceptable for lines to be longer than 80 charac-
ters. Tags may appear in any order, with the following
exceptions: the hostname must be the very first field in an
entry, and the hardware type must precede the hardware
address.
An example /etc/bootptab file follows:
# Sample bootptab file
default1:\
:hd=/usr/boot:bf=null:\
:ds=128.2.35.50 128.2.13.21:\
:ns=0x80020b4d 0x80020ffd:\
:ts=0x80020b4d 0x80020ffd:\
:sm=255.255.0.0:gw=0x8002fe24:\
:hn:vm=auto:to=-18000:\
4
bootpd(1M) SYSTEM ADMINISTRATION COMMANDS bootpd(1M)
:T37=0x12345927AD3BCF:T99="Special ASCII string":
carnegie:ht=6:ha=7FF8100000AF:ip=128.2.11.1:tc=default1:
baldwin:ht=1:ha=0800200159C3:ip=128.2.11.10:tc=default1:
wylie:ht=1:ha=00DD00CADF00:ip=128.2.11.100:tc=default1:
arnold:ht=1:ha=0800200102AD:ip=128.2.11.102:tc=default1:
bairdford:ht=1:ha=08002B02A2F9:ip=128.2.11.103:tc=default1:
bakerstown:ht=1:ha=08002B0287C8:ip=128.2.11.104:tc=default1:
# Special domain name server for next host
butlerjct:ht=1:ha=08002001560D:ip=128.2.11.108:ds=128.2.13.42:tc=default1:
gastonville:ht=6:ha=7FFF81000A47:ip=128.2.11.115:tc=default1:
hahntown:ht=6:ha=7FFF81000434:ip=128.2.11.117:tc=default1:
hickman:ht=6:ha=7FFF810001BA:ip=128.2.11.118:tc=default1:
lowber:ht=1:ha=00DD00CAF000:ip=128.2.11.121:tc=default1:
mtoliver:ht=1:ha=00DD00FE1600:ip=128.2.11.122:tc=default1:
Bootpd looks in /etc/inet/services to find the port numbers
it should use. Two entries are extracted: bootps -- the
bootp server listening port, and bootpc -- the destination
port used to reply to clients. If the port numbers cannot
be determined this way, they are assumed to be 67 for the
server and 68 for the client.
Bootpd rereads its configuration file when it receives a
hangup signal, SIGHUP, or when it receives a bootp request
packet and detects that the file has been updated. Hosts may
be added, deleted or modified when the configuration file is
reread. If bootpd is compiled with the -DDEBUG option,
receipt of a SIGUSR1 signal causes it to dump its memory-
resident database to the file /etc/inet/bootpd.dump or the
command-line-specified dumpfile.
FILES
/etc/inet/bootptab
/etc/inet/bootpd.dump
/etc/inet/services
BUGS
Individual host entries must not exceed 1024 characters.
HISTORY
22-Jan-86 Bill Croft at Standford University
Created.
30-Jul-86 David Kovar at Carnegie Mellon University
5
bootpd(1M) SYSTEM ADMINISTRATION COMMANDS bootpd(1M)
Modified to CMU specifications.
24-Jul-87 Drew D. Perkins at Carnegie Mellon University
Modified to use syslog. Added debugging dumps. Other
bug fixes.
17-Jul-88 Walter L. Wimer at Carnegie Mellon University
Added vendor information to conform to RFC1048.
Adopted termcap-like file format to allow variable
data.
SEE ALSO
inetd(1M);
DARPA Internet Request For Comments RFC951, RFC1048,
RFC1084, Assigned Numbers
6