Slashdot Mirror
Bug Forces Android Devices Off Princeton Campus Network
pmdubs writes "A major bug in the Android DHCP implementation has forced network administrators to (effectively) ban the use of such devices on the Princeton campus. In the last few months, Princeton has had to kick more than 400 Android devices off the campus network for using IP addresses well beyond the allotted DHCP lease (to the detriment of other users), sending invalid DHCPREQUEST messages after lease expiration, and a variety of other wacky behaviors. The link provides a clearly documented explanation of the buggy behavior, as does this largely neglected bug report. Without doubt, this buggy behavior is affecting other, less vigilant networks, and disrupting Wi-Fi traffic for Android and non-Android devices alike."
Why in the name of all that is GNU would Android re-implement a DHCP client when every Linux system since forever has had good DHCP client support already there?
Did Google decide to implement their own IP layer entirely?
# Prevent Internet sites from requesting LAN resources. Site LOCAL Accept from LOCAL Deny
Anyone care to comment on what that is all about?
From the description in the bug report, it sounds like certain services (dhcp client I should think) are halted or disabled. It seems to restart when web browsing activity is initiated. This seems to indicate that it was halted when the machine was initially locked -- my guess would be to save battery. After all, DHCPing all the time would burn battery.
I wonder what the best solution would be? When locking to release the DHCP lease before suspending the DHCP client? I wonder if my Vibrant has the same issue?
oh, google will fix it. But there will be carriers who will never roll those fixes out to their users.
I've had to reboot my WBR-2310 fairly often as my Android phone loses ability to see the router to connect to it.
I moved the DHCP server to my Linux box and it seemed to help, but have since had to reboot router occasionally.
I wonder if it's related.
Also, good work Princeton, this impressed me, from TFA:
--
Salon Kill File: required for reading Salon.com Letters section:
http://salon.maow.net/
Yeah because we all know how good that Android OEMs are about releasing timely updates.
The link is Coral Cached, presumably in an attempt to prevent a slashdotting.
Benford's Corollary to Clarke's Law: "Any technology distinguishable from magic is insufficiently advanced."
They do own princeton.edu. You'd expect someone with a 5-digit /. ID to know that. And to be able to figure out from the hundreds of similar past links in articles, that nyud.net is a distributed caching service.
Apple had a similar issue:
http://www.net.princeton.edu/announcements/ipad-iphoneos32-stops-renewing-lease-keeps-using-IP-address.html
At this point, one has to wonder what Princeton is doing on their network that they keep uncovering such bugs.
Princeton may well be one of the leading academic institutions in the country, but I've taken it as axiomatic that the more prestigious an institution is the more backward its technology is going to be. For instance, at Firestone Library, the chief repository for literature-related material on campus, there is no electronic gate for entry and exit -- a desk guard checks your ID when you go in and searches your bag when you go out. Many projectors on campus max out at an anemic 800x600 resolution, a fact that has caused problems for me at two different presentations. Site licensing policy is weird and inconsistent (there are no fewer than three different kinds of Windows licenses you can get from the software repository).
I don't know if it's the archaic technology they're responsible for maintaining or some other cause, but the Office of Information Technology is full of power-hungry knee-biters who have made it their life's mission to sniff out every errant packet, every mistimed request, every misconfigured network adapter, and God help the poor sap whose device is unwittingly responsible for one of these infractions. The banhammer's wrath is terrible, its retribution swift. You never see it coming because OIT bans first and sends nastygrams later, or not at all, and when you call them to inquire why your Internet connection is suddenly nonexistent they give you this explanation of their rationale that somehow always ends up sounding like the narrative of a Carmen Sandiego investigation. Oh, and you play the part of the VILE agent. You're always knowingly guilty. Yeah, my wife installed VMware Fusion on her Mac to cause trouble for the netizens of Princeton. She was totally aware that VMnet was slightly misconfigured and was occasionally sending invalid packets to her subnet. It was all part of her nefarious plan to shut down the university network for some inadequately explored reason.
I'm posting this anonymously because for all I know some overzealous git at OIT (which is Princetonese for KGB) reads Slashdot and Lord knows their admins are happy to ban you from the network for any reason they can conjure up out of thin air. Better yet, if you get banned from the network enough times for seemingly innocuous misbehavior by your gadgets they can cite you for academic misconduct. Plagiarism? Bought an Android phone? Same difference.
It is possible to describe OIT's hypomanic "kill all DHCP miscreants" approach as "vigilant." It is also possible to describe it as "total overkill." I haven't yet heard of any major university or corporate network being blown up by sleeper cells (har har) of terroristic smartphones.
In short, Princeton OIT is like the Civil Protection of information technology outfits: they protect the network from its users. Small wonder that I sometimes feel like picking up a crowbar and causing some anarchy for them...
The last time I have reported a Google bug on slashdot, it has been corrected very quickly.
This may be the new procedure: report a bug to google and if it is not corrected quickly enough, advertise on slashdot.
Agreed. I wonder how many serious security bugs users of the original direct-from-Google ADP are exposed to, because Google refuses to release updates for a phone they sold retail not much more than a year ago (right up until the release of the N1 I believe, which is only a little over a year old).
People bash other vendors for not supporting android hardware but tend to favor Google since they have supported the N1 with all of their updates quickly, but they forget that the N1 is not first android phone that Google sold. Google stopped releasing security updates for the ADP as soon as they released the N1 - the last update of any kind for the ADP was Android 1.6, which came out the summer before they stopped selling the phone.
I'll take android over Apple any day - but only if I can root the phone, and use a mostly-open-source distribution. For all of its issues at least Apple supports their hardware, and even they pale in comparison to Microsoft which still provides security updates Windows XP.
Not releasing security patches for an always-connected device for at least the full 2-3 year upgrade cycle after the last unit is sold is just irresponsible behavior. They don't need to release the latest and greatest features necessarily, but they should at least back-port serious bugfixes. If they are concerned about supporting all those sub-versions of android then they can either do releases more slowly, or at least migrate all phones to LTS releases of some kind.
At this point, one has to wonder what Princeton is doing on their network that they keep uncovering such bugs.
Princeton's network was for the longest time very old. We had shared 10mb over cat3 cable to most of the campus. To keep things working, the network was heavily monitored and anything that did not belong was promptly disconnected.
Fast forward to now. We have a modern network that can handle some problems, but the motioning form the dark days still continues. Because of this heavy monitoring IT can see problems with devices that probably no one on earth sees.
Yes the iPhone and iPod both had the same issues, but Apple fix them eventually. I hope the Google will do the same.
You paid google with your eyeballs (every time you use Google search or one of their other clever resources that builds their gold mine of user data and helps them shovel ads.) You also paid your carrier to pay google (every year google makes $10 per active handset from the carrier.)
So yeah, google kind of does get paid, by ME, for the privilege of using Android.
Android is singled out over Apple devices because there's a workaround on iOS but not on Android. The workaround involves disabling a variety of things that many iPhone & iPad users may not want disabled, but it is available.
And I don't consider a single mention of an "Allshare workaround" that involves waiting for a particular app to connect, then crash to be a workaround.
fencepost
just a little off
Some may wonder why only Princeton has reported this problem. Some may believe that because other sites are not reporting it, the problem must be due to a problem with Princeton's network.
Princeton detected this issue because we take a very pro-active stance to monitor for certain kinds of common network problems, including this one. Our network monitoring includes comparing actual IP address usage to DHCP server lease assignments on a daily basis. This allows us to detect some devices using IP addresses not assigned for their use. This is a degree of monitoring that many sites do not perform. We also monitor our DHCP servers very closely for any problems they detect, including when they see DHCP-leased IP addresses in-use when they should not be, or when a client tries to SELECT an offer that was not made to it, or when a client tries to renew or rebind an IP address after the client's lease on that IP address has already expired.
As a result, Princeton tends to learn about some kinds of bugs in DHCP client implementations sooner and more often than do many other sites.