

Updated iOS 6 devices don't connect to WIFI - obilgic
http://forums.macrumors.com/showthread.php?t=1446596

======
0x0
What seems to have happened was that the people managing www.apple.com 404'ed
the URL <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
Basically: if apple.com is down, all the ios devices go down...

~~~
christoph
I just checked this - If I block apple.com on my router, wifi on my iPad
becomes unusable when reconnected. When re-enabled, no problem.

Apple just fell quite a few points for me.

~~~
0x0
What kind of blockage did you set up? A hijacking 404/403 HTTP response, or
are you dropping IP packets to the www.apple.com IP addresses? If your router
blocking is implemented on the HTTP level, then obviously you would see the
same result as everyone just did when that URL returned 404.

I'd be more interested in learning how iOS reacts when TCP (HTTP) connections
to that URL time out, or are treated as a closed port.

~~~
christoph
I just went to the parental access control section on the router (a free
router the ISP gave me) and set apple.com to block.

I guess if you're a large corporate and you don't want iPads/iPhones using
your wifi, this is an absolutely great way to block them with zero effort!

------
js2
Chromium's design doc for handling captive portals (for comparison):

[https://docs.google.com/document/d/1k-gP2sswzYNvryu9NcgN7q5X...](https://docs.google.com/document/d/1k-gP2sswzYNvryu9NcgN7q5XrsMlUdlUdoW9WRaEmfM/edit)

 _When a main frame HTTPS load is taking a while, we preemptively open a
background request for<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._

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

~~~
bdz
It is like a self-DDOS now.

~~~
mattdw
It just came back up. Phew.

~~~
bdz
Yeah, I guess the problem was that everyone in the US started the update
process nearly at the same time.

------
greggman
Wait, 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
If 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
In fact, if you control that URL, then you are operating a captive network,
which is precisely what accessing that URL is meant to detect.

------
k-mcgrady
It'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
Agreed. I've been running one of the last dev releases for weeks and have had
0 problems.

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

------
christoph
I'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
This is how does it work [http://www.digitaltrends.com/mobile/apple-devices-
call-home-...](http://www.digitaltrends.com/mobile/apple-devices-call-home-
when-on-a-wi-fi-network/)

~~~
christoph
As 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
An iOS device is typically multi-homed. Think about what routing options the
typical iPhone has and how it likely picks a default route.

~~~
barrkel
I'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-...](http://arstechnica.com/apple/2012/08/apple-lifts-curtain-on-ipod-
touch-sales-figures-for-the-first-time/) :

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

~~~
bathat
Ok, yes, I was a little cavalier in my phrasing, and didn't communicate what I
meant (which was roughly "iOS devices with a cellular radio"). iPhones and
iPads with cellular radios _are_ typically multi-homed. Edit: And "typically"
does not mean "exclusively."

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

------
swilliams
I 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>

Fortunately the Apple Store replaced it. Free too.

------
eknkc
Well, 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.

------
waiwai933
What 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> 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
The 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.

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

------
fireix
Yep 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
No, 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.

------
tomflack
Anyone else having trouble connecting to corporate networks with a self-signed
certificate?

------
caycep
i updated, didn't have any trouble

