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

Steve Haskew <> Tue, 07 July 2020 13:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BAB173A0C5B for <>; Tue, 7 Jul 2020 06:04:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MkSPjWkvZEkC for <>; Tue, 7 Jul 2020 06:04:00 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 526DB3A0C59 for <>; Tue, 7 Jul 2020 06:04:00 -0700 (PDT)
Received: from [] ( []) (Authenticated sender: by (Postfix) with ESMTPSA id 648402602F0; Tue, 7 Jul 2020 14:03:56 +0100 (BST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Steve Haskew <>
In-Reply-To: <>
Date: Tue, 7 Jul 2020 14:03:54 +0100
Cc: captive-portals <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Tommy Pauly <>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <>
Subject: Re: [Captive-portals] CAPPORT support in iOS 14 and macOS Big Sur betas
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of issues related to captive portals <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 07 Jul 2020 13:04:02 -0000

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!


> On 22 Jun 2020, at 22:30, Tommy Pauly <> 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 <>
> 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