iPhone OS 3.2 on iPad Stops Renewing DHCP Lease, Keeps Using IP Address

This document provides details of a DHCP bug exhibited by iPhone OS 3.2 on the Apple iPad® (first generation). It provides information for individuals who would like detailed technical information about the issue.

The bug can cause the device to disrupt service to other devices on the network.

The bug is not related to the Wi-Fi issues (e.g., lost Wi-Fi connections, low signal strength) some had experienced with this platform.

Princeton University reported the bug to Apple, and worked with Apple to resolve the issue. Apple fixed this bug as of iOS 3.2.1 on the Apple iPad® (first generation). (Note that Apple's fix introduced a new bug, described in iOS 3.2.1 - 4.0.2 Requests a DHCP Lease Too Often.)

Contents

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.

What is the Issue?

Under certain circumstances, iPhone OS 3.2 on the iPad (first generation) stops renewing its DHCP lease, yet continues using the IP address after the lease expires. Although the owner of the iPad may not realize there is a problem, this interferes with service to others on the network.

Circumstances Leading to the Issue

The device exhibits this issue when the following requirements are met simultaneously:

The device is not attached to a power source (e.g. power adapter or computer).

The device goes to sleep prior to DHCP lease renewal time, and remains asleep until the lease has expired.

The device chooses to remain attached to a Wi-Fi network while the device is asleep. While the device is asleep and it is not attached to a power source, the device apparently chooses to remain attached to a Wi-Fi network in several situations: The device is configured to fetch mail, contacts, and calendars via "Push", and is configured with an account that actually supports "Push" technology (for example, Microsoft Exchange ActiveSync®). The device is configured to have "Notifications" (Apple Push Notification Service) turned on. We are unsure if there are other situations (perhaps involving the use of applications not among those pre-installed with iPhone OS 3.2) that could cause the device to choose to remain attached to a Wi-Fi network while the device is asleep. Outside the situations above, the device apparently chooses to disconnect from the Wi-Fi network when the device is asleep and it is not attached to a power source. (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.) Since the device doesn't remain attached via Wi-Fi while it is asleep and it has no power source, it doesn't exibit the DHCP issue.

Nothing happens to cause the device to lose its connection (even momentarily) to the Wi-Fi network from the time that the device goes to sleep until the time that the DHCP lease expires. Roaming directly from one wireless access point to another that is part of the same extended service set (a true 802.11 re-association) apparently doesn't count as "losing" the connection.

DHCP Behavior

Once the device goes to sleep, the device stops renewing the DHCP lease. The lease eventually expires, but the device continues to use the IP address from the expired lease.

Several events can still forestall the problem:

If the device is awoken before the lease expires, the device will request a new DHCP lease (it enters the DHCP INIT-REBOOT state).

If the device disconnects from the Wi-Fi network (it disassociates from the wireless access point) before the lease expires, this avoids the problem. When the device reconnects to the Wi-Fi network (even if it was disconnected only momentarily) the device will request a new DHCP lease (it enters the DHCP INIT-REBOOT state).

Once the lease has expired, waking the device does not resolve the problem. Once the device is awake, the iPad does not attempt to use DHCP to obtain a new lease. It continues to use the IP address from the lease that has expired. At that point, further sleeping and waking the device does not help.

Once the device has reached this point, we have found that any one of the following actions will get the device out of this state:

Power off the iPad (this is not the same as putting the device to sleep). When you next power on the iPad, it will ask for a new lease.

Use the iPad's Settings application to turn off its wireless interface. When you next turn on the iPad's wireless interface (even if it's only a few seconds later), it will ask for a new lease.

Cause the iPad to lose its connection to the 802.11 wireless network may also work. (That is, cause the iPad to experience an 802.11 de-authenticate or disassociate event. We've tested it by forcing the wireless access point to de-authenticate the iPad. Moving the iPad beyond the coverage area of its current wireless access point might also do the job.) When the iPad next associates to the wireless network, it may ask for a new DHCP lease. We've verified this works in some cases, but have not yet been able to test enough cases.

Why is this DHCP Behavior a Problem?

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.)

Inaccurate Media Reports

Some media reports concluded that Princeton discovered or diagnosed a Wi-Fi issue with the iPad, sometimes reporting that the issue Princeton has seen is the cause of iPad Wi-Fi signal/connectivity issues others had described. This conclusion is inaccurate; the particular behavior we encountered with iPhone OS 3.2 on the iPad is a DHCP client issue. This DHCP client issue is unrelated to any Wi-Fi signal/connectivity issue with iPhone OS 3.2 or the iPad.

Some have reported that Princeton has security or bandwidth concerns about the iPad. This is not accurate. This issue we identified is strictly a DHCP client issue in iPhone OS 3.2 on the iPad (first generation).

Is This the Same Issue Princeton Saw with Later Versions of iOS?

When this bug was fixed in iOS 3.2.1, at the same time a new issue was introduced: iOS 3.2.1 - 4.0.2 Requests a DHCP Lease Too Often. Both issues appear to be triggered by similar circumstances. Probably the issue that debuted in iOS 3.2.1 was caused by the changes made in iOS to fix the bug that was present in iOS 3.2. Take note that the two issues are not identical. In iPhone OS 3.2, the device stops performing DHCP yet continues using the DHCP-assigned IP address after the DHCP lease expired. In iOS 3.2.1 - 4.0.2, the device performs DHCP unecessarily often. The effect on network service is quite different.

When the iOS 3.2.1 - 4.0.2 Requests a DHCP Lease Too Often issue was in turn fixed in iOS 4.1, at the same time a new issue was introduced: iOS 4.1 - 6.1 Allows DHCP Lease to Expire, Keeps Using IP Address. That issue too appears triggered by similar circumstances. Probably the issue that debuted in iOS 4.1 was caused by the changes made in iOS to address the issue that was present in iOS 3.2.1 - 4.0.2. Again, the issues are not identical, and the effect on network service is quite different.

How Has Princeton Handled This Issue?

iPhone OS 3.2 debuted on the Apple iPad® (first generation) on April 3 2010.

On April 4, we observed our first DHCP client malfunction from an iPad on the Princeton network. Over the next few days, additional iPads malfunctioned in the same way.

Beginning April 4 2010 (before we had seen enough malfunctions to establish a pattern), when an individual iPad malfunctioned, we would contact the owner to advise him or her of the problem. When the same iPad malfunctioned a second time, we would block that device from using our network, and contact the owner again.

Our approach was the same as for any other particular device that malfunctions in such a way as to disrupt service: When an individual customer's device malfunctions this way repeatedly, Princeton blocks that particular customer's device from using those campus network services which rely on the device's DHCP client respecting lease times. These include our wireless services. We do this to protect other customers of those services from the disruptions caused by the malfunctioning devices.

Within a few days of the iPad's arrival, we had seen enough incidents from those iPads already on campus to conclude that there was a problem. At that time we knew that the devices were continuing to use their IP addresses after allowing the DHCP leases to expire. We did not yet know the circumstances that led the devices to behave in this way.

Roughly half the iPads atached to our network had malfunctioned in the same way. Because the problems were so common and began as soon as iPhone OS 3.2 and the Apple iPad were released, we felt it unlikely that the problem was due to customer misconfiguration. Given the symptoms we have seen, we believe that it is due to a bug in iPhone OS 3.2 on iPad.

We collected technical data and reported the bug to Apple on April 7 2010.

On April 8 2010, Princeton posted an alert advising campus iPad owners of the issue. The alert said: Until a fix is provided by Apple, OIT recommends not connecting your iPad device to the campus network as it is extremely likely it will malfunction. iPad devices that malfunction in this manner while connected to the campus network may need to be blocked to maintain the stability and reliability of campus network services. That alert remained in place through April 19 2010.

We continued collecting information, and providing detailed technical data to Apple. We attempted to identify a temporary workaround for our customers to use until a fix became available.

On April 13 2010, we published the first version of this document, describing the issue we were seeing. We have continued to update the document since then.

On April 15 2010, we determined how to reproduce the problem, and added that information to this document.

On April 19 2010, we published the first version of our Workaround for "iPhone OS 3.2 on iPad Stops Renewing DHCP Lease, Keeps Using IP Address" Issue. We viewed it as a temporary workaround, until a fix is available from Apple.

On April 19 2010, Princeton revised its posted alert to reflect the availability of that workaround. The updated alert no longer recommended that iPad owners keep their devices disconnected from the campus network; instead it said: Until a fix is provided by Apple, OIT recommends that iPad owners use the Workaround for "iPhone OS 3.2 on iPad Stops Renewing DHCP Lease, Keeps Using IP Address" Issue. That temporary workaround appears to prevent the iPad from malfunctioning in this manner. iPad devices that continue to malfunction while connected to the campus network may need to be blocked to maintain the stability and reliability of campus network services.

So during the period April 8-19 2010, Princeton recommended that iPad owners not connect their iPads to the campus network. When a customer did connect his or her iPad, s/he would find that once that device malfunctioned twice, we blocked the device from further use of the network, to stop it from disrupting service further.

Since April 19 (once we had a workaround), when an individual iPad malfunctions, we contact the owner to advise him or her of the problem and refer the owner to the workaround. If the same iPad malfunctions a second time, we block that device and contact the owner again.

If an iPad owner is able to operate the device in such a way that it does not malfunction (for example, by using a workaround we published), we do not block the device. Only those iPads which actually malfunction in such a way as to disrupt service are blocked.

On June 14 2010, we updated this document to add additional information about the circumstances leading to the malfunction. We had already documented that the iPad exhibits the problem when it chooses to remain attached to Wi-Fi while it is asleep and the iPad is not attached to a power source. Additional information is that one reason the iPad will choose to remain attached to Wi-Fi (while it is asleep and it is not attached to a power source) is the use of "Push" to retrieve email if the iPad has been configured with an email account that supports Push (e.g., Microsoft Exchange ActiveSync®) technology. A second reason the iPad will behave this way is leaving "Notifications" (Apple Push Notification Service) turned on after an application that uses Apple Push Notification Service is installed.

Taking advantage of that additional information, on June 14 2010 we published the second version of our Workaround for "iPhone OS 3.2 on iPad Stops Renewing DHCP Lease, Keeps Using IP Address" Issue. While the first version of the workaround was effective, this new version was more convenient. We continued to view it as a temporary workaround, until a fix was available from Apple.

On July 15 2010, Apple released iOS 3.2.1 (build 7B405) for iPad (first generation). We verified that iOS 3.2.1 does not exhibit this bug.

Through July 15 2010, 102 of the 160 iPads seen on our campus network had exhibited this bug; some had done so repeatedly. A total of 81 of these iPads were blocked from using the network due to this malfunction; some have since been unblocked, for example, after the customer adopted the workaround we have published, or upgraded to a version of the code that fixes this bug.

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.

Did We Ban the iPad at Princeton?

Many media reports reported that Princeton "banned" use of the iPad on our campus network. That's not entirely accurate.

As we describe elsewhere in this document, during April 4-7 2010 (prior to establishing a pattern of malfunctions with the device), we contacted the owner of each device that malfunctioned to advise him or her of the problem. When the same device malfunctioned a second time, we would block that device from using our network and contact the owner again.

Once we had established the pattern of malfunctions, and came to believe that it was a bug in iPhone OS 3.2 on iPad, we updated our handling. On April 8 2010, Princeton posted an alert advising campus iPad owners of the issue. The alert said: Until a fix is provided by Apple, OIT recommends not connecting your iPad device to the campus network as it is extremely likely it will malfunction. iPad devices that malfunction in this manner while connected to the campus network may need to be blocked to maintain the stability and reliability of campus network services. That alert remained in place through April 19 2010.

On April 19 2010, we published the first version of our Workaround for "iPhone OS 3.2 on iPad Stops Renewing DHCP Lease, Keeps Using IP Address" Issue. We viewed it as a temporary workaround, until a fix is available from Apple.

On April 19 2010, Princeton revised its posted alert to reflect the availability of that workaround. The updated alert no longer recommended that iPad owners keep their devices disconnected from the campus network; instead it said: Until a fix is provided by Apple, OIT recommends that iPad owners use the Workaround for "iPhone OS 3.2 on iPad Stops Renewing DHCP Lease, Keeps Using IP Address" Issue. That temporary workaround appears to prevent the iPad from malfunctioning in this manner. iPad devices that continue to malfunction while connected to the campus network may need to be blocked to maintain the stability and reliability of campus network services.

So during the period April 8-19 2010, Princeton recommended that iPad owners not connect their iPads to the campus network. When a customer did connect his or her iPad, s/he would find that once that device malfunctioned twice, we blocked the device from further use of the network, to stop it from disrupting service further.

We understand why some would report that we had "banned" the iPad from our network. But as the information above explains, the reality was somewhat different.

Some iPads (first generation) continue to exhibit this issue because they are still running iPhone OS 3.2. When an individual device exibits this issue, we contacted the customer to advise him or her of the problem and refer the customer to the iOS upgrade. (Before an iOS upgrade was available to address the issue, we referred customers to our temporary workaround.) If the same device continued to exibit the issue (the customer has not upgraded the firmware nor adopted the temporary workaround until upgrading the firmware), we blocked that device from our network and contacted the customer again. We removed the block once the customer addressed the issue.

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.

Why Didn't Other Sites Report This Particular Issue?

When we first described the problem, some asked why only Princeton was seeing a problem. Understandably, some suggested that because other sites were not reporting it at the time, the problem must have been 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. Without 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 less likely to encounter the issue if they assign DHCP leases with long expiration times. Princeton's wireless services relied on DHCP leases in the 1-3 hour range. (Shorter leases allowed us to recover unused IP addresses rapidly, in turn permitting us to assign globally-routable IP addresses to clients without requiring Princeton to impose a NAT between wireless clients and the Internet.) Expiration times so long that the client device is likely to be awoken (or relocated in such a way that its Wi-Fi connection drops) before the lease expires will reduce the frequency of the problem. Working around the problem entirely probably would require the use of lease times that exceed the longest time an iOS device could remain asleep before its battery is drained.

Sites which operate network infrastructure that modifies the behavior of ARP traffic may also 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 the 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.

Some have claimed that because we only detected this malfunction from half of the iPads at Princeton, the fault must have been not with the iPhone OS 3.2 on iPad, but with Princeton's network. That conclusion was incorrect. As the Steps to Reproduce the Bug elsewhere in the document explain, we found that a specific set of circumstances would cause the iPad to malfunction in this way. Not every iPad might experience that specific set of cirumstances. Additionally, Princeton's network monitoring was (at the time) able to detect this kind of malfunction only when it disrupts service or extends beyond one day; some malfunctions go undetected. Some also further claimed that because we only blocked some of the iPads at Princeton, the fault must have been not with the iPhone OS 3.2 on iPad, but with Princeton's network. That conclusion was similarly incorrect. As the information in this document explains, iPhone OS 3.2 on iPad only exhibited the malfunction in specific circumstances, and we only blocked the device after we detected it malfunctioning a second time.

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 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. Furthermore, our wireless networks previously allowed IP ARP traffic to flow normally. Now on most of our wireless networks, wireless controllers intercept most IP ARP requests to reduce the broadcast traffic rate; instead of flooding the requests to allow all possible clients to see and respond to ARP requests, the wireless controllers may choose to construct an ARP response themselves based on the controller's notion of the "correct" answer. A side-effect of the move away from normal ARP traffic flow is that on our wireless networks, we no longer can truly determine which devices are using which IP addresses. The upshot is that as a side-effect of 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 no longer able to detect and troubleshoot these kinds of problems.

Steps to Reproduce the Bug

We can reliably reproduce this bug by following the procedure below. (We do not know if there are other circumstances that can be used to demonstrate the bug.)

If you have an iPad+3G (instead of the iPad without 3G), you may wish to disable the 3G interface while following these steps to reproduce the bug. (We have tested this procedure on the iPad without 3G; we do not know if an iPad+3G will behave differently if its cellular interface is up.) Ensure you are using an iPad (first generation) running firmware version 3.2 (build 7B367). This is the version that originally shipped with the iPad beginning with the iPad's release in April 2010. You may view an iPad's firmware version at Settings -> General -> About -> Version . You will not be able to reproduce this problem with firmware version 3.2.1 (build 7B405) or version 3.2.2 (building 7B500). Those versions have a different issue. Configure the iPad with an email account that supports Microsoft Exchange ActiveSync® to push email from the server to the iPad. The iPad will not indicate whether an email account supports Microsoft Exchange ActiveSync. If you are not sure, check with your email provider. Configure the iPad to try to retrieve email via Push (for those accounts which support Push (e.g., Microsoft Exchange ActiveSync). Do so by setting Settings -> Mail, Contacts, Calenders -> Fetch New Data -> Push to On . This availability of this setting does not mean that your iPad is in fact configured with an email account that actually supports Microsoft Exchange ActiveSync. The setting is always available. When set to On , the iPad tries to use Push to retrieve mail, contacts, and calendar, but for accounts that do not support Push, the iPad 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. Leave the USB/dock connector disconnected from the iPad throughout the test; the iPad must not be connected to a power source. Cause the iPad to be connected to an 802.11 wireless network. Allow the iPad to obtain a lease via DHCP. If it was already configured to use DHCP, it did this once it connected to the wireless network in the preceeding step. For the remainder of the steps below, don't do anything that would cause the iPad to disassociate or de-authenticate from the 802.11 wireless network. For example, don't relocate the iPad in such a way that it loses its 802.11 connection for a time. This is because a wireless reconnection may trigger the iPad to attempt to perform DHCP, putting you back to the previous step (resetting the lease timers). If the iPad on its own decides to disconnect from the 802.11 wireless network, this will also prevent you from reproducing the problem, for the same reason. If your wireless access points perform an 802.11 de-authentication or disassociation of the iPad after some time (e.g. due to some idle station timeout), this can also prevent you from reproducing the problem, for the same reason. If the iPad roams directly from one Wireless Access Point to another (never losing its connection), this generally will not trigger the iPad to attempt to perform DHCP. As a result, roam events will not prevent you from reproducing the problem. (We verified that the iPad remained connected to the wireless network throughout the test by monitoring the logs from our wireless access points. If you don't have the ability to monitor your wireless access points, you will not be able to verify that the iPad is truly remaining connected continuously. Without that information, if you have difficulty reproducing the problem, you may be unable to determine if it is because the iPad didn't remain connected to the wireless network.) Before the DHCP lease reaches the time it is due to be renewed (lease time T1) cause the iPad to go to sleep. You can do this my pressing the Sleep/Wake button, or by allowing the iPad to use its auto-lock feature. Leave the iPad continue to remain asleep through the time that the DHCP lease is due to expire. Lease renewal time will pass without the iPad attempting to renew its lease. Although the iPad remains attached to the wireless network the entire time, it does not attempt to renew the DHCP lease. The iPad will continue to use the IP address. (This is not yet a problem.) Lease expiration time will pass without the iPad attempting to renew its lease. Although the iPad remains attached to the wireless network the entire time, it does not attempt to renew the DHCP lease. Even after the lease has expired, the iPad continues to use the IP address. For example, it will respond to ARP requests and PING requests. Once the iPad is in this state, pressing its Sleep/Wake button to awake the device (and optionally unlocking it as well) does not resolve the problem. Once awoken, and unlocked, the iPad does not attempt to use DHCP to obtain a new lease. It continues to use the IP address from the lease that has expired. Putting the device back to sleep and awakening it again will not help at this point; the problem continues.

In brief:

When the iPad is configured with an email account that supports Microsoft Exchange ActiveSync®, and the iPad is configured to retrieve email for that account using "Push", the iPad tries to remain connected to the Wi-Fi network even when the iPad is asleep and the iPad is not attached to a power source.

When the iPad has an application installed which supports Apple Push Notification Service, and Notifications are enabled, the iPad tries to remain connected to the Wi-Fi network even when the iPad is asleep and the iPad is not attached to a power source. (This doesn't happen 100% of the time; sometimes the iPod chooses to remain disconnected from the Wi-Fi network. We suspect that's an unrelated bug.)

While the iPad remains connected to the Wi-Fi network and is asleep, and the iPad is not attached to a power source, and the iPad experiences no 802.11 wireless disconnect/reconnect events, the iPad does not attempt to renew its DHCP lease. The iPad continues using the IP address after the lease has expired.

Once the iPad has gotten into this state, and the DHCP lease has expired, we have found that any one of the following actions will get the device out of this state:

Power off the iPad (this is not the same as putting the device to sleep). When you next power on the iPad, it will ask for a new lease.

Use the iPad's Settings application to turn off its wireless interface. When you next turn on the iPad's wireless interface (even if it's only a few seconds later), it will ask for a new lease.

application to turn off its wireless interface. When you next turn on the iPad's wireless interface (even if it's only a few seconds later), it will ask for a new lease. Causing the iPad to lose its connection to the 802.11 wireless network may also work. (That is, cause the iPad to experience an 802.11 de-authenticate or disassociate event. We've tested it by forcing the wireless access point to de-authenticate the iPad. Moving the iPad beyond the coverage area of its current wireless access point might also do the job.) When the iPad next associates to the wireless network, it may ask for a new DHCP lease. We've verified this works in some cases, but have not yet been able to test enough cases.