Switch to SpeakEasy.net DSL

The Modular Manual Browser

Home Page
Manual: (OSF1-V5.1-alpha)
Apropos / Subsearch:
optional field

bootptab(4)							  bootptab(4)

  bootptab - BOOTP and DHCP server database


  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 whi-
  tespace 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 hex-
  adecimal digit is found, the second interpretation is	used.  The dhcptags
  file obviates	the need to use	this syntax, but it is supported for


  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

    +  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:

  Value	  Symbol       Hardware	Type
  0		       Client Identifier
  1	  ethernet     10MB Ethernet
  2	  ethernet3    3 MB experimental Ethernet
  3	  ax.25
  4	  pronet       Proteon ProNET Token Ring
  5	  chaos
  6	  token-ring   IEEE 802	networks
  7	  arcnet

  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 data-
  base 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 fol-
  lowing tags:

    network IP address

    vendor class

    hardware address/client identifier

    hardware type

  The valid combinations are as	follows:

  ht - ha - nw

  ht - ha

  nw - ct



  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 consti-
  tute 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 ven-
  dors (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 dif-
  ferent 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 pre-
  cedence.  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 configura-
  tion entry.  After removal with @, a tag can be set again through the	tc

  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

  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 summar-
  izes these possibilities:
  hd tag   bf tag   Received File   Returned File
  any	   any	    /c		    /c
  /a	   any	    /c		    /a/c
  any	   /b	    null	    /b
  /a	   /b	    null	    /a/b

  In all these cases, existence	of the file means that,	in addition to actu-
  ally 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 direc-
  tory 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 tag to specify the	IP address of the particular TFTP
  server the client is to use.	In the absence of this tag, joind tells	the
  client to perform TFTP to the	same machine on	which the joind	daemon is

  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 specify-
  ing 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

      Always forces an RFC 1048/RFC 1033-style reply.  DHCP clients must
      always send the rfc1048 cookie or	they will be treated as	BOOTP

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

				     bootptab file
	       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 rou-
  tine.	 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.

  BOOTP	Semantics

  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 recog-
  nized	BOOTP tags are as follows:

  bf  Boot file

  bs  Boot file	size (512 octet	blocks)

  cs  Cookie servers

  df  Dump file

  dn  DNS domain name

  ds  Domain name servers

  ef  Encapsulate flavor

  gw  Gateways (IP rosters)

  ha  Hardware address

  hd  Home directory

  hn  Send host	name

  ht  Hardware type

  im  Impress servers

  ip  Host or network IP address

  lg  Log servers

  lp  LPR servers

  ns  IEN-116 name servers

  ra  Reply address override

  rl  Resource location	protocol servers

  rp  Root path

  sa  TFTP server address (used	by clients)

  sm  Subnet mask (host)

  sw  Swap server address

  tc  Template host (points to similar host entry)

  td  TFTP root	directory (used	by secure TFTP server)

  to  Time offset (seconds)

  ts  Time servers

  vm  Vendor magic cookie selector


  A sample bootptab for	BOOTP support is as follows:

       # Sample	bootptab file for BOOTP	support

       :T37=0x12345927AD3DCF:T99="Special ASCII	string":


       # Special domain	name server for	next host





  Daemons: joind(8), tftpd(8)

  Files: dhcptags(4)

  DARPA	Internet Request For Comments: DHCP Options and	BOOTP Vendor Exten-
  sions	(RFC 1533), Dynamic Host Configuration Protocol	(RFC 1541)