NAME

bootpd, bootptab, bootp − Internet Boot Protocol server

SYNOPSIS

/usr/sbin/bootpd [-c chdir-path] [−ttimeout]
[−d debug-level] [ configfile [ dumpfile ] ]

FLAGS

−c chdir-path
Sets the current directory used by a bootpd process while checking the existence and size of client boot files.  This is useful when client boot files are specified as relative pathnames and the bootpd process needs to use the same current directory as the TFTP server (typically /tftpboot). 

−d debug-level
Sets the debug-level variable that controls the number of debugging messages generated.  For example, −d 4 sets the debugging level to 4.  Valid entries are 1 to 4, where 1 specifies lower level of messages and 4 the highest. 

−t timeout
Specifies the timeout value (in minutes) that a bootpd process waits for a BOOTP packet before exiting.  If no packets are received for timeout seconds, then the program exits.  A timeout value of zero means that a bootpd process will wait forever.  When the bootpd daemon is not started using the inetd daemon, this option is forced to zero. 

DESCRIPTION

The bootpd daemon implements an Internet Boot Protocol server as defined in RFC 951, RFC 1532, and RFC 1533.  It is normally run by the /usr/sbin/inetd daemon by including the following line in the /etc/inetd.conf file:

bootps dgram udp wait root /usr/sbin/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 flag can be used to specify a different timeout value in minutes (for example, −t20).  A timeout value of zero means forever. 

To run the bootpd daemon, you must also run the tftpd daemon. 

Upon startup, bootpd first reads its configuration file, /etc/bootptab, and then begins listening for BOOTREQUEST packets.  The configuration file has a format similar to that of termcap(4) 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. . . .

The hostname is the name of a bootp client; tg is a two-character tag symbol.  Dummy entries have an invalid host name (one with a period (.) as the first character) and are used to provide default values used by other entries through the tc=.dummy-entry mechanism.  Most tags must be followed by an equal sign (=) and a value as above.  Some can also appear in a Boolean form with no value (that is, :tg:).  The recognized tags are:

bfBootfile

bsBootfile size in 512-octet blocks

csCookie server address list

dfMerit dump file

dnDomain name

dsDomain name server address list

efExtension file

gwGateway address list

haHost hardware address

hdBootfile home directory

hnSend host name

htHost hardware type (see Assigned Numbers RFC)

imImpress server address list

ipHost IP address

lgLog server address list

lpLPR server address list

nsIEN-116 name server address list

rReply address override

rlResource location protocol server address list

rpRoot path to mount as root

saTFTP server address the client should use

smHost subnet mask

swSwap server address

tcTable continuation (points to similar "template" host entry)

tdTFTP root directory used by secure TFTP server

toTime offset in seconds from UTC

tsTime server address list

vmVendor magic cookie selector

There is also a generic tag, Tn, where n is an RFC 1533 vendor field tag number.  Thus it is possible to immediately take advantage of future extensions to RFC 1533 without being forced to modify bootpd first.  Generic data can be represented as either a stream of hexadecimal numbers or as a quoted string of ASCII characters.  The length of the generic data is automatically determined and inserted into the proper field(s) of the RFC 1533-style bootp reply. 

The following tags take a whitespace-separated list of IP addresses:

cs

ds

gw

im

lg

lp

ns

ra

rl

ts

The ip, sa ,sw, and sm tags each take a single IP address.  All IP addresses are specified in standard Internet dot (.) notation and can use decimal, octal, or hexadecimal numbers (octal numbers begin with 0, hexadecimal numbers begin with 0x or 0X).  Any IP addresses can alternatively be specified as a host name, causing the bootpd daemon to look up the IP address for that host name using the gethostbyname routine.  If the ip tag is not specified, the bootpd daemon determines the IP address using the entry name as the host name.  (Dummy entries use an invalid host name to avoid automatic IP lookup.) 

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 10 Mb Ethernet; ethernet3 or ether3 for 3 Mb 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, respectively.  The ha tag takes a hardware address that must be specified in hexadecimal; optional periods and/or a leading 0x can be included for readability.  The ha tag must be preceded by the ht tag (either explicitly or implicitly; see tc below). 

