Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Android Cellphones Networking Wireless Networking

Bug Forces Android Devices Off Princeton Campus Network 309

Posted by Soulskill from the your-computer-is-broadcasting-an-ip-address dept.
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."
This discussion has been archived. No new comments can be posted.

Bug Forces Android Devices Off Princeton Campus Network More

Bug Forces Android Devices Off Princeton Campus Network

Comments Filter:

  • WTF? (Score:5, Insightful)

    by killmenow ( 184444 ) on Tuesday April 19, 2011 @07:17AM (#35866460)
    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?

    • Re:WTF? (Score:4, Interesting)

      by klingens ( 147173 ) on Tuesday April 19, 2011 @07:34AM (#35866556)

      If they didn't, It'd be harder to pull stunts like closing the Honeycomb source.

      Android uses the Linux kernel, nothing more that is GPLed. Even their libc is developed inhouse. Tho, dhcp-client by ISC has a very permissive license. Little bit of advertising, that's all. Closing the source is allowed.

      • Even their libc is developed inhouse

        I thought it was the netbsd libc.

      • Re:WTF? (Score:4, Interesting)

        by teh31337one ( 1590023 ) on Tuesday April 19, 2011 @07:49AM (#35866712)

        If they didn't, It'd be harder to pull stunts like closing the Honeycomb source.

        They haven't closed the source, they're delaying the source because they're worried about the user experience when it inevitably gets ported to a phone. At the moment, honeycomb is designed to work on 1280x800 screen res devices, and that's it. They''ll release the source when it's ready.

        • Re: (Score:3, Insightful)

          by Swampash ( 1131503 )

          They haven't closed the source, they're delaying the source because they're worried about the user experience when it inevitably gets ported to a phone.

          So they've closed the source then?

          When it has been released THEN it will be open. Until then it's closed.

          • Re: (Score:2, Informative)

            by Anonymous Coward
            They've closed the source of Honeycomb (I think this is where the GP misread him) but to date not Android. Remember that Honeycomb is a tablet-only fork. Real Android devices haven't been affected by the closure... and hopefully will stay that way (2.4 at least should be open).

          • so they're closed because they won't release honeycomb until it's ready, but they're open (almost entirely) otherwise?

            Do you see how fucking backwards that is?

            If you replace honeycomb with "windows 8" and reverse the terms, do you realize how wrong the statement is?

          • They haven't closed the source though. They just haven't opened it up yet (which is completely different)

          • Re: (Score:3)

            by Speare ( 84249 )
            If users have the hardware (Xoom, et al), they're using the software; if the software is GPL'd, the users have the right to the source code. Whether it's Google or Motorola, the case is the same: they're in violation of the license if they haven't made source available for GPL'd software that users are using.

      • Re: (Score:2)

        by rumith ( 983060 )
        Google has reiterated [blogspot.com] that they do plan to publish Honeycomb source code. And when they say that it's not ready for the prime time, they actually mean that Honeycomb was rushed to please Motorola and was supposed only to be run on Xoom. That both Xoom and Honeycomb are beta-quality at best is another matter. I believe that it's quite smart of Google to keep Honeycomb source closed: this way, we only have one crappy device with an unfinished OS; if they published the source code right now, we would have hund

    • Re: (Score:2, Interesting)

      by poetmatt ( 793785 )

      as linked below, someone needs to ask apple what the hell they're doing too. [princeton.edu]

      • Re: (Score:2)

        by Rhaban ( 987410 )

        as linked below, someone needs to ask apple what the hell they're doing too. [princeton.edu]

        They will sue google for counterfeiting the behaviour of their DHCP client?

      • From the same:

        "On July 15 2010, Apple released iOS 3.2.1 (build 7B405) for iPad (first generation). We verified that iOS 3.2.1 does not exhibit this bug."

      • Re:WTF? (Score:4, Informative)

        by Tharsman ( 1364603 ) on Tuesday April 19, 2011 @09:57AM (#35868108)

        Someone needs to read the links they post. Your linked article clearly states it was promptly fixed.

    • 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?

      It's not clear that the Linux DHCP client would play nice with the power-management shininess that Google bolted on to Android (and were never accepted into the kernel mainline). This is bolstered by the fact that the steps for reproducing the issue involved connecting to wifi, letting the device lock/sleep and observing wonkiness when it wakes up (search for 'STEPS TO REPRODUCE THE BEHAVIOR' in the OP, I don't want to copypasta too much).

      My guess is that the lion's share of the issues have to do with timer

  • The first link in this article causes NoScript to complain about a script attempting to access local LAN resources.

    # Prevent Internet sites from requesting LAN resources. Site LOCAL Accept from LOCAL Deny

    Anyone care to comment on what that is all about?

  • From ipod antennas to this?
    • no, the strategy today is to get something that mostly works out the door as fast as you can. That way you can gauge how much people use it and decide to invest resources into patching it.

  • Interesting problem (Score:3)

    by erroneus ( 253617 ) on Tuesday April 19, 2011 @07:24AM (#35866498) Homepage

    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?

    • Re:Interesting problem (Score:4, Interesting)

      by Overzeetop ( 214511 ) on Tuesday April 19, 2011 @07:40AM (#35866616) Journal

      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.

    • Re:Interesting problem (Score:5, Informative)

      by Wannabe Code Monkey ( 638617 ) on Tuesday April 19, 2011 @08:11AM (#35866878)

      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.

      • At least its an improvement in that their previous DCHP bug renewed its lease every couple of minutes - sometimes up to a half dozen times per minutes. That bug dates back to the 1.x code base. I wonder if this bug as a result of a fix for their previous DHCP bug.

      • Re: (Score:2)

        by Artifex ( 18308 )

        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.

        Funny, seems like the same group reported that iOS has had the same problem: http://www.net.princeton.edu/announcements/ipad-iphoneos32-stops-renewing-lease-keeps-using-IP-address.html [princeton.edu]

        Wonder why only Android was mentioned for this story?

    • Re: (Score:2)

      by Inda ( 580031 )
      Turning it off and on again?

      I'm serious.

    • I wonder what the best solution would be?

      IPv6 stateless autoconfiguration...

  • 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?

  • and it will never be fixed (Score:5, Interesting)

    by Anonymous Coward on Tuesday April 19, 2011 @07:25AM (#35866514)

    oh, google will fix it. But there will be carriers who will never roll those fixes out to their users.

    • Please mod parent up.

      And there will also be manufacturers who will take their sweet time in even developing an update for their devices for the carriers to never release. Yes, I'm talking about you, Samsung.

      The trouble is, handsets are being released at such a frenzied pace that, with the availability of updateable firmware, there's this rush to get products out the door that aren't entirely done, with the assumption that they'll be fixed via a software update. However, it also means that that new devices

    • And this is, IMHO, one huge benefit to owning an iPhone instead: you get your updates directly from Apple, bypassing the carriers.

  • Wut? (Score:2, Insightful)

    by somersault ( 912633 )

    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.

  • 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.

  • 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:

    Why Haven't Other Sites Reported This Particular Issue?

    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

  • Didn't they see the warnings in the scifi movies? Give an android an inch and he'll take a mile.

  • OIT sucks (Score:3, Informative)

    by Anonymous Coward on Tuesday April 19, 2011 @07:53AM (#35866736)

    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...

  • 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...

    • Many others probably do have the problem but haven't noticed due to lax monitoring. Their users just experience poor service (which they may have come to expect).

    • Re: (Score:2)

      by jrumney ( 197329 )

      Didn't Princeton have a similar problem with iPhones

      Yes. Confusingly the story about iPhones having the same basic problem is linked to from the summary under "...disrupting Wi-Fi traffic for Android and non-Android devices alike."

      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...

      As IPv4 addresses become a scarce commodity, expect more organizations to start controlling more tightly how they are use

  • Apparently their server has been affected.  Clearly if they've banned the Android devices, the outage is caused by something else.

  • 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.

  • 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.
  • See, this is exactly what Apple was talking about. This is why Apple had to sue Samsung [telegraph.co.uk]... these things are copying Apple [princeton.edu]!

Slashdot Top Deals

A physicist is an atom's way of knowing about atoms. -- George Wald

Close