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. 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? Thanks for your efforts in getting this implemented! Steve > On 22 Jun 2020, at 22:30, Tommy Pauly <tpa...@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
