GNOME Bugzilla – Bug 609870
Test for captive portal before putting applications in online mode
Last modified: 2020-11-12 14:27:28 UTC
Currently, if I connect to a wireless network with a captive portal, NetworkManager signals all of my applications to go into online mode immediately. This is not appropriate because internet access is not really available yet, and the applications will all show errors that they cannot access their respective servers. Upon connecting, NetworkManager should test for the ability to reach a public Web site. If the test fails, it should run a user-configured command to perform the portal login and then retest when the command terminates. By default, the command could be a browser (with an option telling it to work online even though the global status is still offline), or the user could substitute a custom program that knows how to log in to the particular portal. In contrast to bug 379523, this proposal would not have NetworkManager actually perform the portal login.
see also some discussion in bug 620932, and in http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/TODO (In reply to comment #0) > In contrast to bug 379523, this proposal would not have NetworkManager actually > perform the portal login. I think dcbw's feelings on the matter have changed since then.
NetworkManager has a "connectivity checking" feature now, but there doesn't appear to be a way to get existing applications to treat the "captive portal" state as offline short of modifying them individually. https://lists.fedoraproject.org/pipermail/devel/2012-March/164026.html
We should update GNetworkMonitor to deal with this; that's bug 664562
*** Bug 514304 has been marked as a duplicate of this bug. ***
Notes... * We need to distinguish 4 different states: (1) no/unknown connectivity, (2) stuck behind a captive portal, (3) not behind a portal but not connected to the global interface, (4) full connectivity. Currently 2 and 3 are both represented by NM_STATE_CONNECTED_SITE. * In the case of wispr or HTTP status 511, we may have a login form URL to return to some user process; we might want to have another agent API, for apps to be able to register as portal-logging-in-to agents. (https://mail.gnome.org/archives/networkmanager-list/2013-February/msg00128.html) We're not adding wispr/511 support right away, but we don't want to have to totally redesign the API when we do. * The "not globally connected" state must be advisory only, because it's not completely foolproof. (Likewise, in some cases it's ambiguous whether a response means "behind a portal" or "not globally connected", so we should not force the user into "portal login" mode in this case.) Also, in some cases, the portal may allow access to some sites even without logging in (eg, access to skymall.com from airline wifi), so we don't want apps to treat portal mode as "offline". * There should be some way for the "portal login agent" to ping NM to recheck and update its status.
OK, pushed fixes/changes to danw/portal branch: - NMManager now has a "connectivity" property that can be used to distinguish captive-portal from limited-connectivity; in terms of NMState, they are both still represented as CONNECTED_SITE - There is also a "connectivity-hints" property that is currently always empty, but in the future can be used to pass a portal login URL, and possibly other information. (If we think there will never be any other information, we could just make this be a single login url property, rather than a hints hash table...) - There is a CheckConnectivity method that will make NM re-check connectivity immediately, which the shell or whoever could call after doing a portal login.
(In reply to comment #6) > OK, pushed fixes/changes to danw/portal branch: > > - NMManager now has a "connectivity" property that can be used to > distinguish captive-portal from limited-connectivity; in terms of > NMState, they are both still represented as CONNECTED_SITE > > - There is also a "connectivity-hints" property that is currently > always empty, but in the future can be used to pass a portal login > URL, and possibly other information. (If we think there will never > be any other information, we could just make this be a single > login url property, rather than a hints hash table...) > > - There is a CheckConnectivity method that will make NM re-check > connectivity immediately, which the shell or whoever could call > after doing a portal login. Had you seen the Agent-based interface stuff I'd speced out a while back? That used agents for the portal handling, pushing the login URL and details to the agent and having the agent return whether or not to check connectivity again immediately. I was concerned about exposing these details to everything on the system; at least we have some control over the agents and we ensure they are in a session blah blah etc.
(In reply to comment #7) > Had you seen the Agent-based interface stuff I'd speced out a while back? Yes, though I only looked quickly. I guess was thinking that the agent interface wouldn't make sense until we also added wispr support, and so we didn't want to bother with that now. But maybe not? > I was concerned about exposing these details to everything on the > system There's nothing private/interesting in the properties I added. In the non-wispr case, I don't think it makes sense to have NM try to keep portal secrets. There's really no plausible way to extract the info from the (possibly-multi-page) random HTML login form. But maybe even without secrets the agent-style interface still makes more sense.
Oh, I didn't mean NM should necessarily keep the secrets at this time. I think that whatever actually handles the portal login should handle that too. I just thought that instead of exposing public attributes on the NM interface that most things don't actually care about, it might be cleaner to keep them in the agent interface, because the agents are already things that handle passwords and other requests, so they can also handle the requests for portal login. One issue with having the portal URL properties be on the main NM interface is that you can then no longer have two things that might listen to them installed, otherwise you get multiple login windows. The agent interface handles that already by allowing one agent to answer the request at a time. This wouldn't really be connected to the existing secrets stuff, just that the agents are an existing means of answering certain authentication requests, plus we can enforce permissions against them with PolicyKit, and we can track what they are doing.
repushed to danw/portal, without the ConnectivityHints property, but also without the agent interface. We may want to do a 0.9.8.4 release for GNOME 3.10 / F20, and it would be good to get this at least partially in. These patches will make it possible for the shell (or other observers) to distinguish "behind a portal" from "limited connectivity". The shell can then try to take some action if it wants. In a future release, we can add the agent API so that NM can explicitly ask the shell to act, and it can pass additional information to it.
Branch looks good, with the sole exception of the authentication for the connectivity check request methods. They should be authenticated with the NETWORK_CONTROL permission so that users who cannot control the network can't call the method either. I think impl_manager_deactivate_connection() is the simplest example of that.
This also looks easy to extend in the future with the agent stuff so that we get better portal detection including the login URI, so yay.
pushed with fixes. leaving this bug open for the implementation of the login agent
Hi Dan, you may also be interested in bug #704416
(In reply to comment #13) > pushed with fixes. leaving this bug open for the implementation of the login > agent The login agent was implemented in gnome-shell, did you want to leave this opened to provide a helper for other desktops?
Further improvements that we need to do here: Per-device connectivity checks with a new Device property for connectivity. This would happen during the IP_CHECK state in parallel with the gateway ping stuff; this implies that portal state blocks device activation, of course. This requires a few things: 1) binding the HTTP requests to the device with libsoup https://mail.gnome.org/archives/libsoup-list/2012-December/msg00011.html It looks like all the necessary bits are in glib 2.22+ and libsoup 2.37.4+ (April 2012), so we should be fine to depend on them. 2) probably doing our own name resolution of the connectivity server from the URL using the connection-specific DNS servers, then reconstructing the URL and doing the check. otherwise the system-global servers from resolv.conf get used, and that's not what we want. We can use soup_uri_*() functions to get the server name and set the new IP address after resolution. We then need to add the un-resolved URI into the HTTP request's "Host" header to support HTTP virtual hosts. The full added header should be: Host: hostname[:port-if-not-80] 3) We may need to play around with rp_filter on the device during connectivity to ensure that the response comes back to us correctly; ISTR that fixed some issues when interfaces are connected to the same network. That's not a problem before DEVICE_STATE_ACTIVATED, but when doing the periodic checks later, it could be, since we'd be flipping rp_filter randomly which could mess up other apps? Need to be careful after DEVICE_STATE_ACTIVATED. 4) The global connectivity property would be the "best" state out of all the per-device states, such that if one device was PORTAL and one device was FULL, the global state would be FULL. --- Clients that want to care about per-device state (like GNOME Shell) would be updated to watch the per-device connectivity property instead of the global one, so that they could show the portal window whenever a new connection was activated even if it was not the primary connection.
We may also need to add a 'connectivity-changed' dispatcher event, that would run whenever connectivity changes for an interface.
bugzilla.gnome.org is being shut down in favor of a GitLab instance. We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time. If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/ Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).