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?
oh, google will fix it. But there will be carriers who will never roll those fixes out to their users.
No, the restart sequence should check a timer to determine if the initial lease has expired, and renegotiate a new IP from the server if necessary. Assuming that when you wake up that the lease still exists without checking would certainly cause problems. It's not a case that would normally get tested as it requires a large down time to accomplish, and yuo won't encounter that with normal sleep-to-wake test cycles.
Is it just my observation, or are there way too many stupid people in the world?
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...
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.
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?
Actually, the report specifically states that this bug should not be classified as a problem with DHCP when sleeping. The Princeton guy did extensive testing and found that even with active use, the device fails to renew the lease and continues using the IP after the lease has expired.
We always knew Comcast was corrupt, here's the proof: http://tech.slashdot.org/comments.pl?sid=1909890&cid=34545432
iPrism (my company's nanny of choice), blocks the site as an annonymiser. And what the hell kinda URL *is* net.princeton.edu.nyud.net anyway?
Here's the link to Princeton's web site: http://www.net.princeton.edu/android/android-stops-renewing-lease-keeps-using-IP-address-11236.html
And it appears the iPad has a similar problem: http://www.lockergnome.com/blade/2010/04/16/princeton-explains-network-issues-for-ipad-users-and-has-banned-the-devices/
Odd that they're both doing something so similar. Wonder if they use the same base DHCP code.
I don't need a million points of light, just two points of multi-mode fiber and a 10 Gig-E router.