Linux Remote Booting Contents Page

Theory

As stated in the introduction section, the three network services necessary for remote booting are BOOTP, TFTP, and NFS. This section will examine the theory of how this works in more detail, and look at other networking issues affecting their capabilities. The boot process is started with the diskless computer.

Hardware and Firmware

The diskless computer must have a network interface card (NIC) on board. This card can be one of several types which Linux will support. Testing has been done using the following cards:

  1. 3c905B 3com
  2. 3c90x vortex 3com
  3. NE2000 compliant ISA (generic)

ISA NE2000 cards which are leftovers or cost under $10 have been tested successfully with remote booting. The remote computers must have an onboard NIC containing a PROM program that supports BOOTP. Prior to programming the PROM, this program may be placed on floppy for testing purposes if a floppy drive is available on the remote computer.

Why not use RARP?

RARP is not used for two reasons.

  1. It uses broadcasting and therefore cannot operate across networks since broadcast messages are not forwarded by a router.
  2. A diskless computer needs more information than just it's IP address. It needs a server address and name of a file. It will download the file from the specified server. This is necessary so the diskless computer can get a file containing an operating system.

BOOTP

BOOTP messages are is encapsulated inside UDP messages and therefore it's requests and replies are forwarded by routers that have BOOTP/DHCP relay agents installed. The drawing below illustrates the data encapsulation:

BOOTP data encapsulation

The diskless system reads its unique hardware address from its network interface card then sends a BOOTP request. The table below shows the BOOTP package format from most significant bit to least significant bit.

Bit range# of BitsNameDescription
0-78OpcodeTells if the message is a BOOTP request or reply. Request=1, reply=2
8-158Hardware typeIndicates the type of hardware (link level). A value of 6 indicates ethernet
16-238Hardware address lengthTells the length in bytes of the hardware address number. Ethernet addresses are 6 bytes long.
23-318Hop countInitially set to 0. Incremented each time it is forwarded.
32-6332Transaction IDA random number set by the client and returned by the server. Used to match replies with requests
64-7916Number of secondsThe time since the client started trying to bootstrap. Used to tell if a backup BOOTP server should respond.
80-9516unusednot used
96-12732Clients IP addressThe clients IP address. If a request, it is normally 0.0.0.0
128-15932IP address for clientThe server sets this in the reply message.
160-19132Server IP addressFilled in by the server.
192-22332Gateway IP addressReturned by the server.
224-351128Clients hardware addressProvided by the client.
352-13751024Server hostnameA null terminated string optionally filled in by the server.
1376-34232048Boot filenameA fully qualified boot file name with path information, terminated with a null. Supplied by the server.
3424-44471024Vendor informationUsed for various options to BOOTP including the subnet mask to the client.

The BOOTP server uses port 67 and the BOOTP client uses port 68. The following is a brief explanation of what happens when a remote client boots:

  1. BOOTP request. The client sends a BOOTP request from 0.0.0.0.68 to 255.255.255.255.67 with its ethernet address and number of second's fields filled in.
  2. BOOTP reply. The server responds with the client's IP address, the server's IP address (it's own), and the IP address of a default gateway.
  3. ARP request. The client issues an ARP to tell if the IP address it just received is being used. It uses 0.0.0.0 as it's own address
  4. ARP request. The client waits 0.5 seconds and repeats the same ARP request.
  5. ARP request. The client waits another 0.5 seconds and repeats the ARP request with it's own address as the senders address.
  6. BOOTP request. The client waits 0.5 seconds and sends another BOOTP request with its own IP address in the IP header
  7. BOOTP reply. The server sends the same BOOTP reply it sent the last time.
  8. ARP request. The client outputs an ARP request for the server hardware address
  9. ARP reply. The server replies with its own ethernet address.
  10. TFTP read request. The client sends a TFTP read request asking for its specified boot file.

TFTP

Trivial file transfer protocol ((TFTP) uses port 69. Trivial file transfer protocol (TFTP) is similar to FTP, but more compact and requires no login. TFTP uses the UDP protocol to keep it small for use by diskless workstations. Some have had security concerns with TFTP, but it appears that security with TFTP has been greatly improved lately. This is because TFTP can be set up so access outside a specified directory will be denied. In fact the TFTP client cannot execute a directory command or have any way to search outside its single directory. In spite of this, it is still not generally recommended to assume TFTP is fully secure. It is therefore recommended that a TFTP server not be used to store sensitive data. The TFTP message block begins with an opcode which will be set to one of the following values:

  1. RRQ=1. Read request.
  2. WRQ=2. Write request.
  3. Data=3. File data being transferred.
  4. ACK=4. Acknowledge of data received.
  5. Error=5. Data error.

The TFTP datagram with a RRQ or WRQ opcode will contain a filename with a null terminator, and mode. The mode is a string "netascii" or "octet" terminated by a null character. Octet means the data is 8bit bytes of data and netascii means the data is ASC text. All data packets (opcode=3) have a block number that is later used in the acknowledgement (opcode=4). During a transfer, the following happens:

  1. The client sends a read request for a given file.
  2. The server responds with a data packet of 512 bytes. (Assuming the file request was allowed)
  3. The client acknowledges the data packet
  4. The above two steps are repeated until the client receives a data packet smaller than 512 bytes, meaning the end of file has been reached.

NFS

Network File System (NFS) uses Remote Procedure Protocol (RPC) and the UDP protocol. NFS is a method used by UNIX and Linux computers to share filesystems over a network.

Linux Remote Booting Contents Page