This document provides details of a DHCP bug exhibited by Apple iOS® versions 4.1 - 6.1.
This document provides information for individuals who would like detailed technical information about the issue.
The bug can cause the iOS device to disrupt service for other devices on the network from time to time.
Princeton University reported the bug to Apple, and worked with Apple to try to resolve the issue.
The last version of iOS we tested for this bug was version 6.1. The bug was still present in iOS 6.1. Although the bug had not been fixed through iOS version 6.1, other changes in iOS result in the bug not having an opportunity to trigger when the DHCP lease time is of sufficient duration. Starting in iOS 5.0, DHCP lease times of 60 minutes or more effectively hide the bug. And starting in iOS 5.1, DHCP lease times of 30 minutes or more effectively hide the bug. We are not testing versions iOS 6.1.1 or later to learn if the bug has ever been fixed, or if the behavior described in this document has changed in versions of iOS newer than 6.1.
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.
Under certain circumstances, the affected versions of Apple iOS do not renew the DHCP lease before the lease is due to expire. iOS allows the DHCP lease to expire, but continues using the IP address after that time. Although the owner of the device may not realize there is a problem, this interferes with service to others on the network. This continues until the device chooses to request a new DHCP lease, or the device disconnects from the network.
The device may exhibit this issue when the following requirements are met simultaneously:
The requirements above raise the question: "In what situations does a sleeping iOS device choose to remain attached to a Wi-Fi network while the device is not attached to a power source?" Excepting one unusual exception exhibited by iOS 4.3 - iOS 5.1.1, such situations include (but may not be limited to) each of the following:
The device's choice to remain attached to the Wi-Fi network in the situations above is understandable, as the device wishes to online to receive incoming connections.
When the iOS device chooses not to remain attached to Wi-Fi while the device is asleep and it is not attached to a power source, our experience is that the device usually disconnects from the Wi-Fi network not long (sometimes 10-15 seconds, sometimes as much as 90 seconds) after the device is put to sleep. (It may reconnect to Wi-Fi periodically if configured to fetch mail, contacts, and calendars via a periodic schedule, but it will disconnect once done fetching, rather than remain connected.)foobar
For iOS devices that meet the requirements above, the device's strategy for renewing its DHCP lease while the device is asleep is unusual. Rather than attempting to renew the lease once the lease reaches its expiration time, the device may choose to delay renewing the lease for some time. Usually it will renew the lease (or rebind the lease, if rebinding time has passed) prior to the lease's expiration time.
However, sometimes it does not attempt to renew (or rebind) the lease prior to expiration time; instead it allows the expiration time to pass, but continues to use the IP address from the expired lease. Specifically, it continues to respond to IPv4 ARP Requests with an IPv4 ARP Response indicating that the IP address still belongs to the device.
We have seen devices remain in this state ("stealing" the IP address after the lease has expired) for times that range from seconds to well over an hour.
If left alone, the device usually recovers from this state after some time; it eventually chooses to ask for a new DHCP lease (it enters the DHCP INIT state).
Several events can still prevent the device from entering the state in which is "steals" the IP address, or cause the device to recover from that state (this is probably an incomplete list):
Whether or not the device chooses to perform DHCP at this point seems to vary. We observed that iOS version 4.1 appeared to perform DHCP consistently in this situation, while iOS versions 4.2 and 4.2.1 might not always do so. Perhaps this is a reason that the problem became worse starting in version 4.2. This behavior had improved by iOS 5.0.
If the lease has not yet expired, this behavior can help the device avoid entering the problem state. If the lease has already expired, this can cause the device to recover from the problem state.
Starting in iOS 6.0, it appears that the receipt of a TCP or UDP unicast IPv4 packet destined to the device's IP address after the lease has passed its renewal time no longer causes the device to choose to perform DHCP.
Whether or not the device chooses to perform DHCP at this point seems to vary. We observed that iOS version 4.1 appeared to perform DHCP consistently in this situation, while iOS versions 4.2 and 4.2.1 might not always do so. Perhaps this is a reason that the problem became worse starting in version 4.2. This behavior had improved by iOS 5.0.
If the lease has not yet expired, this behavior can help the device avoid entering the problem state. If the lease has already expired, this behavior can cause the device to recover from the problem state.
Because certain kinds of outgoing (and sometimes incoming) IPv4 traffic can trigger the device to perform DHCP, how often the device experiences the problem can be related to the frequency and timing of that IPv4 traffic:
We have observed that devices running iOS 5.0 (and later) send and receive IPv4 TCP traffic (for example, to/from Apple's servers) more often than devices running earlier versions of iOS. As a result, an iOS 5.0 (and later) device is more likely (than an iOS 4.1.x - 4.3.x device) to renew/rebind its DHCP lease before the lease expires, at least for least times of 30 minutes or longer.
In our tests. iOS 4.2.x - 4.3.x devices using a ten minute lease duration exhibit the problem an average of eleven times over a 24 hour period. Increasing the lease duration to 30 minutes reduces the failure rate slightly, to 10 failures per 24 hours. A lease length duration of 1 hour reduces the failure rate to 2 failures per 24 hours. And a lease duration of 3 hours reduces the failure rate to 0 failures per 24 hours.
In our tests, iOS 5.0 - 5.0.1 devices using a ten minute lease duration exhibit the problem an average of sixteen times over a 24 hour period. Increasing the lease duration to 30 minutes reduces the failure rate to 3 failures per 24 hours. A lease length duration of 1 hour reduces the failure rate to 0 failures per 24 hours. And a lease duration of 3 hours retains a failure rate of 0 failures per 24 hours.
Results from iOS 5.1 were similar but not identical to iOS 5.0 - 5.0.1. Ten minute leases produced 27 failures per 24 hours. Lease durations of 30 minutes, 60 minutes, and 3 hours all produced 0 failures per 24 hours. Results from iOS 6.0 were similar to 5.1.
The improvement exhibited starting in iOS 5.0 appears to be due to iOS 5.0 sending and receiving TCP traffic (for example, from/to Apple's servers) more often than devices running earlier versions of iOS. Because sending IPv4 datagrams (in iOS 4.1 - at least 6.0.1) and receiving TCP or UDP unicast IPv4 datagrams (in iOS 4.1 - 5.1.1) triggers iOS to renew/rebind a DHCP lease which has passed its renewal time, iOS 5.0 and later is more likely than iOS 4.1.x - 4.3.x to renew its DHCP lease before the lease expires.
The upshot is that for iOS 5.1 or later, lease times of 30 minutes or longer will essentially "hide" the effect of the bug. However, the underlying bug remains present, and because its effect is only hidden as a side-effect of the device's other IP behaviors and timers, it remains possible that the underlying bug could resume causing problems in the future.
When a device continues to use an IP address from an expired DHCP lease after that lease expires, this can interfere with service to other devices. Once the malfunctioning device has allowed its DHCP lease to expire, the DHCP server may lease the same IP address to another client.
If two devices on the same IP network try to use the same IP address at the same time, one or both can experience difficulties using IP.
The DHCP servers try to reduce the impact of these malfunctioning clients. Before offering a client a new lease for a dynamically-assigned IP address, the servers perform a quick PING test to determine whether the IP address is unexpectedly in use. (For example, is some device "stealing" the IP address?) This quick test helps, but does not entirely work around the problem caused by the malfunctioning clients. (For example, sometimes the malfunctioning device may not respond to PING at the time the DHCP server checks before leasing the IP address to another client. And with some DHCP server implementations, the DHCP server may have limited time to perform the test, as other clients are waiting for responses from the DHCP server.)
This issue is related to the earlier iPhone OS 3.2 on iPad Stops Renewing DHCP Lease, Keeps Using IP Address bug and iOS 3.2.1 - 4.0.2 Requests a DHCP Lease Too Often issue we observed previously.
All these issues appear to be triggered by similar circumstances. It appears that this new issue debuted in iOS 4.1 as a result of the changes made in that version of the software to fix the iOS 3.2.1 - 4.0.2 Requests a DHCP Lease Too Often bug. Take note that the issues are not identical.
Apple released iOS 4.1 on September 8 2010.
Princeton University reported the bug to Apple. Our testing appeared to show that in version 4.1, the circumstances needed to cause the problem to happen would be uncommon at Princeton University. In order to observe the problem, we had to use short lease times (10 minutes) and also prevent traffic from Apple Push Notification Servers from reaching the iOS device. Because we felt the bug was so hard to trigger that it would be unlikely to cause problems at Princeton University, we did not publish information about the bug at that time.
Apple released iOS 4.2 and 4.2.1 on November 22 2010.
Our testing showed that in these versions, the bug happens more often than it did in iOS version 4.1. In version 4.2, we found that while it did not happen for devices using three hour leases, it would happen several times per day for a device using one hour leases. And we needed to create no special conditions to experience the problem starting in version 4.2. We reported the change in the bug's behavior to Apple.
Given the new behavior starting in iOS 4.2, we felt that the bug would cause problems at Princeton University. At the time, our standard wireless service used three hour lease times, so clients of that service were unlikely to be affected. Our visitor wireless service used one hour lease times, so clients of that service were likely to be affected. (It was not feasible to change our visitor wireless to use longer lease times to try to hide the problem, due to the pressure this would place on our IP address supply.)
On November 30 2010, we published this document. We did so to provide details for those of our customers who run afoul of this bug, and to detail the issue for others who wish to understand the bug Princeton has encountered.
On November 30 2010, we published a workaround. We hoped that the workaround would be temporary, until Apple made a fix available.
On December 6 2010, we updated this document and the workaround to reflect that Apple's Find My iPad/Find My iPhone/Find my iPod feature also causes the device to remain associated to the wireless network while the device is asleep.
Apple released iOS 4.3 on March 9 2011. On March 15 2011, we updated this document and the workaround to reflect that the bug is still present in that version. We added information about the unexpected behavior that appeared in iOS 4.3 for one device model when connected to one of Princeton's networks.
Apple released iOS 4.3.1 on March 25 2011. On April 1 2011, we updated this document and the workaround to reflect that the bug is still present in that version, as is the unexpected behavior that appeared starting in iOS 4.3 for one device model when connected to one of Princeton's networks.
Apple released iOS 4.3.2 on April 14 2011. On April 24 2011, we updated this document and the workaround to reflect that the bug is still present in that version, as is the unexpected behavior that appeared starting in iOS 4.3 for one device model when connected to one of Princeton's networks.
Apple released iOS 4.3.3 on May 4 2011. On May 16 2011, we updated this document and the workaround to reflect that the bug is still present in that version, as is the unexpected behavior that appeared starting in iOS 4.3 for one device model when connected to one of Princeton's networks.
Apple released iOS 4.3.4 on July 15 2011. At that time, we updated this document and the workaround to reflect that we did not re-test this version, but expect that this version behaves like version 4.3.3.
Apple released iOS 4.3.5 on July 25 2011. At that time, we updated this document and the workaround to reflect that we did not re-test this version, but expect that this version behaves like version 4.3.3.
Apple released iOS 5.0 on October 12 2011. At that time, we updated this document to reflect that the bug is still present in that version, as is the unexpected behavior that appeared starting in iOS 4.3 for one device model when connected to one of Princeton's networks. Our update also reflected that other changes in iOS 5.0 result in the bug appearing less often with longer lease times, essentially hiding the bug for lease times of an hour or more. Because our existing workaround would not work with iOS 5.0, we updated our workarounds document to add a different workaround for iOS 5.0. Our document also retained the workaroundfor iOS 4.1 - 4.3.x, as the older workaround is superior (for the versions of iOS capable of using the older workaround).
Apple released iOS 5.0.1 on November 10 2011. On December 2 2011, we updated this document and the workaround to reflect that we re-tested this version and found it behaved similar to version 5.0.
Apple released iOS 5.1 on March 7 2012. On March 26 2012, we updated this document and the workaround to reflect that we re-tested this version and found it behaved similar to version 5.0.1.
Apple released iOS 5.1.1 on May 7 2012. At that time, we updated this document and the workaround to reflect that we have not re-tested this version; based on Apple's release notes, we assume this version behaves similar to version 5.1. On May 25 2012, we updated this document to reflect that our testing confirmed that expectation.
Changes were made to Princeton's wireless network architecture beginning in September 2012 to accomodate the growing demand for wireless service. These changes included migrating from using globally-routable IPv4 addresses behind normal IPv4 routers to using private IPv4 addresses behind NAT routers, to accomodate a demand for more IPv4 addresses. And these changes included migrating from DHCP servers instrumented to detect malfunctioning clients to commodity DHCP servers, to accomodate growth in DHCP transacation rates from wireless clients. Side effects of those changes prevent us from detecting wireless clients exhibiting this issue. As we can no longer detect those malfunctioning clients, we no longer block these clients and contact the owner. As a result, those malfunctioning clients may disrupt service to other wireless clients and degrade overall wireless network service on an ongoing basis.
Apple released iOS 6.0 on September 19 2012. At that time, we updated this document and the workaround to reflect that we re-tested this version and found the bug remained present, and to reflect changes we found in the device's DHCP and Wi-Fi behaviors.
Apple released iOS 6.0.1 on November 1 2012. At that time, we updated this document and the workaround to reflect that we re-tested this version and found the bug remained present.
Apple released iOS 6.0.2 on December 18 2012. At that time, we updated this document and the workaround to reflect that we have not re-tested this version to determine whether the bug remains present.
Apple released iOS 6.1 on January 28 2013. On February 4 2013, we updated this document and the workaround to reflect that the bug remains present.
Apple released iOS 6.1.1 (only for select models) on February 11 2013. On February 12 2013 we updated this document to reflect that we have not re-tested that version. We assume the bug remains present as that version was released to fix specific unrelated bug(s) affected specific models.
Apple released iOS 6.1.2 on February 19 2013. On February 20 2013 we updated this document to reflect that we have not re-tested that version. We assume the bug remains present as that version was released to fix specific unrelated bug(s).
Apple released iOS 6.1.3 on March 19 2013. On March 20 2013 we updated this document to reflect that we have not re-tested that version. We assume the bug remains present as that version was released to fix specific unrelated bug(s).
Apple released iOS 6.1.4 (only for select models) on May 3 2013. On May 6 2013 we updated this document to reflect that we have not re-tested that version. We assume the bug remains present as that version was released to fix specific unrelated bug(s).
Apple has continued to release newer versions of iOS. As we no longer have an environment where we can test for this bug, we are not testing versions of iOS newer than 6.1 for this bug.
We have not banned devices running iOS versions 4.1 - 6.1 from Princeton University's network.
When an individual device exibits this DHCP issue, we contacted the customer to advise him or her of the problem and refered the customer to the temporary workaround. If the same device continued to exibit the issue (the customer has not adopted the temporary workaround) we blocked that individual device from our network and contact the customer again. We removed the block once the customer addressed the issue (by adopting the temporary workaround).
If it was not practical to contact the customer (for example, because the device was using our visitor wireless service and the owner was anonymous), we blocked that individual device from our network. 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 and refered the customer to the temporary workaround. We removed the block once the customer addressed the issue.
This is similar to how we handle other malfunctioning devices which disrupt or degrade service. We typically do not ban entire classes of devices. We block individual devices after they actually disrupt or degrade service. In most cases, we unblock such devices when the owner takes acceptable action to address the issue. Device Blocking Policies describes these policies in greater detail.
As described above, architectural changes made to our wireless networks beginning in September 2012 to accomodate growth now prevent us from detecting clients exhibiting this malfunction. As a result, we no longer contact the owner of these devices or block them. Instead, these malfunctioning devices continue to disrupt and degade network service for others.
Beginning in September 2012 wireless clients blocked from network service because they were exhibiting this issue will be unblocked upon request from the customer. This is because (as described above) we no longer are able to detect wireless clients exhibiting this issue. Once unblocked, if the device continues/resumes malfunctioning in this way, it may disrupt service to other wireless clients and degrade overall wireless network service on an ongoing basis. If it does so, we will no longer be able to determine the cause of the problem or address it.
Some have asked why only Princeton reported this problem. Understandably, some have suggested that because other sites have not reported it, the problem must be due to a problem with Princeton's network.
Princeton detected this issue because at the time, we took a very pro-active stance to monitor for certain kinds of common network problems, including this one.
At that time, our network monitoring included comparing actual IP address usage to DHCP server lease assignments on a daily basis. Specifically, we compared our IP router ARP cache data to our DHCP server logs. We were able to do so because we were using DHCP servers instrumented to provide us with the necessary information, and non-NAT'd IP networks in which we were able to reliably gather IP ARP data from the IP router. This allowed us to detect some devices using IP addresses not assigned for their use.
This was a degree of monitoring that many sites did not perform. Many sites place client devices -- especially wireless clients -- behind NATs. And many sites operate a DHCP service that is not instrumented in a way to assist in such monitoring. With such closely monitored ARP data and DHCP server data, detecting this kind of problem is difficult or impractical.
We also monitored our DHCP servers very closely for any problems they detected, including when they saw DHCP-leased IP addresses in-use when they should not be, or when a client tried to SELECT an offer that was not made to it, or when a client tried to renew or rebind an IP address after the client's lease on that IP address has already expired. We had instrumented our DHCP server software to make it (somewhat) easier to see such events. Our monitoring also reported DHCP clients which were the source of excessive transactions; occasionally these were victims of malfunctioning iPhone OS devices "stealing" IP addresses.
As a result of the close monitoring we performed to detect DHCP issues, Princeton tended to learn about some kinds of bugs in DHCP client implementations sooner and more often than many other sites.
A more common approach is to ignore the kinds of problems caused by devices using IP addresses not leased to them, allowing such malfunctioning devices to cause sporadic mysterious network problems for customers as their IP addresses are "stolen". Sites that use that approach may take action only when a victim of a malfunctioning device chooses to complain. Most victims probably don't complain because these kinds of problems appear random and short-lived to each victim, and often go away when they "try again."
We felt that the stance we took ultimately benefited our customers, as it resulted in more reliable network service to the customers. It reduced the frequency that our customers experience network disruptions due to others' malfunctioning devices.
As a side note, this pro-active stance also resulted in our discovering DHCP client issues a number of times over the years for a variety of common platforms. Typically we provided technical details of these issues to the DHCP client vendors, which helped the vendors to fix bugs and improve DHCP client behavior, as Apple did for this bug. Although identifying issues in vendors' DHCP client software was not our goal -- our mission was and remains to provide excellent network service to Princeton University customers -- it does speak to the technical accuracy of the bugs we discovered.
Sites that are able to monitor for these problems closely are unlikely to encounter the issue if they assign DHCP leases with longer expiration times. As described above, the probability of seeing the bug decreases with longer lease times. For iOS 4.3 - 4.3.1, we found that lease times of ten minutes produced an average of fifteen failures per 24 hours (for a single device). A lease time of thirty minutes reduced the failure rate to three failures per 24 hours. A lease time of one hour reduced the rate to under one failures per 24 hours, and with a lease time of three hours, the rate was reduced to zero failures per 24 hours. For iOS 5.0 - 5.0.1, we found that lease times of ten minutes produced an average of sixteen failures per 24 hours (for a single device). A lease time of thirty minutes reduced the failure rate to three failures per 24 hours. A lease time of an hour or more reduced the failure rate zero failures per 24 hours. For iOS 5.1 and later, a lease time of thirty minutes or more reduces the failure rate to zero.
Sites which operate network infrastructure that modifies the behavior of ARP traffic may have difficulty detecting these problems. For example, some enterprise Wi-Fi infrastructures rewrite ARP request broadcast frames to becomes unicast frames destined to the device the infrastructure "believes" should be the owner of the requested IP address. Or the infrastructure may drop ARP request broadcast frames and instead reply to these requests on behalf of the device the infrastructure "believes" should be the owner of the requested IP address. Such interference with ARP traffic can make it difficult or impossible for network operators to detect this iOS bug. Depending on the way such infrastructures decide which device "should" be the legitimate owner of a requested IP address, these ARP changes may not reliably work around the damage (stolen IP addresses) caused by this iOS bug. That is, such modifications to the behavior of ARP may not hide the damage this iOS bug causes, but may prevent network operators from discovering that the damage is happening and that it's due to this iOS bug.
Since the time we detected this bug, Princeton University re-architected our wireless networks to accomodate wireless growth. These network changes began in September 2012. 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 globally-routable IPv4 addresses and was not behind a NAT. A side effect of that design was that we could reliably retrieve IP ARP data from each network's IP router. Now most of our wireless networks are behind NAT routers so we may assign private IPv4 addresses to wireless clients; we are doing so to extend the time before we run out of globally-routable IPv4 addresses. A side-effect of the shift from normal IP routers to NAT routers is that we are no longer able to record IP ARP data for wireless clients in a manner reliable enough to let us detect wireless clients malfunctioning in various ways, including the way described in this document. Additionally, our wireless networks previously used DHCP servers we had instrumented to help us to detect "stolen" IP addresses. 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. Wireless clients which exhibit these kinds of issues can still disrupt or degrade network service for others, but we are often not able to detect and troubleshoot these kinds of problems.
We can reproduce this issue by following the procedure below. (We do not know if there are other circumstances that can produce the same issue.)
We did not test iOS versions 4.2.6 - 4.2.10 (which are available only for the Verizon iPhone 4) for this bug. We expect it behaved like version 4.2.1 or to version 4.3.x, which have the bug.
We did not test iOS versions 4.3.4 - 4.3.5 for this bug. We expect they behaved like versions 4.3 - 4.3.3, which have the bug.
We did not test iOS version 6.0.2 for this bug. We expect it behaved like versions 6.0 - 6.1, which has this bug.
We did not test iOS version 6.1.1 (which is available only for select device models) for this bug. We expect it behaved like versions 6.0 - 6.1, which has this bug.
We did not test iOS version 6.1.2 for this bug. We expect it behaved like versions 6.0 - 6.1, which has this bug.
We did not test iOS version 6.1.3 for this bug. We expect it behaved like versions 6.0 - 6.1, which has this bug.
We did not test iOS version 6.1.4 (which is available only for select device models) for this bug. We expect it behaved like versions 6.0 - 6.1, which has this bug.
We did not test other platforms running iOS 4.1 - 6.1.4 for this bug.
You may view the device's firmware version at: Settings -> General -> About -> Version.
It is possible that the problem is present on the other hardware platforms which run the iOS versions above, however, we have not tested on those other hardware platforms.
As the bug is exhibited much less often by iOS 4.1, you will find it much easier to reproduce it using version 4.2 or later.
Create a unique SSID on a single wireless access point; it should be an SSID which no other access point within the RF area will offer. This will ensure there are no 802.11 roam events.
Cause the wireless access point to offer service on only one frequency band (2.4 GHz or 5 GHz) rather than both. Choose a frequency band supported by both your iOS device and your wireless packet capture system.
These steps will ensure that the iOS device and the device you use to perform wireless packet capture are both operating on the same channel.
The wireless access point should be configured to not disassociate or deauthenticate 802.11 clients on its own due to idle timeouts or other duration-based rules.
The wireless access point should be configured to log each time the 802.11 client associates, authenticates, disassociates, or deauthenticates. This is necessary so you may determine whether the device is remaining continuously associated to the acess point. Any disassociation/reassociation events will trigger the device to perform DHCP, hiding the underyling DHCP client bug.
(In iOS 4.2 you will be able reproduce the behavior with lease times as long as an hour, although will likely need to collect data for a day or more.)
You will want the IP address to remain the same throughout the test so that you can more easily arrange for a probe device to periodically ARP for the IP address (as described below).
Although not necessary, it will be easiest to analyze the data after the test if your DHCP server writes logs in such a way that you can later extract the DHCP activity for the iOS device to determine when it performed DHCP.
The device will not indicate whether an email account supports Microsoft Exchange ActiveSync. If you are not sure, check with your email provider.
This availability of this setting does not mean that your device is in fact configured with an email account that actually supports Microsoft Exchange ActiveSync. The setting is always available. When set to On, the device tries to use Push to retrieve mail, contacts, and calendar, but for accounts that do not support Push, the device will instead use the periodic polling schedule (or "manual") specified on the same screen.
Use the Settings -> Mail, Contacts, Calenders -> Fetch New Data -> Advanced button on this screen to also view the per-email-account settings. Verify that the setting for your specific email account is also set to Push; that is, that the setting for this specific account has not overridden the system-wide setting.
You may look for running apps by opening the app drawer (double tap the Home button), and swiping through the drawer.
We suspect that applications which make use of the operating system's multitasking API to perform certain other network-related operations in the background (for example, to listen for incoming VoIP calls) might also prevent the problem from appearing. We are unable test until such applications become more widely available. If your device has any such applications installed, ensure they are not running.
Arrange for this device to send several ARP Requests for the iOS device's IP address periodically. A reasonable approach is to send three ARP Requests as layer 2 broadcasts, and three more ARP Requests as layer 2 unicasts (to the iOS device's MAC address), waiting 1-2 seconds between each packet.
After each cycle of six packets, wait a brief interval before starting the next cycle. If you are testing iOS 4.1.x, or are testing 5.0 or later, use a 5-10 second interval; that way, you are likely to send a few probes before the device recovers from the bug on its own. (Chances are that the device will recover in a few minutes, or even less.) Because the bug's behavior changed in iOS 4.2, in versions 4.2.x - 4.3.x you should be able to observe the bug even with longer intervals (say, 30 seconds or so) between each probe cycle (the device may remain in the broken state for minutes; we have even seen it last for well over an hour in those vesrions).
Be sure to send ARP Request packets to demonstrate the problem, not other kinds of IPv4 packets (for example, UDP, TCP, ICMP). Certain kinds of IPv4 unicast traffic directed at the iOS device can trigger the device to perform DHCP, hiding the problem.
If you use wireless packet capture software running on a wireless device attached via the same wireless access point (on the same channel) as the iOS device, and capture all frames from and to the MAC addresses of the iOS device and the probe device, you will be able to observe a fuller picture of the device's behavior. In particular, you will be able to observe the relationship among the device's DHCP activity, incoming IPv4 unicast traffic, and outgoing IPv4 traffic from the device.
If you are testing iOS 4.1, you will likely need to arrange to block any traffic from the Internet to the device's leased IP address. Otherwise, traffic from the Apple Push Notification Service may trigger the device to renew/rebind its DHCP lease before the lease expires. If you do install such a block (perhaps a block at your site's Internet border), be sure that the block does not interfere with the ability of the device to perform DHCP.
Because the behavior changed in iOS 4.2, starting in that version you should be able to observe the bug without any such special configuration.
You can do this by pressing the Sleep/Wake button, or by allowing the device to use its auto-lock feature.
Use the wireless access point log information to verify that the device is remaining continuously associated to the wireless access point.
As you can expect the device to exhibit the bug several times over a day, you will probably want to let the test run for 24 hours. The ARP probe and the packet capture should continue running throughout the test.
If you do not have DHCP server logs to examine, you will need to examine the packet capture to locate the DHCP activity from the device.
You will see that during that interval, the iOS device was responding to the the ARP Requests sent by your probe device, claiming that the IP address from the expired lease still belongs to the device. (You may find that the device was responding to only some of the ARP Requests; this is why we recommend sending several requests, and sending them as both unicast and broadcast frames.)
Our testing showed that iOS 4.3 - iOS 5.1.1 has an unexpected exception to the behavior described above in When Does a Sleeping iOS Device Choose to Remain Attached to a Wi-Fi Network?
Instead, the device first connected to the Wi-Fi network (associates to a wireless access point) for a period. Next it disconnected from the Wi-Fi network for a period. This cycle kept repeating. The device was connecting to the Wi-Fi network periodically to poll for certain data.
We observed the connect and disconnect durations varied among platforms and iOS versions. On an iPad (first generation, Wi-Fi), typical durations were 1-5 minutes online, 20-30 minutes offline (in iOS 4.3 - 5.0) or 12-14 minutes offline (in iOS 5.0.1 - 5.1). Some durations (online or offline) were well outside these ranges; these were only typical values. On an iPad (third generation, Wi-Fi), durations were highly irregular; ranging from 2 minutes - 12 hours online, and 2-20 minutes offline.
The fact that the device chose to not remain attached continuously to the Wi-Fi network was unexpected because the device was configured as described above (When Does a Sleeping iOS Device Choose to Remain Attached to a Wi-Fi Network?). One would expect the device to choose to remain connected continuously to the Wi-Fi network, so that it could receive incoming data (such as push mail and push notifications) in a timely fashion.
Because the device chose to not remain connected continuously to the Wi-Fi network, it no longer satisfied the requirements above which lead an iOS device to exhibit the DHCP bug described in this document.
As we were able to reproduce this unexpected iOS 4.3 - 5.1.1 behavior on only one of Princeton's networks using only selected device models, and the behavior interfered with the device's ability to receive incoming data as promptly as one might expect, we were unsure how to interpret this. Perhaps this was a new unrelated Wi-Fi bug in iOS 4.3 - 5.1.1; if so, it seemed to be triggered by an unusually specific set of circumstances. Or perhaps Apple added this behavior starting in iOS 4.3 specifically to trigger for a subset of iOS hardware platforms, when the device found itself attached to one specific Princeton University wireless network (based on that network's range of globally-routable IPv4 addresses); that possibility at first seemed far-fetched, but eventually appeared to be a likely explanation.
We found this unusual behavior was no longer present beginning in iOS 6.0, at least on the iPad (third generation, Wi-Fi). We have not tested for this change on other hardware platforms capable of running iOS 6.0 or later.
In September 2012, Princeton University renumbered the IP address range for the one wireless network at which this unexpected iOS 4.3 - 5.1.1 behavior appeared targeted. (That renumbering was part of unrelated network changes to add capacity for more wireless clients.) A side effect of renumbering that network is that the exceptional behavior in iOS 4.3 - 5.1.1 apparently targeted at that one Princeton network will no longer activate, even for devices running iOS 4.3 - 5.1.1.