I then used a colleague's phone to get what the DNS for that captive wifi is, and also the appended domain suffixes to be searched. Since this all goes away when you are disconnected in about a second, I took a screenshot so I could read what it said for my IP. Using Sumit's description as inspiration, I clicked to connect to the wifi button, then on the second that the wifi seemed to connect I hit the i icon which takes you to the screen where you can see your assigned IP address, submask, and router IP. 0.2), I would try to connect to the wifi and then after maybe a second would be disconnected. Since I upgraded to iOS 11(.0.1 and then.

Similar to what moooooog35 experienced, my company has wifi with a captive portal that is accessed via https. The link to the original discussion is here, but I'll copy the suggestion here to help those only browsing the iOS forums. Is this a known issue and/or is there any workaround from an end-system perspective? I did not find any topic like this on the forums as of yet.Ī user sumit.modi over on the Mac OS 10.3 forum gave a suggestion that worked for me on iOS 11 (.0.2). This is hugely problematic as there is no workaround for end systems other than for system administrators to disable the https requirement for the captive portal. The new beta systems, though, just disconnect the wifi connection immediately. In currently released iOS and Mac OS's, the wifi connection does not drop - it just simply won't display the portal when our redirection is issued. This appears to be neglected by the new OS's captive network assistant which then, simply, drops the wifi connection completely. Our company's captive portal has the option to force end systems to use https for it, so if it receives an http request for a portal, it responds with a port 443 redirect request. I've noticed that my Apple devices running ios 11 and Mac OS 10.13 High Sierra will disconnect their wifi connection immediately if the server responding with captive portal uses https.

Xcode 11 high sierra