iOS 14 modernized captive network issue?

Hi, I am attempting to use the new captive network DHCP advertisement in option 114 as described here: https://developer.apple.com/news/?id=q78sq5rv

I configured my network's dhcp server (dnsmasq) like the following:

Code Block
dhcp-option-force=114,https://wifi.mysite.com/v1/captive

(wifi.mysite.com does resolve and have a valid https cert within my network, and the API response is valid per the spec)

When I associated an iOS 14 device (iPhone) to the network, it successfully was assigned a DHCP address and included the new option 114. However, it seems that it does not attempt to query the captive portal API specified in option 114 (no dns or https request for is seen wifi.mysite.com in a packet capture at my AP). Instead, the iPhone does an HTTP GET of http://captive.apple.com/hotspot-detect.html. Seems like it is behaving just like an iOS 13 or below device with respect to captive networks, even though the new dhcp option is present.

Some additional info: my network is ipv4 only, and I've already tried forgetting the SSID on the iPhone, DHCP release/renew, rebooting the iPhone.


Answered by lmanonius in 645264022
I'm also experiencing the same issue described in previous POSTs. Is Apple ever going to fix this (or is even aware)?
This feature is very important to get rid of HSTS redirection among other details that in legacy captive portal aren't optimal.
I find it strange releasing this feature this way as it defeats the purpose if on first join the portal ain't triggered.
I have a similar problem, but it seems that iOS reverts to the legacy detection method only on the first connect. When I connect to the network the second time, it uses the API endpoint from the DHCP option. It appears that iOS does not even try to use the new method on first connect. From the console, on first connect (or after forgetting the network and connecting to it again):

com.apple.captive default 12:04:40.051877+0300 configd en0: Probing 'portal2'

After this, I can see from dnsmasq's logs that iOS attempts to resolve captive.apple.com.

On the second attempt, I get the following in the console, followed by the captive portal opening correctly:

com.apple.captive default 12:08:19.191328+0300 configd en0: Evaluating API 'portal2'

I can also see from dnsmasq's logs that on both occasions the iPhone did ask for DHCP option 114 and received it.


Same problem here, the first time I join the network it uses the old method and makes an GET to http://captive.apple.com/hotspot-detect.html. However, if I rejoin the same network a second time (without forgetting the network inbetween) it uses the new DHCP option 114 and opens the captive portal as described in https://developer.apple.com/news/?id=q78sq5rv.


Accepted Answer
I'm also experiencing the same issue described in previous POSTs. Is Apple ever going to fix this (or is even aware)?
This feature is very important to get rid of HSTS redirection among other details that in legacy captive portal aren't optimal.
I find it strange releasing this feature this way as it defeats the purpose if on first join the portal ain't triggered.
I am still experiencing this issue. Not sure who to contact @apple about it besides posting in this developer forum?

Not sure who to contact @apple about it besides posting in this
developer forum?

Regardless of what else you do, you should file a bug about the problems you’re having. Please post your bug number, just for the record.

Beyond that, it’s not clear how you can get formal support for this. My organisation, Developer Technical Support (DTS), supports captive network APIs (like NEHotspotHelper) but does not support the default on-the-wire behaviour. You may be able to get support for this from Apple Support but I’m not sufficiently up to speed on their support policies to know for sure.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"
I created a bug report as suggested by @eskimo here: https://feedbackassistant.apple.com/feedback/8901099


there has been no response to my bug report since I opened it 8 months ago.

I just took a look at your bug (FB8901099, right?) and, AFAICT, you marked it as resolved on 19 May 2021 )-: It sounds like that was unintended. I’m not sure if there’s a way to undo that, so my suggestion is that you create a new bug report, with a reference to the old one.

You should make sure to include Wi-Fi logging information in your new bug. Note that the Wi-Fi for iOS profile is available on our Bug Reporting > Profiles and Logs page. I just checked and that version has definitely not expired (-:

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

iOS 14 modernized captive network issue?
 
 
Q