BOOTP(1M) — Silicon Graphics January 12, 1987
NAME
bootp − server for DARPA Bootstrap Protocol (BOOTP)
SYNOPSIS
/usr/etc/bootp [ −d ] [ −f ]
DESCRIPTION
Bootp is a server which supports the DARPA Bootstrap Protocol (BOOTP). This protocol is designed to allow a (possibly diskless) client machine to determine its own Internet address, the address of a boot server and the name of an appropriate boot file to be loaded and executed. BOOTP does not provide the actual transfer of the boot file, which is typically done with a simple file transfer protocol such as TFTP. A detailed protocol specification for BOOTP is contained in RFC 951, which is available from the Network Information Center.
The BOOTP protocol uses UDP/IP as its transport mechanism. The BOOTP server receives service requests at the UDP port indicated in the “bootp” service description contained in the file /etc/services (see services(4)). The BOOTP server is started by inetd(1M), as configured in the inetd.conf file.
The basic operation of the BOOTP protocol is a single packet exchange as follows:
1)The booting client machine broadcasts a BOOTP request packet to the BOOTP server UDP port, using a UDP broadcast. The request packet includes the following information:
requestor’s Ethernet address
requestor’s Internet address (optional)
desired server’s name (optional)
boot file name (optional)
2)All the BOOTP servers on the same Ethernet wire as the client machine receive the client’s request. If the client has specified a particular server, then only that server will respond.
3)The server looks up the requestor in its configuration file by Internet address or Ethernet address, in that order of preference. (The BOOTP configuration file is described below.) If the Internet address was not specified by the requestor and a configuration record is not found, the server will look in the /etc/ethers file (see ethers(4)) for an entry with the client’s Ethernet address. If an entry is found, the server will check the hostname of that entry against the /etc/hosts file (see hosts(4)) in order to complete the Ethernet address to Internet address mapping. If the BOOTP request does not include the client’s Internet address and the server is unable to translate the client’s Ethernet address into an Internet address by either of the two methods described, the server will not respond to the request.
4)The server performs name translation on the boot filename requested and then checks for the presence of that file. If the file is present, then the server will send a response packet to the requestor which includes the following information:
the requestor’s Internet address
the server’s Internet address
the Internet address of a gateway to the server
the server’s name
vendor specific information (not defined by the protocol)
If the boot file is missing, the server will return a response packet with a null filename, but only if the request was specifically directed to that server. The pathname translation is: if the boot filename is rooted, use it as is; else concatenate the root of the boot subtree, as specified by the BOOTP configuration file, followed by the filename supplied by the requestor, followed by a period and the requestor’s hostname. If that file is not present, remove the trailing period and host name and try again. If no boot filename is requested, use the default boot file for that host from the configuration table. If there is no default specified for that host, use the general default boot filename, first with .hostname as a suffix and then without.
Options
The −d option causes bootp to generate debugging messages. All messages from bootp go through syslogd(1M), the system logging daemon.
The −f option enables the forwarding function of bootp. Refer to the following section on Booting Through Gateways for an explanation.
Bootp Configuration File
In order to perform its name translation and address resolution functions, bootp requires configuration information, which it gets from an ASCII file called /usr/etc/bootptab and from other system configuration files like /etc/ethers and /etc/hosts. Here is a sample bootptab file:
#
# /usr/etc/bootptab: database for bootp server
#
# Blank lines and lines beginning with ’#’ are ignored.
#
# root of boot subtree
/usr/local/boot
# default bootfile
vmunix
%%
#
# The remainder of this file contains one line per client interface
# with the information shown by the table headings below.
# The ’host’ name is also tried as a suffix for the ’bootfile’
# when searching the boot directory. (e.g., bootfile.host)
#
# hosthtypehaddriaddrbootfile
#
turbo11:2:3:4:99:aa89.0.0.13000.tcp
unixbox11:2:3:4:bb:cc89.0.0.2
The fields of each line may be separated by variable amounts of white space (blanks and tabs). The first section, up to the line beginning ’%%’, defines the place where bootp looks for boot files when the client requests a boot file using a non-rooted pathname. The second section of the file is used for mapping client Ethernet addresses into Internet addresses. The htype field should always have a value of 1 for now, which indicates that the hardware address is a 48-bit Ethernet address. The haddr field is the Ethernet address of the system in question expressed as 6 hex bytes separated by colons. The iaddr field is the 32-bit Internet address of the system expressed in standard dot notation (4 byte values in decimal, in network order, separated by periods). Each line in the second section can also specify a default boot file for each specific host. In the example above, if the host turbo sends a BOOTP request with no boot filename specified, the server will look for the following files and select the first one that it finds:
/usr/local/boot/3000.tcp.turbo
/usr/local/boot/3000.tcp
If the host called unixbox makes a BOOTP request with no boot file specified, the server will select the first of the following that it finds:
/usr/local/boot/vmunix.unixbox
/usr/local/boot/vmunix
It is not necessary to create a record for every potential client in every bootptab file. The only constraint is that bootp will only respond to a request from a client if it can deduce the client’s Internet address. There are three ways that this can happen: 1) the client already knows his Internet address and includes it in the BOOTP request packet, 2) there is an entry in /usr/etc/bootptab that matches the client’s Ethernet address or 3) there are entries in the /etc/ethers and /etc/hosts files (or their Yellow Pages equivalents) that allow the client’s Ethernet address to be translated into an Internet address.
Booting Through Gateways
Since the BOOTP request is distributed using a UDP broadcast, it will only be received by other hosts on the same Ethernet cable as the client. In some cases the client may wish to boot from a host on another network. This can be accomplished by using the forwarding function of BOOTP servers on the local wire. To use BOOTP forwarding, there must be a bootp process running in a gateway machine on the local cable. A gateway machine is simply a machine with more than one Ethernet controller board. The gateway bootp must be invoked with the −f option to activate forwarding. Such a forwarding bootp will resend any BOOTP request it receives that asks for a specific host by name, if that host is on a different network from the client that sent the request. The BOOTP server forwards the packet using the full routing capabilities of the underlying IP layer in the kernel, so the forwarded packet will automatically be routed to the requested BOOTP server provided that the kernel routing tables contain a route to the destination network.
DIAGNOSTICS
The BOOTP server sends any messages it wants to reach the outside world through the system logging daemon, syslogd(1M). The actual disposition of these messages depends on the configuration of syslogd on the machine in question. Consult syslogd(1M) for further information.
Bootp can produce the following messages:
’get interface config’ ioctl failed (message)
’get interface netmask’ ioctl failed (message)
getsockname fails (message)
forwarding failed (message)
send failed (message)
set arp ioctl failed
Each of the above messages mean that a system call has returned an error unexpectedly. Such errors usually cause bootp to terminate. The message will be the result of calling perror(3C) with the errno value that was returned.
less than two interfaces, −f flag ignored
Warning only. Means that the −f option was specified on a machine that is not a gateway. Forwarding only works on gateways.
request for unknown host xxx from yyy
Information only. A BOOTP request was received asking for host xxx, but that host is not in the host database. The request was generated by yyy, which may be given as a host name or an Internet address.
request from xxx for ’fff’
Information only. Bootp logs each request for a boot file. The means that host xxx has requested boot file fff.
boot file fff missing
A request has been received for the boot file fff, but that file doesn’t exist.
replyfile fff
Information only. Bootp has selected the file fff as the boot file to satisfy a request.
forward request with gateway address already set (dd.dd.dd.dd)
The server has received a reply to be forwarded to a requestor, but some other bootp has already filled himself in as the gateway. This is an error in the BOOTP forwarding mechanism.
missing gateway address
This means that this bootp has generated a response to a client and is trying to send the response directly to the client (i.e. the request did not get forwarded by another bootp), but none of the Ethernet interfaces on this machine is on the same wire as the client machine. This indicates a bug in the BOOTP forwarding mechanism.
can’t open /usr/etc/bootptab
The bootp configuration file is missing or has wrong permissions.
(re)reading /usr/etc/bootptab
Information only. Bootp checks the modification date of the configuration file on the receipt of each request and rereads it if it has been modified since the last time it was read.
bad hex address: xxx at line nnn of bootptab
bad internet address: sss at line nnn of bootptab
string truncated: sss, on line nnn of bootptab
These messages all mean that the format of the BOOTP configuration file is not valid.
’hosts’ table length exceeded
There are too many lines in the second section of the BOOTP configuration file. The current limit is 512.
can’t allocate memory
A call to malloc(3C) failed.
gethostbyname(sss) fails (message)
A call to gethostbyname(3N) with the argument sss has failed.
gethostbyaddr(dd.dd.dd.dd) fails (message)
A call to gethostbyaddr(3N) with the argument dd.dd.dd.dd has failed.
can’t find source net for address xxx
This means that the server has received a datagram with a source address that doesn’t make sense. The offending address is printed as a 32 bit hexadecimal number xxx.
SEE ALSO
inetd(1M), syslogd(1M), tftpd(1M), ethers(4), hosts(4), services(4)
Version 3.6 — December 20, 1987