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?
This should be fixed by this afternoon and everyone should be updated by tomorrow, right? Not like the closed iOS which would have taken months to fix.
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
Apple fanboys can rant how iOs is supposedly better. Closed-source fans can decry the "horrible quality" of open source. And I'm sure some "Windows Mobile is the shit"-guys will chime in. All the while forcing Android and open source advocates to defend/counter-attack. There's something for everybody!
This should be fun to watch. Flamewar is a go!
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/
Give the kids a 3-day dhcp lease!
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.
Didn't they see the warnings in the scifi movies? Give an android an inch and he'll take a mile.
I used to see very similar behavior from my EeePC 701 using the Xandros install that came with it. It basically meant I couldn't connect to my work's network as the machine refused to give up the lease it had obtained on my home network (which was the same IP range). This persisted through reboots!
I wanted to move to Ubuntu anyway, so I never solved the problem - just installed a better distro!
1. PROTIP: Coral Cache
2. FAIL!
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
Well, if you go to www.princeton.edu and search for android right off the main page you will find: (top link mind you) http://www.net.princeton.edu/android/
Geeze, how hard was that to verify?
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
I manage a network with a very small DHCP range that I can't expand for legacy reasons. In the past few months, it has run out of addresses more and more often. I don't have the monitoring that Princeton has, so I've been having trouble identifying the cause. In the time it has been getting worse, there have been more and more Android devices, but I never made the correlation. I'm going to have to look into this and see if a ban or a workaround might fix it.
Please resolve all wars, solve all poverty, and give everyone a magic flying pony. And do it now. Ta.
- You do realise that what you call events are in fact problems? dont you? and when you allow problems to exist in the world you are essentially saying "I'm a low quality shit who cant be bothered to do it right'
- And yes, I suppose I could become president of the world and then do and learn the political stuff and fix the whole world 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 politicians are a special type of person where quality is for low LOC loosers..
Really, you don't ask for much do you? I think the fact you think any coder who has a bug in their software is "low quality" demonstrates aptly that you don't have the first fucking clue of the level of complexity of software development. I think the fact you have such a low user ID and have hence been here a while and still haven't managed to grasp that fact suggests that no, you couldn't learn to program, because you're clearly just far too fucking dumb.
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.
http://www.net.princeton.edu.nyud.net/android/android-stops-renewing-lease-keeps-using-IP-address-11236.html is the Coral Cache link for http://www.net.princeton.edu/android/android-stops-renewing-lease-keeps-using-IP-address-11236.html. Go ahead, click on both links, you will see that they are the same
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...
Android is open, the users can download the source code and fix the bug themselves. This "problem" is blown completely out of proportion.
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
Can't take a taste of your own medicine? There's nothing but bitching about Apple's walled garden and Android is the next greatest thing ever. But bring up the fact that some OEMs are stuck on VERY old roms and will never be updating and you like to ignore it.
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.
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.
You complain about TESTING and you can't even get ONE SENTENCE correct?
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.
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
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.
Princeton had this same problem with the Iphone/Ipad a year ago. I run a much larger wireless network and have done extensive testing and found this to be a non-issue. Yes it does happen in a few hard to reproduce cases, but alot of DHCP clients are broken in a few hard to reproduce cases, and DHCP has a process in place to deal with these clients, as well as others who are poaching IPs.
This isnt a case of proactive monitoring, its a case of bitching about users instead of actively solving the problem. Step one, NAT the wireless network. Step two, Double the address pool with RFC 1918 address space. Step three, Quit your bitching.
The DHCP issue is just one of a whole host of issues with 802.11 on Android. If you watch your logs you will see things such as the 802.11 interfaces just dying when you change SSIDs, WPA(2)-Enterprise settings that disappear, WPA(2)-Enterprise settings combinations that don't make sense, serious pain getting a certificate on the device to use with WPA(2)-Enterprise, complete lack of support for hidden SSIDs (even though wpa_supplicant supports it).
To make matters worse, Google ignores their users that report issues like this. (Disclaimer : I am an Android user, and have many devices, so this isn't an iPhone user bashing Android.)
I wish I could say that 802.11 was a second class citizen on Android. But, that would be too much praise. It seems 802.11 was only included to provide a competitive data point.
To be fair, the 802.11 interfaces dying is more the fault of the driver developers for the individual phone makers. But, the rest of the issues are squarely on the shoulders of Google.
They need to hire someone that *REALLY* understands 802.11, like Matthew Gast (he wrote the O'Reilly 802.11 book). Maybe then they could get their stuff together.
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.
Apparentyl Ipod users experiment the same trouble at princeton..
https://discussions.apple.com/thread/1874930?threadID=1874930
You can always say dhcp clients are having it all wrong, but as a sysadmin at princeton, I would wonder if the bug's not on the chair...
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.
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
It seems that every few months Princeton has DHCP issues with something or other. As a DHCP administrator, I have often investigated these issues myself, only to find that what Princeton claims, just isn't so.
I have little faith that they know what they are doing. I just think it's a bad admin, pointing the finger at a vendor.
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/
http://i.imgur.com/y7Hm9.jpg
At least they have the choice to play flash games while their online!
Wouldn't be the first bug report to go ignored. I'm still waiting for proper windows vpn support.