You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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.
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.
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.
The text was updated successfully, but these errors were encountered: