Re: [Captive-portals] CAPPORT support in iOS 14 and macOS Big Sur betas

Hi Steve,

Glad you’re testing is going well so far.

> On Jul 7, 2020, at 6:03 AM, Steve Haskew <steve@boaz.org.uk> wrote:
> 
> Hi Tommy,
> 
> I have now been doing some testing of our solution with iOS 14 and it has been fairly straightforward in getting it all working at a basic level!
> 
> I have a couple of observations/queries:
> 
> Just to confirm, are you not yet supporting any of the informational elements (venue info URL, seconds remaining etc) since you say the user experience is not changing? Despite setting these values I am not seeing any difference.

That’s expected. The iOS 14 beta doesn’t include any changes to the Wi-Fi settings. There are ways to check for the values being parsed in system logs if you want to confirm, however. 

> 
> Secondly I have on a few occasions been directed by probe instead of via the API. I am working to replicate this with packet capture etc so that I can determine whether it’s variation in my setup or any kind of bug, but it is also likely just because I am repeatedly logging in and out and jumping on and off the network in question! Do you know what the criteria is (timeout values on the API request, any retries on the API request? etc.) for fallback to probe method?

If you can submit a feedback/bug with system logs attached when you see this behavior, we can look into it. There are various error heuristics for when we fail to receive a valid API connection. Likely we’re hitting one of those, but it would be good to confirm which.

> 
> Thanks for your efforts in getting this implemented!

Thanks for implementing it too!

Best,
Tommy
> 
> Steve
> 
> 
> 
>> On 22 Jun 2020, at 22:30, Tommy Pauly <tpauly@apple.com> wrote:
>> 
>> 
>> Hello CAPPORT,
>> 
>> I wanted to highlight an announcement we’ve made for the betas of iOS and macOS released today:
>> 
>> How to modernize your captive network <https://developer.apple.com/news/?id=q78sq5rv>
>> 
>> The betas for iOS and macOS support both draft-ietf-capport-rfc7710bis and draft-ietf-capport-api by default. This doesn’t change the user experience of logging onto captive networks, but the system will request the DHCP options and handle the RA option, and will prefer using the Captive Portal API Server interaction over having a probe that is intercepted.
>> 
>> If you have a portal system that is already implementing the CAPPORT features, please test out these betas and let us know if you see any issues! And if you have a captive portal solution, we’d encourage you to start supporting this soon.
>> 
>> Best,
>> Tommy
>> 
> 
> _______________________________________________
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals