5.3   BOOTP, Bootstrap Protocol

BOOTP is a basic bootstrap protocol implemented on top of the Internet User Datagram Protocol (UDP). The BOOTP client provided with VxWorks lets a target retrieve a single set of configuration parameters from a BOOTP server. Included among these configuration parameters is a permanently assigned IP address and a file name specifying a bootable image. To retrieve the boot file, the target can use a file transfer program, such as TFTP, FTP, or RSH.1


*

NOTE: For many applications, the DHCP protocol can function as an alternative to BOOTP.

BOOTP offers centralized management of target boot parameters on the host system. Using BOOTP, the VxWorks target can retrieve the boot parameters stored on a host system. This lets you set up VxWorks systems that can automatically reboot without the need to enter the configuration parameters manually.

A BOOTP server must be running (with inetd on a UNIX system) on the boot host, and the boot parameters for the target must be entered into the BOOTP database (bootptab). The format of this database is server specific. An example bootptab file is described in About the BOOTP Database.

BOOTP is a simple protocol based on single-packet exchanges. The client transmits a BOOTP request message on the network. The server gets the message, and looks up the client in the database. It searches for the client's IP address if that field is specified; if not, it searches for the client's hardware address.

If the server finds the client's entry in the database, it performs name translation on the boot file, and checks for the presence (and accessibility) of that file. If the file exists and is readable, the server sends a reply message to the client.

5.3.1   BOOTP Configuration

Using the BOOTP server to supply boot parameters requires that you edit the server's BOOTP database file, bootptab. However, the specifics of how to do this can vary from server to server. Refer to the manuals for your host's BOOTP server. If the host does not provide a BOOTP server as part of the operating system, a copy of the publicly available CMU BOOTP server is provided in target/unsupported/bootp2.1.

The following discussion of how to modify bootptab applies to the CMU BOOTP server.

About the BOOTP Database

To register a VxWorks target with the BOOTP server, you must enter the target parameters in the host's BOOTP database (/etc/bootptab). The following is an example bootptab for the CMU version of the BOOTP server:

# /etc/bootptab: database for bootp server (/etc/bootpd) 
# Last update Mon 11/7/88 18:03 
# Blank lines and lines beginning with '#' are ignored. 
# 
# Legend: 
# 
#    first field -- hostname 
#             (may be full domain name and probably should be) 
# 
#    hd -- home directory 
#    bf -- boot file 
#    cs -- cookie servers 
#    ds -- domain name servers 
#    gw -- gateways 
#    ha -- hardware address 
#    ht -- hardware type 
#    im -- impress servers 
#    ip -- host IP address 
#    lg -- log servers 
#    lp -- LPR servers 
#    ns -- IEN-116 name servers 
#    rl -- resource location protocol servers 
#    sm -- subnet mask 
#    tc -- template host (points to similar host entry) 
#    to -- time offset (seconds) 
#    ts -- time servers 
# 
# Be careful to include backslashes where they are needed. Weird (bad) 
# things can happen when a backslash is omitted where one is intended. 
# 
# First, we define a global entry which specifies what every host uses. 
 
global.dummy:\ 
:sm=255.255.255.0:\ 
:hd=/usr/wind/target/vxBoot:\ 
:bf=vxWorks: 
 
vx240:ht=ethernet:ha=00DD00CB1E05:ip=150.12.1.240:tc=global.dummy 
vx241:ht=ethernet:ha=00DD00FE2D01:ip=150.12.1.241:tc=global.dummy 
vx242:ht=ethernet:ha=00DD00CB1E02:ip=150.12.1.242:tc=global.dummy 
vx243:ht=ethernet:ha=00DD00CB1E03:ip=150.12.1.243:tc=global.dummy 
vx244:ht=ethernet:ha=0000530e0018:ip=150.12.1.244:tc=global.dummy

Note that common data is described in the entry global.dummy. Any target entries that want to use the common data use tc=global.dummy. Any target-specific information is listed separately on the target line. For example, in the previous file, the entry for the target vx244 specifies only its Ethernet address (0000530e0018) and IP address (150.12.1.244). The subnet mask (255.255.255.0), home directory (/usr/wind/target/vxBoot), and boot file (vxWorks) are taken from the common entry global.dummy.

Editing the BOOTP Database to Register a VxWorks Target

To register a VxWorks target with the BOOTP server, log onto the host machine, edit the BOOTP database file to include an entry that specifies the target address (ha=), IP address (ip=), and boot file (bf=). For example, to add a target called vx245, with Ethernet address 00:00:4B:0B:B3:A8, IP address 150.12.1.245, and boot file /usr/wind/target/vxBoot/vxWorks, you would add the following line to the file:

vx245:ht=ethernet:ha=00004B0BB3A8:ip=150.12.1.245:tc=global.dummy

Note that you do not need to specify the boot file name explicitly. The home directory (hd) and the boot file (bf) are taken from global.dummy.

When performing the boot file name translation, the BOOTP server uses the value specified in the boot file field of the client request message as well as the bf (boot file) and the hd (home directory) field in the database. If the form of the file name calls for it (for example, if it is relative), the server prefixes the home directory to the file name. The server checks for the existence of the file; if the file is not found, it sends no reply. For more information, see bootpd in the manual for your host.

When the server checks for the existence of the file, it also checks whether its read-access bit is set to public, because this is required by tftpd(8) to permit the file transfer. All file names are first tried as filename.hostname and then as filename, thus providing for individual per-host boot files.

In the previous example, the server first searches for the file /usr/wind/target/vxBoot/vxWorks.vx245. If the file does not exist, the server looks for /usr/wind/target/vxBoot/vxWorks.


1:  For the complete BOOTP protocol specification, see RFC 951 "Bootstrap Protocol (BOOTP)," RFC 1542 "Clarifications and Extensions for BOOTP," and RFC 1048 "BOOTP Vendor Information Extensions."