OIT Networking & Monitoring Services

Android DHCP Client in SELECTING State Specifies Invalid DHCP Server Identifier

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.

Contents

  1. What is DHCP?
  2. What is the Issue?
  3. How Has Princeton Handled This Issue?

What is DHCP?

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.


What is the Issue?

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.


How Has Princeton Handled This Issue?

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.

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.


A service of OIT Networking & Monitoring Services
The Office of Information Technology,
Princeton University
Last Updated: September 18 2013