The host name, home directory, and bootfile are ASCII strings that can be optionally surrounded by double quotation marks (").  The client’s request and the values of the hd and bf symbols determine how the server fills in the bootfile field of the 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 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, then the request is discarded. 

Clients that 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, that pathname is returned in the reply packet.  Otherwise, if the hd and bf tags together specify an accessible file, that file name is returned in the reply.  If a complete file name cannot be determined, the reply will contain a zeroed-out bootfile field. 

In these cases, for the tftp transfer to succeed, the file must be present and it must have its public read access bit set.  (For other tftpd file access restrictions see the tftpd(8) reference page.) Also, all file names are first tried as filename.hostname and then as filename, thus providing for individual per-host bootfiles. 

Some newer versions of the tftpd daemon provide a security feature to change their root directory using the chroot system call.  You can use the td tag to inform the bootpd daemon  of this special root directory used by the tftpd daemon.  (Alternatively, you can use the bootpd −c chdir option.)  The hd tag is relative to the root directory specified by the td tag.  For example, if the real absolute path to your BOOTP client bootfile is /tftpboot/bootfiles/bootimage, and the tftpd daemon uses /tftpboot as its secure directory, then specify the following line in the bootptab file:

:td=/tftpboot:hd=/bootfiles:bf=bootimage:

If your bootfiles are located directly in the /tftpboot directory, use the following line in the bootptab file:

:td=/tftpboot:hd=/:bf=bootimage:

You can use the sa tag to specify the IP address of the particular TFTP server you want the client to use.  In the absence of this tag, the bootpd daemon tells the client to perform TFTP to the same machine on which the bootpd daemon is running. 

The time offset (to) can 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) can be either a decimal, octal, or hexadecimal 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) can take one of the following keywords:

autoIndicates that vendor information is determined by the client’s request. 

rfc1048Always forces an RFC 1048/RFC 1033-style reply. 

cmuAlways forces a CMU-style reply. 

The hn tag is strictly a Boolean tag; it does not take the usual equal sign and value.  It’s presence indicates that the host name should be sent to RFC 1533 clients.  The bootpd daemon attempts to send the entire host name 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 host name sent (if nothing reasonable 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 that does not actually exist and never sends bootp requests.  This feature is similar to the tc feature of termcap(4) 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 can be the host name 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 construction tag@, which removes the effect of tag as in termcap(4).  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 the number sign (#) are ignored in the configuration file.  Host entries are separated from one another by newlines; a single host entry can be extended over multiple lines if the lines end with a backslash (\).  It is also acceptable for lines to be longer than 80 characters.  Tags can appear in any order, with the following exceptions: the host name must be the first field in an entry, and the hardware type must precede the hardware address. 

A sample /etc/bootptab file follows:

# Sample bootpd file
.default1:\
:hd=/usr/boot:bf=null:\
:ds=128.2.35.50 128.2.13.21:\
:ns=128.2.11.77 128.2.15.25:\
:ts=128.2.11.77 128.2.15.25:\
:sm=255.255.0.0:gw=128.2.254.36:\
:hn:vm=auto:to=-18000:\
: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
bojct: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:

The bootpd daemon looks in /etc/services to find the port numbers it should use.  Two entries are extracted:

bootpsThe bootp server listening port

bootpcThe 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. 

The bootpd daemon 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 can 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 /usr/adm/bootpd.dump file or dumpfile specified in the command line. 

RESTRICTIONS

Individual host entries must not exceed 1024 characters. 

FILES

/etc/bootptabInternet Boot Protocol server. 

/usr/adm/bootpd.dump
The bootpd daemon dump file. 

/etc/servicesDefines the sockets and protocols used for Internet services. 

RELATED INFORMATION

Commands: bootpgw(8), inetd(8), tftpd(8)

DARPA Internet Request For Comments: Bootstrap Protocol (RFC 951), Clarifications and Extensions for the Bootpstrap Protocol (RFC 1532), DHCP Options and BOOTP Vendor Extensions (RFC 1533)