Hi Steve, Glad you’re testing is going well so far.
> On Jul 7, 2020, at 6:03 AM, Steve Haskew <st...@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 <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 _______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
