bootpd

Internet boot protocol server

Syntax:

bootpd [-s] [-t timeout] [-d] [configfile] 

Options:

-s
Run standalone.
-t timeout
Specify the timeout value in minutes (the default is 15).
-d
Write debugging information to the /etc/bootpd.dump file.
configfile
Specify a configuration file (the default file is /etc/bootptab).

Description:

The bootpd utility implements an Internet Boot Protocol server as defined in RFC 951 and RFC 1048. To conserve resources, it's normally run by the inetd utility via the following line in the /etc/inetd.conf file:

bootps  dgram  udp wait root /etc/bootpd  bootpd

This causes bootpd to be started only when a boot request arrives. If bootpd doesn't receive another boot request within fifteen minutes of the last one it received, it will exit to conserve system resources. You can use the -t option to specify a different timeout value in minutes (e.g. -t20). A timeout value of zero means forever.

Rather than wait for a boot request, bootpd can be started independent of inetd (for example in /etc/netstart using the -s option). This is probably the desired mode of operation for large network installations with many hosts.

When using the -s option, bootpd and inetd may compete for the same port. Make sure to comment out the bootps entry in the /etc/inetd.conf file. In this case, the -t option has no effect since bootpd will never exit.

Each instance of the -d option increases the level of debugging output.

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, 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 (e.g. :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
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's also a generic tag, Tn, where n is an RFC 1048 vendor field tag number. This lets you take advantage of future extensions to RFC 1048 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 generic data is automatically determined and inserted into the proper field(s) of the RFC 1048-style bootp reply.

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

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 as one of the following symbolic names:

The ha tag takes a hardware address that must be specified in hexadecimal (optional periods and/or a leading 0x may be included for readability). The ha tag must follow the ht tag (either explicitly or implicitly; see tc below).

The hostname, home directory, and bootfile are ASCII strings that 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 bootp reply packet.

If the client specifies an absolute pathname and that file exists on the server machine, then that pathname is returned in the reply packet. If the file can't be found, the request is discarded and 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 isn't supplied in the configuration file or if the resulting boot file can't be found, 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 on the hd and bf tags. If the bf tag gives an absolute pathname and the file exists, then that pathname is returned in the reply packet. If the hd and bf tags together specify an accessible file, then that filename is returned in the reply. If a complete filename can't be determined or if the file doesn't exist, then the reply will contain a zeroed-out bootfile field.

In all these cases, the file must have its public read access bit set, since this is required by tftpd.

The time offset to may be either:

Specifying the to symbol as a boolean has the same effect as specifying auto as its value. The bootfile size bs may be either:

As with the time offset, specifying bs 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:

The hn tag is strictly a boolean tag; it doesn't take the usual equals sign and value. Its presence indicates that the hostname should be sent to RFC 1048 clients. The bootpd daemon attempts to send the entire hostname as it is specified in the configuration file. If the name won't fit into the reply packet, it will be shortened to just the host field (up to the first period, if present) and then tried. The server will never send an arbitrarily truncated hostname (if nothing reasonable will fit, nothing is sent).

Many host entries often share common values for certain tags (such as name servers, etc.). Rather than repeatedly specify these tags, you can use the tc (table continuation) mechanism to list a full specification for one host entry that can be shared by others. The template entry is often a dummy host that doesn't actually exist and never sends bootp requests. This feature is similar to the tc feature of termcap 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's necessary to delete a specific tag after it's been inferred via tc. This can be done using the construction tag @, which removes the effect of the tag as in termcap.

For example, to completely undo an IEN-116 name server specification, you would put the following at an appropriate place in the configuration entry:

:ns@:

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 (\). Lines can be longer than 80 characters.

Tags may appear in any order, with the following exceptions:

Here's an example /etc/bootptab file:

# 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:\
    :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:

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

If the port numbers can't be determined this way, they're assumed to be 67 for the server and 68 for the client.

The server 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.

QNX extensions:

The argument to the bf tag can start with an | character. If so, then the following is taken to be a command to spawn in order to get a boot image:

bf= |cd /boot; buildqnx build/node1:

Files:

/etc/bootptab
/etc/bootpd.dump
/etc/services

Caveats:

Individual host entries must not exceed 1024 characters.

See also:

inetd

RFC 951, RFC 1048, RFC 1084, Assigned Numbers