/etc/bootptab

Boot protocol server configuration file

Name:

/etc/bootptab

Description:

The /etc/bootptab file is used by the bootpd daemon.

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. This can be:

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

If bs is specified as a boolean, auto is assumed.

cs

Cookie server address list (a whitespace-separated list of IP addresses).

ds

Domain name server address list (a whitespace-separated list of IP addresses).

gw

Gateway address list (a whitespace-separated list of IP addresses).

ha

Host hardware address. This 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).

hd

Bootfile home directory.

hn

Send hostname. This 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's specified in the configuration file. If the name doesn't fit into the reply packet, it's shortened to just the host field (up to the first period, if present) and then tried. The server never sends an arbitrarily truncated hostname (if nothing reasonable fits, nothing is sent).

ht

Host hardware type (see Assigned Numbers RFC). This tag specifies the hardware type code as either an unsigned decimal, octal, or hexadecimal integer or as one of the following symbolic names:

• ethernet or ether for 10M Ethernet
• ieee802, tr, or token-ring for IEEE 802 networks.

im

Impress server address list (a whitespace-separated list of IP addresses).

ip

Host IP address (a single IP address).

lg

Log server address list (a whitespace-separated list of IP addresses).

lp

LPR server address list (a whitespace-separated list of IP addresses).

ns

IEN-116 name server address list (a whitespace-separated list of IP addresses).

rl

Resource location protocol server address list (a whitespace-separated list of IP addresses).

sa

TFTP server address the client should use (useful with multi-homed servers). This tag takes a whitespace-separated list of IP addresses.

sm

Host subnet mask (a single IP address).

tc

Table continuation (points to similar “template” host entry).

td

TFTP root directory used by secured TFTP server.

to

Time offset. This can be:

• a signed decimal integer specifying the client's timezone offset (in seconds from UTC)

  Or

• the keyword auto, which uses the server's timezone offset.

If to is specified as a boolean, auto is assumed.

ts

Time server address list (a whitespace-separated list of IP addresses).

vm

Vendor magic cookie selector. This can be one of the following keywords:

• auto (indicating that vendor information is determined by the client's request)
• rfc1048 (which always forces an RFC 1048-style reply)
• cmu (which always forces a CMU-style reply).

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.

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 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 always elicit a reply from the server. The exact reply again depends 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 contains 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.

---

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. You can do this by 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, 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 a pound sign (#) 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:

• the hostname must be the very first field in an entry
• the hardware type must precede the hardware address.

Here's a sample /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:

• bootps — the bootp server listening port
• bootpc — the destination port used to reply to clients.

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

Caveats:

As a QNX Neutrino extension, the argument to the bf tag can start with an “or bar” character (|). If it does, then the following is taken to be a command to spawn in order to get a boot image:

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

If you use this extension, tftpd must not be started as root. One choice is to create the user tftp and start tftpd as that user. You could also create and use the user ftp, but that opens up your machine to anonymous ftp. For information on how to change the user as which tftpd starts, see /etc/inetd.conf.

See also:

bootpd