The bootptab file is one of several text database files employed by joind, the BOOTP and DHCP server. The file's format is similar to that of the termcap(4) file.
There are three types of lines in this file: data, comments, and whitespace (for readability).
Data lines can be logically continued onto the next physical line by preceding the newline character with a backslash (\), but the backslash-newline pair is ignored elsewhere.
A comment has the number sign (#) as the first nonwhitespace character on a line that is not a logical continuation of a data line; in no other context is the number sign treated specially. Comments and blank lines are ignored when the file is parsed by joind but are preserved when editing with the xjoin GUI.
Data is organized into groups, the end of a group being identified by a newline. A data group begins with a label, an optional printable string and one or more colon-separated fields, each of which carries an identifying tag used to represent configuration parameters and the clients to which they apply.
label:tg=value. . . :tg:. . . :tg=value. . . .
The tags currently recognized by bootptab are listed in dhcptags(4).
The tg is a two-character tag symbol. If tg refers to a Boolean data type, it may stand alone to indicate the Boolean is on or true; it may also take the (case-insensitive) values true, false, on, or off. Other types require a value set off from the tag by an equals sign. Leading or trailing whitespace surrounding a text value is removed, but is retained if the string is enclosed in double quotes (the quotes are stripped internally). The following special syntax is also acceptable:
. . . :tg@:. . . .
There is also a generic tag, Tn, where n is an integer in the range 1-254. The value may be represented as either a stream of hexadecimal numbers or as a string of ASCII characters. If the numeric option is not found in the dhcptags file, the former interpretation is tried first; if an invalid hexadecimal digit is found, the second interpretation is used. The dhcptags file obviates the need to use this syntax, but it is supported for backward-compatibility.
In this section, when a reference is made to a specific option, that option is described by its standard two character identifier in the dhcptags file. These tags are identical to those in the Carnegie Mellon implementation of BOOTP, though DHCP defines wholly new options as well.
The label is a printable string that groups together the tags that follow the label and that can be referenced by the tc tag in other entries. It may be interpreted as a client host name in the following circumstances only: The data group refers to a specific BOOTP client The hostname ho tag is not explicitly used The string is a valid host name
Tags may appear in any order with one exception: the hardware type (ht) must precede the hardware address (ha) (either explicitly or implicitly; see the tc description). The ht tag specifies the hardware type code as either an unsigned decimal, octal, or hexadecimal integer or one of the following symbolic names:
|2||ethernet3||3 MB experimental Ethernet|
|4||pronet||Proteon ProNET Token Ring|
|6||token-ring||IEEE 802 networks|
The ha tag takes a value that (except when the type field is zero) is a hardware address specified in hexadecimal; optional periods, dashes, or colons may separate the octets for readability; a leading '0x' indicating hexadecimal data is also permissible. However, the common convention of using colons as octet delimiters conflicts with the use of that symbol as a field separator and requires that the address be enclosed in quotes.
When the type field is zero, it implies that the ha field will be used to match against a client identifier, a DHCP concept. The client identifier is an opaque object of arbitrary length, but may be a printable string. Therefore, in the case of ha, the value is first scanned as hexadecimal; if this scan does not succeed, the value is assumed to be a literal string and is used as such.
Within each data group, certain tags and the label determine how the database will be constructed and searched to resolve a particular client query. When the server starts, each data group is internally assigned to exactly one of 5 hash tables according to the presence of one or more of the following tags: network IP address vendor class hardware address/client identifier hardware type
The valid combinations are as follows:
The keys to the hash tables correspond to the values assumed by the tag or tags. A particular configuration for a client (both DHCP and BOOTP) is synthesized by searching these tables, in the order given, for a match that corresponds to data explicit or implied in the client's BOOTPREQUEST packet. Client parameters resolved earlier in the search take precedence over those resolved later. Thus, a client configuration is assembled by searching for parameters starting from most restrictive match to least. To support BOOTP clients in the manner to which they are accustomed, you can omit any data groups with the other keys. Any pre-existing bootptab file fulfills this requirement.
When the server tries to match a data group (partially) keyed by ht - ha to a specific client, it normally uses the client's hardware type and hardware address as sent in the htype and chaddr fields. DHCP clients may choose to identify themselves by the so-called client identifier option, which they explicitly send to the server. In this instance, the server tries to match to a key in the database by using the client identifier in place of the hardware address and using zero for the type. DHCP clients that choose to use this mechanism must do so consistently, and the data sent must constitute a unique identifier.
The client class (ct) is typically a string categorizing clients having attributes in common, such as the CPU architecture/operating system pair. Clients identify themselves as belonging to a particular class by sending this data to the server. A data group in the dhcpcap file is considered keyed with the class in either of the following ways: Explicitly by the presence of ct and its value Implicitly by the data group containing data items that are specific to a particular vendor
It is illegal for a data group to contain data items for two or more vendors (though it is permissible for standard tags to be combined with vendor tags). It is also illegal for a data group keyed to a specific class to refer to a data group of a different class with tc. Combinations missing in the list are redundant: for instance, the client ID always implies a particular vendor class, so there is no need for a hash having that pair as its key. If the data group contains tags that over-determine the key, the extraneous tags are ignored.
In addition to the internal tables, another table whose purpose is different is formed by a hash on the label. It allows a convenient shorthand by grouping subsets of parameters together and referencing them as an ensemble with the reference tag, tc. There may be more than one tc tag in a data group, and when encountered they are resolved. However, parameters that are explicitly named always take precedence over those implied by tc, regardless of their order within an entry. If two or more continuation tags are found, values resolved from the first named entity take precedence. The converse is true for other tags: if the same parameter is tagged twice, the last value is chosen.
Sometimes it is necessary to delete a specific tag after it has been implied by tc. This can be done using the construction tag @, which removes the effect of tag. 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 can be set again through the tc mechanism.
The remaining tags that imply special logic are described as follows:
The hd (home directory) and bf (bootfile) tags are ASCII strings. The client's request and the values of the hd and bf symbols determine how the server fills in the file field of the DHCP/BOOTP reply packet.
If the client specifies an absolute pathname and the file exists on the server machine, that pathname is returned in the reply packet. If the file cannot be found, no value is returned. If the client specifies a relative pathname, a full pathname is formed by prepending the value of the hd tag. If the hd tag is not supplied in the configuration file, no value is returned.
If the client sends a null value in the file field, the exact reply depends upon the hd and bf tags. If the bf tag gives an absolute pathname, that pathname is returned. 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 file field in the reply contains zeroes.
All filenames are first tried as filename.hostname and then as filename, providing for individual per-host bootfiles. The following table summarizes these possibilities:
|hd tag||bf tag||Received File||Returned File|
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. (For other tftpd file access restrictions, see tftp(1).)
Some versions of tftpd provide a security feature to change the root directory using the chroot(2) system call. You can use the td tag to inform the joind daemon of this special root directory used by the tftpd daemon. The hd tag is specified relative to any such root directory. For example, if the real absolute path to the client's bootfile is /tftpboot/bootfiles/bootimage, and tftpd uses /tftpboot as its secure directory, specify the following line in the bootptab file:
If the bootfile is located in the /tftpboot directory, use following line in the bootptab file:
You can use the sa or si tag to specify the IP address of the particular TFTP server the client is to use. In the absence of either tag, joind tells the client to perform TFTP to the same machine on which the joind daemon is running.
Three options, bs, to, and vm, permit the special string auto to be used as their value string.
The bootfile size (bs) is a decimal, octal, or hexadecimal integer specifying the size of the bootfile in 512-octet blocks. If the keyword auto is specified, the server should consult the file system to determine the size of the boot image. This assumes that the server is also the TFTP host for the client's boot image. As with the time offset, specifying the bs tag as a Boolean has the same effect as specifying auto as its value.
The time offset (to) is a signed decimal integer specifying the client's time zone offset in seconds from UTC. If the keyword auto is specified, the client should use the server's time zone offset. Specifying the to symbol as a Boolean has the same effect as specifying auto as its value.
The vendor magic cookie selector (vm) tells the server the style of option-encoding that the client wishes to receive. The tag can take one of the following keywords: Indicates that vendor information is determined by the client's request. Always forces an RFC 1048/RFC 1033-style reply. DHCP clients must always send the rfc1048 cookie or they will be treated as BOOTP clients. Always forces a CMU-style reply.
The encoding chosen is based primarily on the value of the magic cookie in the options field of the BOOTPREQUEST from the client. If it is present, the magic cookie must be either the rfc1048 cookie or the cmu cookie. If this cookie is not present, the server determines the encoding from the value of vm.
The following table summarizes the possibilities. None means that although the
vendor field is empty, the file and sname fields
are returned with the client's IP address.
bootprequest none rfc1048 cmu auto
unrecognized none rfc1048 cmu none
rfc1048 rfc1048 rfc1048 rfc1048 rfc1048
cmu cmu cmu cmu cmu
The remaining tags describe actual client configuration data. The bw, bx, cs, ds, gw, im, lg, lp, ns, nt, ra, rl, sr, ts, xd, and xs tags take a whitespace-separated list of IP addresses or hostnames, while the ba, ip, sa, si, sm, and sw tags each take a single IP address. The legal formats that may be used for character string representations of IP addresses are described in join.ipaddresses(4).
When a host name is specified instead of an IP address, the joind daemon looks up the IP addresses for that host name using the gethostbyname routine. If the ip tag is not specified, the joind 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.)
Since the gw tag is an extendible tagged subfield, you must also specify the vm=rfc1048 tag in order to pass the information to the client in an appropriate RFC 1048/RFC 1033-style reply.
For BOOTP usage, the label in the general file format is hostname, the name of a BOOTP client. 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. The recognized BOOTP tags are as follows: Boot file Boot file size (512 octet blocks) Cookie servers Dump file DNS domain name Domain name servers Encapsulate flavor Gateways (IP rosters) Hardware address Home directory Send host name Hardware type Impress servers Host or network IP address Log servers LPR servers IEN-116 name servers Reply address override Resource location protocol servers Root path TFTP server address (used by clients) Subnet mask (host) Swap server address Template host (points to similar host entry) TFTP root directory (used by secure TFTP server) Time offset (seconds) Time servers Vendor magic cookie selector
A sample bootptab for BOOTP support is as follows: # Sample bootptab file for BOOTP support
.default1:\ :hd=/usr/boot:bf=null:\ :ds=184.108.40.206 220.127.116.11:\ :ns=18.104.22.168 22.214.171.124:\ :ts=126.96.36.199 188.8.131.52:\ :sm=255.255.0.0:gw=184.108.40.206:\ :hn:vm=auto:to=-18000:\ :T37=0x12345927AD3DCF:T99="Special ASCII string":
carnegie:ht=6:ha=7FF8100000AF:ip=220.127.116.11:tc=.default1: baldwin:ht=1:ha=0800200159C3:ip=18.104.22.168:tc=.default1: wylie:ht=1:ha=00DD00CADF00:ip=22.214.171.124:tc=.default1: arnold:ht=1:ha=0800200102AD:ip=126.96.36.199:tc=.default1: bairdford:ht=1:ha=08002B02A2F9:ip=188.8.131.52:tc=.default1: bakerstown:ht=1:ha=08002B0287C8:ip=184.108.40.206:tc=.default1:
# Special domain name server for next host
bojct:ht=1:ha=08002001560D:ip=220.127.116.11:ds=18.104.22.168:tc=.default1: gastonville:ht=6:ha=7FFF81000A47:ip=22.214.171.124:tc=.default1: hahntown:ht=6:ha=7FFF81000434:ip=126.96.36.199:tc=.default1: hickman:ht=6:ha=7FFF810001BA:ip=188.8.131.52:tc=.default1: lowber:ht=1:ha=00DD00CAF000:ip=184.108.40.206:tc=.default1: mtoliver:ht=1:ha=00DD00FE1600:ip=220.127.116.11:tc=.default1:
Daemons: joind(8), tftpd(8)
DARPA Internet Request For Comments: DHCP Options and BOOTP Vendor Extensions (RFC 1533), Dynamic Host Configuration Protocol (RFC 1541) delim off