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?
You weren't holding it right.
From ipod antennas to this?
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?
I have a Samsung Captivate, and I also experience this problem. Oddly enough, I experience similar problems with an Asus EEE netbook running Ubuntu 10.10, though maybe that isn't related, and the symptoms are just similar..
I hope this fix this ASAP. Maybe if everyone 'stars' the bug?
oh, google will fix it. But there will be carriers who will never roll those fixes out to their users.
The last link points to a separate bug in iPhone's WiFi implementation, rather than an Android issue. Which kind of makes the rest of the summary look either very ill informed, or a poorly disguised attempt at trolling.
which is totally what she said
This problem has existed for a long time, I'm surprised it's taken this long for someone to start paying attention. I banned Android devices from my company's network months ago due to these issues.
Please fix defects.. especially fix ones that affect other people. And fix them now. Ta.
- You do realise that what you call 'bugs' are in fact 'defects'? dont you? and when you allow defects to exist in your code you are essentially saying 'I'm a low quality shit who cant be bothered to do it right'
- And yes, I suppose I could learn how to program and then do and learn the DHCP code stuff and fix it myself, it would take some years but I could do it.. but that is a straw man; my dentist does not tell me to fix my own teeth.. nor does my hairdresser tell me to learn to cut my own hair.
- But apparently programmers are a special type of person where quality is for low LOC loosers..
"Oops, I always forget the purpose of competition is to divide people into winners and losers." - Hobbes
You usually have to try hard to get dhclient wrong. Just use the one from isc and you should be okay. I suppose most *nix distros do that. Maybe somebody did something clever in later android versions.
http://michaelsmith.id.au
All Android bug reports are neglected. And if you try and escalate you get stupid responses saying stuff like "Don't worry about it".
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.
Not only that, but they need OK'd by the carriers before they get rolled out. This is not a fast process.
Didn't they see the warnings in the scifi movies? Give an android an inch and he'll take a mile.
1. PROTIP: Coral Cache
2. FAIL!
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.
Do you really not know about the nyud.net free content aggregation service?
Educate yourself at www.nyud.net
Prediction for end of Universe #42: Fencepost error in Quantum_bogosort.cpp
Irwin does not hoax when it comes to his network at Princeton, he runs a tight ship. The submitter was just trying to use a cache instead of hitting up princeton's network with traffic, so just remove the nyud.net and you will get the direct link.
-----BEGIN PGP SIGNATURE-----
12345
-----END PGP SIGNATURE-----
I dont know why they have such short lease times as 1-3 hours but i do know it often creates problems, especially if the reason for the short leases are lack of addresses on the subnet in question. In that case you have to chose between address conflicts or lack of a sufficient pool of avaliable addresses.
One of the problems seems to be that the lease times are shorter than most phones are in sleep mode and the easiest remedy would be extending the lease time for the affected Android devices. Banning them are just a knee jerk reaction that puts the users in the unpleasant position of being a battering ram against Google.
Personally i have never seen this behavior from an Android device, perhaps it has a connection to a specific DHCP implemenation. If an AD is connected it could very well be related to the DNS service as well. We have tons of problems with our AD connected DHCP/DNS combo for all kinds of non-windows devices, not only Linux based. Said problems do not show up on other DHCP servers with the same clients.
HTTP/1.1 400
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...
- There is no such thing as software which is not defective, not open source or commercial. Humans are not perfect. There are plenty of "defects" in commercial software, for which the programmers have been notified, that have never been fixed.
- It seems like you're particularly peeved at OSS coders. Open source simply gives a larger quantity of people access to the code which allows for a larger possibility it will be fixed by someone who knows that part of the code. No one is asking you personally to fix it, but someone else is most likely bound to go ahead and do it anyways. That's how open source works. Ask MS to fix the style sheet remote exploits in IE, they simply won't do it, and they'll continue to not do it for years to come.
- Dentists and hairdressers make mistakes all the time, you just don't see their "defects" because you are also human. When that filling they put in seven years ago suddenly falls out while you're driving, you just head into the dentist and have it filled again. But, that filling was probably meant to last eight years and it wasn't packed tight enough. Let's not even address the fact that if dentists were perfect at their job, you would never need to go to the dentist again because they would cure your teeth entirely. But, face it, your continued patronage is their bread and butter. In fact years ago there was a drug that when applied to the mouth permanently cured gingivitis, however the cure could be spread by simply kissing so it was sequestered by the dental community as dangerous because it could not be controlled. Likewise, hair dressing is a subjective art, where people do not notice defects.
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.
Man, if they are blocking androids from their network, I'd hate to be the guy who has to monitor the DHCP server and administer Voigt-Kampff tests to every device sending a request...
Didn't Princeton have a similar problem with iPhones? Sure seems to me that Princeton should look at its own rules and infrastructure to see why it has to be so strict when so many others don't have this problem...
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.
Apparently their server has been affected. Clearly if they've banned the Android devices, the outage is caused by something else.
boycott slashdot February 10th - 17th check out: altSlashdot.org
I'm experiencing none of these issues while running a non-stock setup:
Rooted HTC G2 running CyanogenMod 7 (Gingerbread 2.3.3). The DHCP server I tested against is a WRT54GS using Tomato 1.28 firmware.
With my setup the phone renews the DHCP lease when it reaches 50% of the expiration time if it is already connected. If it is not connected when the lease expires then it renews it correctly when the next connection is made.
The ratio of people to cake is too big
The last time I have reported a Google bug on slashdot, it has been corrected very quickly.
I've found the quickest way to get something fixed is to grumble about it to a Google employee at the pub, preferably just after I've bought them a drink.
(This has now become a long-running joke with the couple of Google employees I know.)
I manage an ISP network with over 500k clients requesting DHCP leases. One of the first things we learned was to set our scopes to ignore client declines or the result would be buggy dhcp from things like home gateway products chewing through thousands of leases in a few hours. BTW Princeton I'm available for consulting.
YOu have to root a a device to do that. network operators/phone creators block you from rooting the device.
And as sugar on the cake, the Priceton IT staff only block the wifi, they cannot block 3g because that is owned by ..... network operators.
This bug has been, and will continue to be, ignored by the Android team. I am consistently disappointed with how rarely they dig into the Issues site and resolve bugs / add developer requested enhancements. If it doesn't fit Google's current agenda (tablet, GPU, etc.) it's abandoned and ignored.
See, this is exactly what Apple was talking about. This is why Apple had to sue Samsung... these things are copying Apple!
I've seen other phones do this too. This especially seems to happen when you reconnect to a network on one of these non-complying phones. They re-use their old dhcp lease without caring what the dhcp server says and so not only could they be using an ip beyond their lease but they may also easily start using an ip now used by someone else since the first phone left the network earlier.
Some of the crappier wifi routers will take a dump when this happens. (my old phone would reliably lock a local wifi hotspot if i "remembered network"). But if i had to manually re-associate each time it was fine.
It was idiotic to use a caching or anonymising proxy in a submission link to a site like Slashdot. Like it or not a lot of us are on corporate or government networks with our own proxies that see stuff like this a attempt to bypass filtering. However, having said that, the problem is legit. Here's the link to Princeton's actual web site:
http://www.net.princeton.edu/android/android-stops-renewing-lease-keeps-using-IP-address-11236.html
I found it when iPrism wouldn't let me read the damned article.
I don't need a million points of light, just two points of multi-mode fiber and a 10 Gig-E router.
Anyone who really thinks that way deserves the kick in the ass from time to time. However, the Android users, enthusiasts and fans I know have also rooted their phones, installed ad blocking and custom firmware.
Android phones are good because most of them are rootable and fixable. I'll just need to ask TeamWhiskey if they have a fix already.
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
At this point, one has to wonder what Princeton is doing on their network that they keep uncovering such bugs.
Or one could choose not to wonder and instead read TFA, in particular point 5, which describes exactly what they are doing.
'The tyrant will always find pretext for his tyranny.' - Aesop's Fables
This would have negated any issues that Princeton's networks were seeing. Properly configured, the only impact would've been that offending DHCP clients would not be able to use the network until they get a proper DHCP lease. There'd be no manual banning or need to contact your user. The user would probably contact you. All of the major networking hardware manufactures have some flavor of it: Cisco, HP, even Juniper claims to. I'd imagine the Princeton network uses something that would support this feature. *The particular related technology in Cisco world is "IP ARP Inspection".
There may be bugs in the Android DHCP, and who knows what else, but I think this is much more likely just typical crappiness of Princeton's IT department. As a grad student here, I've encountered a huge number of examples. I've had at least 3 devices banned from the network because they did "improper" things. Most were genuinely misbehaving (like a crappy router that spilled the occasional 192.168.. address onto the WAN), but not to such a terrible degree that they shouldn't have been handled.
Want to run gentoo? The network flat out won't respond to DHCP queries. Own a Wii? Can't connect to the wireless net because of some technical issue Princeton hasn't bothered to fix for over 2 years.
Forgive me if I'm skeptical of the severity of the Android issue knowing how awesomely capable our IT department is.
Reading the article, they're using 1hour and 3hour dhcp lease times! The easy fix here is simply to bump the lease times back up to a few days, which used to be the default everywhere. Then IP addresses remain relatively static, and the broken behavior won't cause nearly as much of a problem. I understand there's a reason the lease is made that short, but I don't agree with that reason. What happens is that because wifi networks are effectively unswitched, you need to limit the scope/size of each individual network, to avoid broadcast traffic (like dhcp requests) consuming a significant portion of the available throughput. Thus, wifi SSID on campuses often tend toward and mere /24 or /23 address pool per SSID and area. But, you'll likely have a lot more than 512 devices move through that area over time. To compensate for this, a lot of places have lowered their lease times. I've seen lease times as short as 5 minutes. The justification is that most of these devices are mobile devices that only tend to be online for a few minutes at a time anyway.
In my opinion, the result of this action is you have now just created a ton of the very kind of traffic that your were trying to avoid in the first place, as all your fixed devices and even some of your mobiles have to frequently renew their leases. I think a better approach is to allow a much larger address space per wireless zone. This way, you can have longer lease times, spend less wireless bandwidth handling dhcp traffic, and keep a more static IP pool that won't have as much of a problem with the broken dhcp behavior here. The downside is that the zone size has to stay the same -- you still don't want too many devices in the same zone at the same time (remember: allocated address space != actual online devices) -- and so you need to reserve a whole lot more addresses, maybe even switch to using the 10.0.0.0 space for your wifi to get enough for a larger campus (though that space is _easily_ large enough).
Unfortunately, IIRC a couple of the major vendors have their controllers/access points set up to assume /24 zones, and that makes implementing this difficult.
My understanding is most enterprise and educational policies requires the use of a proxy, which oddly enough, is a feature that has been ignored by Google. The lack of proxy settings for WiFi has been the #4 Android issue for over two years now, w/no official response from Google (http://code.google.com/p/android/issues/detail?id=1273). As you can see from almost 1500 responses, proxy support is a key prerequisite of using Android in the enterprise. It's been on other devices for years. and even in Gingerbread and Honeycomb, it's still not there. A select few manufacturers have modded into their phones, and even if you root Android to get proxy support, many apps still won't work. You'd think Google would be making this a priority instead of handing over all that market share to Apple.
From the sounds of it, Princeton doesn't even do NAT. They have a large block (probably A block) of real, routable internet IPs they hand out. As for the proxy, a lot of places I see are actually moving away from using a proxy that requires you to update setting on the client, and rather using a so-called transparent proxy (really just a router or bridge) as the default gateway set by dhcp that works because the only way to get to web is for traffic to go in one interface and go out the other.
I never had any issues with my home wireless network until a few months ago (Cannot tell you exactly when it happened). I have had an iPhone on my wifi for a little over two years now, and got an Android back in December. I thought I just had too many devices on my network or that my router was going out. If my iPhone or Android (or both) are on, my laptop is really slow, Netflix on the Wii will stop working, and the Roku looses network connectivity. I normally curse for buying a cheap router, and just reboot the thing. Looks like its not my router that is the issue after all.
Microsoft shills, Apple fanbois and various professional trolls (including the goatse guy) are buying up low UIDs instead of the now devalued gold.
To have a right to do a thing is not at all the same as to be right in doing it
Or at least a waveguide.
Droid Does.
At this point, one has to wonder what Princeton is doing on their network that they keep uncovering such bugs.
Or one could choose not to wonder and instead read TFA, in particular point 5, which describes exactly what they are doing.
Nah, this is Slashdot. We prefer pointless wondering. Preferably followed up with unfounded assertions and wild conjecture.
But if we don't then the OTHER half of the Slashdot readership complains about slow responses, timeouts and the smoke coming from the server. This is a hard crowd you're running with here.
Faster! Faster! Faster would be better!
This is the same reason a lot of campus networks banned iPhones/iPads. The Android implementation of DHCP is actaully supposed to be a be less buggy than the iOS version, which is banned at more places (and I believe, based on other comments here, this includes Princeton). That said, for most users I doubt its a big a deal. Often the wireless carriers will set up free wifi of their own on college campuses, especially AT&T because there's so many iPhones on most campuses that they wouldn't be able to handle them all on 3g. So even if you can't use the Princeton WiFi network, you probably aren't out of options.
The protocol is supposed to function like this:
1) The client sends a DHCPDISCOVER message
2) Servers with free IPs in their pools are going to send a ICMP ECHO to any address they are going to offer, just in case it has already been taken.
2) One ore more DHCP servers respond with DHCPOFFER messages.
3) The client picks a address form the DHCPOFFERS and sends a DHCPREQUEST for that address.
4) The DHCP server responds with DHCPACK, signifying that the IP now belongs to the client.
5) At any moment after this, the client can ask for a lease extension by sending an DHCPREQUEST.
In any case, there is never going to be any conflicts or "unused" IP addresses, hanging around.
echo '[q]sa[ln0=aln80~Psnlbx]16isb572CCB9AE9DB03273snlbxq' |dc
I call it a simple fix because my wife who doesn't know much about computers or any kind of electronic device can use this fix. on her Android 2.2 phone I put on 1 of the home screens the connection manager Widget that lets her turn off the wireless and/or Bluetooth and the ability to turn it back on. I tell her when she's not downloading stuff or playing online games to turn it off because of this DHCP issue. When the device turns off the wireless it stops requesting the old IP address and it stop responding to it like normal when you turn the device on it requests a new one and it works like a normal device in a DHCP network. I haven't tried this on any other devices but she's using the Evo Shift by sprint.
This is a Mac, what you have there is an embarrassment to your fellow computer users.
Someone please mod parent up as it is very interesting and shows a different view of what is happening at Princeton.
:D)
Specially if you look at comment 35866584 which refers a part of the bug report.
Very very concerning I might say... (posting openly as I could not care any less for OIT
http://stoploudness.org/
Google doesn't have any adult supervision. In fact, it has very few adults at all. They've fallen into the same pit Microsoft did, the "we're really big, so any problems we create belong to someone else" pit.
Despite their size and web presence, Google is a net newbie, and has gotten lots and lots of network related things on Android terribly wrong, and has shown no desire to get it right.
"National Security is the chief cause of national insecurity." - Celine's First Law
http://i.imgur.com/y7Hm9.jpg
Wouldn't be the first bug report to go ignored. I'm still waiting for proper windows vpn support.
Im curious about their setup and config as i cant reproduce the same problem myself. Would be fun to find out how to mitigate the problem and release a nice workaround for others to use.
And i agree that its pretty strange Princeton has such problems with a service most of us just fix (implement a workaround) when a new problem comes up and continue our lives.
HTTP/1.1 400