This document provides details of a DHCP bug exhibited by Android on a wide variety of devices. It provides information for individuals who would like detailed technical information about the issue.
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. 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 (typically, the IP address of the DHCP server) which made the offer, and the IP address of the offered IP address. Assuming all is well, the DHCP server which made the offer responds with a DHCPACK message, granting the lease to the client.
When a device running Android connects to the wireless network, its DHCP client should start in the DHCP INIT state or the DHCP INIT-REBOOT state.
Sometimes, the Android DHCP client malfunctions; it starts in the DHCP SELECTING state instead of the DHCP INIT or INIT-REBOOT state. (The client broadcasts a DHCPREQUEST of the flavor that is only used by a DHCP client in the SELECTING state. That is, the "DHCP Server Identifier" option is present in the DHCPREQUEST.) That doesn't appear to make sense; no DHCP server recently offered a lease to the client.
The "Requested IP Address" and "DHCP Server Identifier' specified in this DHCPREQUEST packet falls into one of the following categories:
If the DCHP Server Identifier specified in the DHCPREQUEST's "DHCP Server Identifier" is one of the DHCP servers for the network to which the device is attached, when it receive the erroneous DHCPREQUEST, it logs the error so that a technician may review it to determine if there is a problem affecting network service. The DHCP server knows that it did not offer the requested IP address to the client, so responds to the client with a DHCPNAK message. This indicates that the DHCP server is unwilling to grant the request. When the DHCP client receives the DHCPNAK message, the DHCP client enters the DHCP INIT state. Once in the DHCP INIT state, it performs DHCP normally.
If the DCHP Server Identifier specified in the DHCPREQUEST's "DHCP Server Identifier" is not one of the DHCP servers for the network to which the device is attached, no DHCP server responds to the client.
A handful of the devices that exhibit the bug sometimes go as far as to send a burst of these invalid DHCPREQUEST packets each time they connect to the network, claiming to have received offers for a set of IP addresses from a set of DHCP servers, none of which correspond to the network to which the device is presently attached.
In most cases, the Android client gives up trying to SELECT a non-existant lease offer, then enters the DHCP INIT or INIT-REBOOT state, and is able to obtain a valid lease at that time. However, the next time it connects to the network, it may again exibibit the same bug.
In some cases, the Android client does this at the same time it has a legitimate DHCP lease from our DHCP servers. At the same time it has that legitimate lease, it persistently sends these erroneous DHCPREQUEST packets attempting to SELECT non-existant offers for a variety of other IP addresses for non-existant offers. When the client keeps sending these erroneous DHCPREQUEST packets throughout the time it is connected, the ongoing DHCP broadcast packets degrade network service, both because they unecessarily load the DHCP servers, and because they contribute unecessary broadcast traffic to the network.
In a few cases, the Android client remains in the SELECTING state, and is never able to obtain a valid DHCP lease. Eventually, the Android devices disconnects from the wireless network. When it next reconnects, the same problem may happen again. Because it is never able to obtain a valid DHCP lease, it keeps retrying. The ongoing DHCP broadcast packets degrade network service, both because they unecessarily load the DHCP servers, and because they contribute unecessary broadcast traffic to the network.
A fraction of the devices that exhibit the bug also sometimes briefly "steal" the IP address at the same time they erroneously try to SELECT the non-existant DHCP lease. They send an ARP packet claiming that the IP address belongs to the device. This interferes with service to any other device presently leased that IP address, if the stolen IP address is indeed one that is part of the IP network to which the device is presently attached.
Princeton began seeing a 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. Since that time, we have continued to see a growing number of 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 asked owners of the malfunctioning devices the following information: Android version, device make and model. Once it became clear to us that the problem is widespread, we stopped asking out support staff to collect this information.
On October 21 2010, we filed a bug report with Google, the vendor responsible for the Android operating system. Our bug report is assigned issue #12066. Through September 18 2013, we saw no response from Google.
In those cases where the device exhibiting this bug was degrading network service (because it keeps broadcasting these erroneous DHCPREQUEST packets without end), Princeton blocked the device from our network. We advise the customer of the problem. Once blocked, if the device has a cellular network interface, the device can still be used with the customer's cellular network provider, of course. If it was not practical to contact the customer (for example, because the device is using our visitor wireless service and the owner is anonymous), we blocked that individual device from our network without contacting the customer. If at a later time it became practical to contact the customer (for example, because the customer registered the device in the University's Host Database), we contacted the customer to advise him or her of the problem.
Since the time we detected this bug, Princeton University re-architected our wireless networks to accomodate wireless growth. One of the side effects of these changes is that we are no longer able to detect and troubleshoot these kinds of problems on our wireless networks. Previously, each of our wireless networks used DHCP servers we had instrumented to help us to detect this issue. Now most of our wireless networks use commodity DHCP servers, because those servers are rated to handle higher DHCP transaction rates than our instrumented DHCP servers. A side-effect of the shift from instrumented DHCP servers to commodity DHCP servers is that we no longer have the DHCP server instrumentation to detect wireless clients malfunctioning in various ways, including the way described in this document. The upshot is that as a side-effect of the the network changes we made starting in September 2012, we are no longer able to detect these kinds of malfunctioning wireless clients.