Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reliable modern Captive Portal advertisment / Provide API for use in Captive-Portal notification using DHCP Option 114 (according to RFC 8910 and RFC7710bis) #8261

Open
2 tasks done
jp-vienna opened this issue Jan 29, 2025 · 0 comments

Comments

@jp-vienna
Copy link

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

Is your feature request related to a problem? Please describe.

Some devices, especially iOS devices, detect the precence of a captive portal only unreliably, sometimes not showing the captive portal at all, sometimes only after repeatedly forgetting the network. This leads to a lot of frustration and users blame it on the network, not the device.

Describe the solution you like

Implement the features as suggested in How to modernize your captive network

Make settings available in the captive portal service setup to setup captive portal advertisment as following:

1.) Provide an API Endpoint separately from the regular http captive portal to deliver at least the min. JSON response over https, as outlined in https://datatracker.ietf.org/doc/html/draft-ietf-capport-api , for example:
{ "captive": true, "user-portal-url": "https://example.org/portal.html", "venue-info-url": "https://flight.example.com/entertainment", }
The full implementation of the API as outlined in draft-ietf-capport-api-08 would be best.
2.) Make the captive portal available over https for the user-portal-url, but keep the http access available in parallel to maintain legacy compatibility (http redirections)
3.) Enable Router Option 114 accordingly in the active DHCP (ISC and/or KEA)

Describe alternatives you considered

Current captive portal implementation by http redirection is unreliable, especially in context of iOS device.
Using https for delivery of the captive portal works even less reliably or not at all. No alternative suggestions exist.

Additional context

https://datatracker.ietf.org/doc/html/rfc8910
https://developer.apple.com/news/?id=q78sq5rv
https://datatracker.ietf.org/doc/html/draft-ietf-capport-api
https://datatracker.ietf.org/doc/html/draft-ietf-capport-rfc7710bis

The whole topic may be extended to IPv6 DHCP and IPv6 RA.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

1 participant