Opened 2 years ago

Last modified 2 years ago

#17567 new enhancement

Implement captive portal detection

Reported by: nephele Owned by: mmlr
Priority: normal Milestone: Unscheduled
Component: Network & Internet/Wireless Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description

For a laptop or other mobile device it is common that some wifi networks will block all network traffic until the user has authenticated over some kind of webpage.

Historically captive portal detection was often done like this:

  • make a http request to some known server you control
  • check the resonse for code 200
  • assume you have no cative portal

This is not so nice for privacy, and also because it wastes bandwidth. (it also seems like many OS still do it like this)

There are two relevant RFC we should implement for this.

The first one is RFC 8910
It descibes how to obtain a cative portal URI from DHCP4 DHCP6 and router advertisments

The second one is RFC 8909
It describes a HTTP+Json api over which the server can provision the cative portal uri, the venue uri aswell as seconds remaining for the connection and whether it can be extended. The seconds remaining and the extension status should be visible in the network preferences for the specific connection. The two uris might make sense to include there aswell.
If the user is still not autenticated to the captive portal the network status should display this accordingly, either by still beeing in the configuration phase or adding a new one for this. The wifi channel list should display this information, also in the icon, with a way to call up the captive portal for authentificiation.

Change History (1)

comment:1 by nephele, 2 years ago

I checked around a bit, it seems opennds supports this api (https://github.com/openNDS/openNDS)

So this can be used to test against.

Note: See TracTickets for help on using tickets.