This document provides details of a DHCP bug exhibited by Android by a small number of devices. It provides information for individuals who would like detailed technical information about the issue.
We have seen the bug exhibited by a handful of Android devices since September 2010. It appears that only a very small set of devices may be affected.
DHCPv4, the Dynamic Host Configuration Protocol for IPv4, allows a device attached to the network to automatically learn some or all of its network configuration, including its IPv4 (Internet) address. Most operating systems include DHCP client software.
A device that uses DHCPv4 runs DHCP client software on a network (e.g., Ethernet or Wireless) interface. The DHCP client software contacts DHCP servers to obtain network configuration; in particular, it usually obtains a lease (a loan) of an IP address.
For example, the DHCP client tells the DHCP server "I am network interface 0:1:2:3:4:5; please lease an IP address to me." The DHCP server might respond "You may use IP address 192.168.1.2 for the next six hours; if you would like to continue using that address, please renew it when three hours have elapsed." When three hours have elapsed, the DHCP client contacts the DHCP server which granted the lease; the client asks that server to renew the lease Typically the DHCP server responds to the client: "You may use IP address 192.168.1.2 for the next six hours; if you would like to continue using that address, please renew it again when three hours have elapsed." (If the DHCP client is unable to contact the DHCP server to the renew its unexpired lease, it will retry from time to time, and is permitted to continue using the IP address until the lease is due to expire.)
Assuming the DHCP client successfully renews the lease before it expires, this repeats periodically until the device goes offline. Once the device is offline, it no longer contacts the DHCP server to renew the lease, so eventually the last lease renewal expires. Once the last lease renewal has expired, the DHCP server is free to lease the IP address to another client.
If the device goes offline, when it later comes back online it broadcasts a DHCP request for a new lease. It may choose to request a brand-new lease, or (if it believes the old lease has not yet expired) may request a new lease on the old IP address.
Some additional detail is needed to understand the particular issue described below.
When a DHCP client obtains a connection to the network, its DHCP client should start in the DHCP INIT state or the DHCP INIT-REBOOT state. Roughly speaking, the DHCP INIT-REBOOT state is used when the DHCP client believes it still has an unexpired DHCP lease, and would like the DHCP server to grant it a new lease on the the same IP address from the existing lease. The DHCP INIT state is used instead when the DHCP client wants a DHCP server to offer a new lease to the client.
If the DHCP client starts in the DHCP INIT state, the sequence of packet is typically as follows: The DHCP client broadcasts a DHCPDISCOVER message. One or more DHCP servers may respond with DHCPOFFER messages, each offering a lease to the client. Each of these DHCPOFFER messages includes the "DHCP Server Identifier" belonging to the DHCP server sending the offer. The client collects these offers, and selects one of them. The DHCP client broadcasts a DHCPREQUEST packet indicating which offer it wishes to select; the client is in the DHCP SELECTING state. This DHCPREQUEST packet specifies the "DHCP Server Identifier" value copied from the selected DHCPOFFER, along with other information copied from that offer. Assuming all is well, the DHCP server which made the offer responds with a DHCPACK message, granting the lease to the client.
Sometimes, the Android DHCP client malfunctions. It starts in the DHCP INIT state, broadcasting a DHCPDISCOVER. One or more DHCP servers respond with DHCPOFFERs. The client selects one of the offers, and broadcasts a DHCPREQUEST in the SELECTING state, indicating which offer it has selected. However, this DHCPREQUEST message is invalid.
Within this DHCPREQUEST message, the "DHCP Server Identifier" should contain a copy of the DHCP Server Identifier from the selected DHCPOFFER. Instead, the client inserts an invalid value in this field. To-date, each of the malfunction clients we have seen has specified one of the following invalid values: 255.0.0.0, 255.255.0.0.
Because the client's DHCPREQUEST specifies an invalid DHCP Server Identifier, no DHCP server responds to the DHCPREQUEST. The DHCP client is unable to obtain a lease. It eventually returns to the DHCP INIT state and tries again. This continues until the client stops malfunctioning, and begins working properly. Sometime later, the device resumes malfunctioning in the same way.
Princeton began seeing a verh small number of Android devices exibit this problem starting in September 2010. We recognized this as a pattern involving Android devices by early October 2010. By October 20 2010, we had seen four Android devices malfunction in this way.
Each of the devices we've detected exhibiting the bug have malfunctioned in this way repeatedly.
To help us better understand which Android platforms malfunction in this way, our customer support organization has begun asking owners of the malfunctioning devices the following information: Android version, device make and model. To-date, we have learned that one affected device is running Android 2.1 on a Samsung Epic 4G. We do not have information about the other three affected devices, but based upon hardware addresses, we suspect that they may also be Samsung devices.
We do not have enough data to file a bug with the Android project.
We will update this document when we have additional information.