Android versions 2.1 - 2.3, 3.0 - 3.1 exhibit a set of bugs which can cause the Android device to disrupt service for other devices on the same network.
A detailed description of the issue is at Android 2.1 - 2.3, 3.0 - 3.1 Allows DHCP Lease to Expire, Keeps Using IP Address.
Princeton University reported the bug to Google (the vendor responsible for the Android operating system) in September 2010. Our bug report is assigned issue #11236. In April 2011, Google confirmed the report; they indicated the problem is due to several bugs. As far as we know, Google has not made available fixes for these bugs.
In the absence of fixes from Google for all affected devices, the following partial workaround may prevent some malfunctioning Android devices connected via Wi-Fi from disrupting service to other devices. This partial workaround does not fix the bugs; it only attempts to prevent an Android device using Wi-Fi and exhibiting some of the bugs from disrupting service to other devices. The approach was proposed by a Princeton University customer. OIT expanded it to cover some additional situations.
This partial workaround is only feasible for Android devices connected via Wi-Fi. It's infeasible for Android devices connected via Ethernet.
This partial workaround appears to be effective on approximately 61% of the devices on which it was applied. This is based on our records (through December 30 2011) of Android devices which have exhibited these bugs on our campus network. In those cases where the customer then advised us that s/he was attempting to use the partial workaround, we found that 61% of the devices did not disrupt service again due to these bugs.
The procedure proved ineffective for the remaining Android devices; those devices continue to disrupt service to others. On malfunctioning Android devices where this partial workaround proves to be not fully effective, we must continue to treat the device as unsuitable for use on Princeton's networks. For this reason, we refer to this procedure as a "partial" workaround.
Our test did not reveal any apparent relationship between particular device models or versions of Android on which this partial workaround proved effective or ineffective. It is not possible for us produce a list of device models or Android versions where the workaround is more (or less) likely to prove effective.
We realize this partial workaround is inconvenient and not a satisfactory fix to the problem. It is the best we can offer in the absence of Android bug fixes from Google.
Settings
-> Wireless & networks
-> Wi-Fi settings
-> Menu (button)
-> Advanced
-> Wi-Fi sleep policy
Settings
-> Wireless & networks
-> Wi-Fi settings
-> Wi-Fi disconnect policy
If the Wi-Fi settings item is greyed-out, you may need to turn on Wi-Fi before you can select this item.
At least one of the choices should be "After 15 mins" or "When screen turns off". Select that choice.
An example would be an application designed to keep your device's Wi-Fi interface always turned on. Another would be an application configured to turn on your device's Wi-Fi interface based on certain conditions (for example, location, time of day, or battery charge).
These applications are not the cause of the bugs. However, they can prevent this partial workaround from being effective, because these may be configured to override Android's "Wi-Fi Sleep Policy" (or "Wi-Fi disconnect policy"), causing the Wi-Fi interface to remain connected to the wireless network for an extended period while the Android device is asleep.
If your device was blocked from the University's network because we detected it interfering with service due to these bugs, and then we unblock it after being advised that you have applied this partial workaround, and then at a later date we detect your device malfunction interferes with in a similar manner, your device would be blocked again. At that time, you would not have another opportunity to "try" this partial workaround again. We would not unblock the device a second time.
We have seen a large number (over a thousand) Android devices on our network exhibiting these bugs; it is impractical for us to allow each one to interfere with service repeatedly. That's true even if the reason for the additional malfunction is that the customer did not apply the partial workaround properly, or that the customer "undid" the partial workaround at some point after applying it. It's even true if the reason that the partial workaround was a firmware/software upgrade, in which the customer forgot to verify/re-apply the workaround following the upgrade. The reason for the failure doesn't play a role; the volume of malfunctioning Android devices is simply so large that we can't allow each one to disrupt service repeatedly. Each device gets one opportunity to try to try to use the workaround.
Once your device malfunctions after you've advised us that you've applied the partial workaround, another similar malfunction will be treated as final indication that the partial workaround is not fully effective for your device, for your usage pattern, or for the way you maintain your device to keep the partial workaround in place.
So: take care that you have not missed any steps above, and that in the future you don't unwittingly undo any of the steps above.
One of the steps above requires you to identify any software installed on your Android device which modifies the way Android turns Wi-Fi on or off. Sometimes customers ask OIT to provide a list of such software.
It is infeasible for OIT to provide a list of those applications which modify the way Android turns Wi-Fi on or off.
Such a list would be lengthy and not practical for us to maintain.
Additionally, each application on such a list might only behavior this way for specific versions of the application, or when the application was configured in particular ways. It would be impractical for us to try to provide such detailed information about the hundreds of thousands of applications available for Android.
One circumstance in which a malfunctioning version of Android allow its DHCP lease to expire but keeps using the IP address is while the device is asleep. This partial workaround instructs the device to disconnect from Wi-Fi when it goes to sleep, or 15 minutes after it goes to sleep. The DHCP leases used on the University's networks presently vary from 60 minutes to 24 hours, with the renewal set at half the duration of the lease. Ensuring that the device disconnects from Wi-Fi when the device goes to sleep (or 15 minutes after it goes to sleep) should avoid the situation in which the device needs to renew its DHCP lease while it is asleep. When the device later reconnects to Wi-Fi, it uses DHCP to obtain a new lease.
As we do not have a complete understanding of all of the bugs causing Android devices to stop renewing their DHCP leases yet continue using (or resume using) the leased IP addresses, we cannot say why this partial workaround is not always effective. Some possibilities are likely:
The partial workaround above does not directly address this bug.
Perhaps some Android devices have Broadcom Wi-Fi hardware, and some have other vendors' Wi-Fi hardware. Perhaps some versions of Android have a newer (fixed) version of the Broadcom Wi-Fi driver; we don't know. We have read that some device vendors may have customized the version of Android they provide for selected device models, to disable the ARP Offload feature in the included Broadcom Wi-Fi driver.
Perhaps that ARP Offload feature is used only by devices which remain connected to Wi-Fi while sleeping. If so, then the feature might not be used by devices which offer a W-Fi sleep (or disconnect) policy of "When screen turns off," but the feature might still be used by devices which offer the policy "After 15 mins."