Illustrated TCP/IP Illustrated TCP/IP
by Matthew G. Naugle
Wiley Computer Publishing, John Wiley & Sons, Inc.
ISBN: 0471196568   Pub Date: 11/01/98  

Previous Table of Contents Next


Chapter 308
Client Side (BOOTREQUEST)

The following is the series of steps taken by the client to build a BOOTREQUEST packet:

1.  The IP destination address (in the IP header, not the BOOTP fields) is set to 255.255.255.255. Optionally, it may set the address to the server’s IP address, if it is known.
2.  The IP source address is set to its IP address (if known); otherwise, it is set to 0.
3.  The UDP port numbers are set to 67 for UDP destination port (the server) and 68 for the UDP source port (the client).
4.  The op field is set to 1 (BOOT-REQUEST).
5.  The htype is set to the hardware address type (bit length) and the hlen is set to the length of the hardware address.
6.  xid is set to a random number.
7.  secs is set to the number of seconds that have elapsed since the client started booting.
8.  The ciaddr is set to an IP address of the client (if known); otherwise, it is set to 0 and the chaddr is set to the client’s hardware address.
9.  If the client wishes to restrict booting to a particular server name, it will set this name in the Sname field; otherwise, the Sname field is set to 0.
10.  The File field can be set to 0 to indicate to the server that it wishes to boot from the default file for its machine. Setting this field to 0 could also indicate that the client is interested in finding out client/server/gateway IP addresses and does not care about a file from which to boot. The field could be set to a simple generic name such as ipboot or unixboot, indicating that it wishes to boot the named program configured for the client. Finally, the field can be set to the full pathname of the server on which the boot file resides.
11.  The Vend field is set to whatever the vendor wishes. However, it is recommended that the first 4 bytes be set to a “magic” number (that is, you pick it). This allows the server to determine what kind of information it is seeing in this field.

If no reply is received by the client within a preset length of time, the client will retransmit the request up to an administered amount of times. The retransmission is regulated in that it will randomly send retransmission requests. This is to ensure that the network will not be flooded with requests should clients somehow sync their transmissions (purely by coincidence). Before retransmission, the Secs field is updated.


Client Side (BOOTREQUEST)


Previous Table of Contents Next