DHCP (“Dynamic Host Configuration Protocol”) is a protocol for IPv4 autoconfigura- tion that is widely used on the Internet and in local area networks. DHCP is an open standard specified in RFC 2131 [26].
DHCP is a client-server protocol concerned with two types of actors:
• DHCP clients, which are hosts attempting to obtain an IPv4 networking configu-
ration.
• DHCP servers, which keep track of the state of one or more subnets and assign
A typical DHCP session proceeds as follows:
1. A DHCP client broadcasts a DHCPDISCOVER message on the network to an- nounce its interest in joining an IPv4 network. The DHCPDISCOVER is sent to the hardware broadcast address because no Internet-layer information is available. 2. The DHCP server responds with a DHCPOFFER message to offer an IPv4 net- working configuration to the DHCP client. The offered IPv4 networking configu- ration must include an IPv4 address that is not currently known to be in use on the network.
3. The DHCP client sends a DHCPREQUEST message to accept an offer from a DHCP server.
4. The DHCP server responds with DHCPACK to confirm to the client that it has committed the reservation of the IPv4 networking configuration being assigned to the client.
The above is a simplified description and does not cover certain aspects, such as DHCP forwarding and rebinding DHCP leases. A full state diagram for DHCP as well as the formats of the protocol messages can be found in RFC 2131 [26]. Since DHCP is a widely deployed, well-documented protocol, there is little reason to document it in full in this thesis.
Although a DHCP client was available for a prior version of Embedded Xinu, it contained various problems and flaws, including:
• The old DHCP client was not source-compatible with the current version of
Embedded Xinu, primarily due to changes in the network subsystem that occurred before I started working with the code.
• The old DHCP client did not re-send DHCPDISCOVER packets if no DHCPOFFER
was received in a certain amount of time. In other words, it was not sufficiently tolerant of networking problems such as packet loss.
• Although the old DHCP client provided access to the IP address, netmask, and
gateway assigned by the DHCP server, it did not provide access to the bootfile name and TFTP server IP address. The latter two pieces of information are used specifically in network booting and therefore needed to be supported in order to implement a network bootloader.
• The old DHCP client duplicated code among the different DHCP request and
reply handlers, thereby making it more difficult to fix other problems. Since all DHCP messages share the same basic format, it makes more sense to share parts of the code.
xsh$ netup ETH0
Trying DHCP on ETH0...
ETH0 is 192.168.1.72 with netmask 255.255.255.0 (gateway 192.168.1.1)
Figure 10: An example of using the Xinu shell to bring up a network interface using DHCP autoconfiguration. This only works if there is a DHCP server (not included with Embedded Xinu) running on a separate host on the network.
Consequently, I rewrote the DHCP client and added it to the current version of Embedded Xinu. It is now located in the network/dhcpc directory and is divided into the following functions, each of which is located in the same-named source file:
• dhcpClient(), which is the external interface to the DHCP client. As input, it
requires the device descriptor for the network device on which to open the DHCP client (such as ETH0) and the number of seconds to attempt DHCP before timing out. As output, it produces the assigned IPv4 address, netmask, and gateway, as well as the bootfile name and IPv4 address of the “next” (TFTP) server if provided by the DHCP server.
• dhcpSendRequest(), which is used internally by dhcpClient() to send
DHCPDISCOVERand DHCPREQUEST messages.
• dhcpRecvReply(), which is used internally by dhcpClient() to wait for
an appropriate reply from a DHCP server.
Between requests and replies, the DHCP client stores its state in an instance of struct dhcpData. The code in the top-level dhcpClient() function resembles a state machine, as per the design of DHCP described in RFC 2131 [26].
In a network booting setup, the administrator of the DHCP server must configure the DHCP server to tell DHCP clients where to download the boot file (the new kernel). This information consists of the file (bootfile) and siaddr (next-server IPv4 address) fields that DHCP offers and acknowledgments contain. This information is returned by dhcpClient() if it was provided by the DHCP server. Consequently, it becomes available for the network bootloader to use in the next part of network bootloading, which uses TFTP to download the specified boot file from the specified server.
Although used as part of the standard network booting process, DHCP is designed for general IPv4 network autoconfiguration and is widely used for this purpose. Because of this, it was also pertinent to use dhcpClient() to implement DHCP support in the netup shell command. Example usage of this feature is shown in Figure 10.
Since Embedded Xinu’s test suite is standalone and I did not implement a DHCP server for Embedded Xinu, it was not realistic to implement automated tests of the DHCP client. However, I tested the DHCP client manually by running the netup command as shown in Figure 10. To do this, I started the standard dnsmasq DHCP
server on another computer (running a Linux-based operating system), connected the Raspberry Pi (running Embedded Xinu) via Ethernet, and ran netup from the Embedded Xinu shell. This resulted in a successful DHCP transaction, and dnsmasq did not report any errors or warnings. I also tested that the DHCP client correctly timed out when no DHCP server responded. Furthermore, I tested that the DHCP client still worked correctly with its source code modified to drop random packets.