8 ms·
Updated iOS 6 devices don't connect to WIFI
- obilgic 14y agohttp://www.apple.com/library/test/success.html http://www.apple.com/library/test/success.html This is the url all iOS devices request as soon as they are connected to wifi. And It is currently down. Edit: It is back now. And this is the response: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <TITLE>Success</TITLE> </HEAD> <BODY> Success </BODY> </HTML>
- k-mcgrady 14y agoIt's not a problem with iOS 6. I've been running the GM for a week with no problems. This issue just appeared in the last couple of hours.
- geuis 14y agoAgreed. I've been running one of the last dev releases for weeks and have had 0 problems.
- christoph 14y agoI've just had the same problem. I can't understand how that page being inaccessible completely kills wifi...??!!? How does that make any technical sense whatsoever? I understand the reasoning, but for it to totally wipe out Wifi?
- bdz 14y agoThis is how does it work http://www.digitaltrends.com/mobile/apple-devices-call-home-when-on-a-wi-fi-network/ http://www.digitaltrends.com/mobile/apple-devices-call-home-...
- christoph 14y agoAs I said, I understand the reasoning. I just don't understand how it completely destroys wifi when inaccessible. Windows 7 does a similar thing, but when the page is inaccessible, it doesn't completely kill the internet connection. Basically, if Apples servers dissapear... Am I to believe that wifi becomes a useless feature on my iDevice, or am I missing a piece of the puzzle?
- bathat 14y agoAn iOS device is typically multi-homed. Think about what routing options the typical iPhone has and how it likely picks a default route.
- barrkel 14y agoI'd be willing to bet more than 40% of iOS devices are not multi-homed - iPod Touches and wifi-only iPads. From http://arstechnica.com/apple/2012/08/apple-lifts-curtain-on-ipod-touch-sales-figures-for-the-first-time/ http://arstechnica.com/apple/2012/08/apple-lifts-curtain-on-... : > Apple has sold 46.5 million iPod touch units in the US between the device's introduction in 2007 and the second quarter of 2012. (That's in addition to the nearly 86 million iPhones and 34 million iPads sold during that time.) iPod Touches alone are 28% of total iOS sales. If wifi-only iPads make up 60% of iPad sales (and I think they're probably higher), then that's 40%. Consider also that the turnover rate on phones is probably higher than the more focused devices.
- abhisec 14y agocan anyone explain why the f will wifi try to hit a html page http://www.apple.com/library/test/success.html http://www.apple.com/library/test/success.html is it just a pac file?
- fireix 14y agoYep I ran into the same issue and now looks like the page is up so its fine. So if it is a success its good if not redirects?
- dubcanada 14y agoNo, the way AP's etc work is on request of any url it verifies that they have logged in or done what ever. Since the iphone is requesting that URL it can detect if there is an AP and then prompt the login stuff. Really it's not that big of a deal lol.
- 0x0 14y agoWhat seems to have happened was that the people managing www.apple.com 404'ed the URL http://www.apple.com/library/test/success.html http://www.apple.com/library/test/success.html, which iOS loads automatically upon associating with a wifi AP. This causes iOS to believe the wifi is actually one of those public "captive" hotspots that redirects all HTTP before you authenticate/pay up, and fires up a modal web browser intending to let you log in. About 10 minutes later, they seem to have restored the URL, and normal wifi access points are no longer incorrectly detected as captive.
- obilgic 14y agoBasically: if apple.com is down, all the ios devices go down...
- 0x0 14y agoThe devices aren't down, they just fall back to 3G. If the page times out, I don't know what happens. But this time, the page explicitly responded with a 404, which it "should never do", so the device successfully detected a "MITM" and did the right thing. (Except in this case, apple.com webmasters screwed up)
- obilgic 14y agoYou are assuming all devices have 3G?
- 0x0 14y agoIn any case, if the wifi AP responds with "impossible" results, the wifi access point is for all purposes "unusable", and you wouldn't be able to get on the internet anyways.
- obilgic 14y agointernet connection != http://www.apple.com/library/test/success.html http://www.apple.com/library/test/success.html When did "successful wifi connection" mean having access to this unstable apple.com url?
- greggman 14y agoWait, you're saying if I can control that URL I can prevent all iOS devices in the world from connecting to the Internet ? That sounds seriously dangerous. Or am I mis-understanding?
- 0x0 14y agoIf you can control that URL, you can probably control ANY URL, and thus you can already prevent any (not just iOS) devices from connecting to the internet _via your wifi ap_. No surprises there. iOS falls back to 3G when the page doesn't respond as expected.
- eridius 14y agoIn fact, if you control that URL, then you are operating a captive network, which is precisely what accessing that URL is meant to detect.
- memnips 14y agoWhat if the URL gets successfully DDOS'd?
- philwelch 14y agoBecause your botnet will generate more traffic than every iOS device in the world connecting to a wifi network?
- caycep 14y agoi updated, didn't have any trouble
- eknkc 14y agoWell, gotta admit that I always liked my iPhone detecting an AP requiring some kind of user confirmation or something like that. It's a lame way to do it though.
- js2 14y agoChromium's design doc for handling captive portals (for comparison): https://docs.google.com/document/d/1k-gP2sswzYNvryu9NcgN7q5XrsMlUdlUdoW9WRaEmfM/edit https://docs.google.com/document/d/1k-gP2sswzYNvryu9NcgN7q5X... When a main frame HTTPS load is taking a while, we preemptively open a background request for http://www.gstatic.com/generate_204 http://www.gstatic.com/generate_204, and check the response code. We do the same when displaying SSL warnings and ERR_SSL_PROTOCOL_ERROR pages. The URL points to a service that returns HTTP 204 (“No Content”) responses, and the domain does not set any cookies or save any logs. If we’re not behind a captive portal, and connected to the Internet, we should get the 204 response code. If we’re behind a captive portal, we should either get the logon page or a redirect to one. If we get an error or a non-HTTP response, we’re either not behind a captive portal, or can’t find the logon page if we are. For the purposes of captive portal discovery, we treat all HTTP status codes except 2xx, 3xx, and 511 as errors. This works regardless of whether the captive portal works by intercepting DNS or HTTP traffic. We also preemptively run captive portal checks when displaying SSL certificate error pages, since these are often caused by captive portals as well. There is no timeout in this case.
- hahainternet 14y agoThis seems a fairly dangerous injection vector for malicious wifi APs. I assume that the browser is opening to the same URL and capturing that and redirecting to a malicious site should be trivial.
- waiwai933 14y agoWhat exactly stops an impersonator (or the operator of a captive network) from capturing/reproducing the content of http://www.apple.com/library/test/success.html http://www.apple.com/library/test/success.html and serving that to the iOS device? I could understand if it were over SSL, but it looks like this doesn't really do anything to stop a MITM attack.
- chrisbolt 14y agoThe purpose isn't to stop a MITM attack, it's to pop up a captive portal browser when you may be trying to use an app that isn't a web browser (Mail, Shazam, etc) and that would just not work.
- smashing 14y agoOriginal Issue Forum Post - Time: 05:56 PM First Negative Forum Post - Response Time: 06:00 PM (same day) : "I think this is the worst iOS release to date. And Steve would've never allowed this." Due of the Internet archive, these forum posts may well be our greatest legacy.
- swilliams 14y agoI had a similar, but separate issue - after upgrading to iOS 6, my wifi was disabled and wouldn't turn back on. Tried messing with settings, airplane mode, resetting network settings and restoring, but nothing worked. Doesn't look like I'm the only one either: https://discussions.apple.com/message/19620439#19620439 https://discussions.apple.com/message/19620439#19620439 Fortunately the Apple Store replaced it. Free too.
- tomflack 14y agoAnyone else having trouble connecting to corporate networks with a self-signed certificate?
- zurn 14y agoApple would do a lot of good if it didn't have these kludges for "captive portals", maybe people would stop using them then. They're just connection hijacking, a horrible idea for a million reasons and break most HTTP applications.