Re: [PATCH 0/5] Handle HTTP error 511

[Jonh Wendell <jonh wendell gmail com>]

2013/2/11 Dan Williams <dcbw redhat com>

On Mon, 2013-02-11 at 12:09 -0200, Jonh Wendell wrote:
> From: Jonh Wendell <jonh wendell oiwifi com br>
>
> This series of patches fixes (on the NM side) bug #670394.

Thanks for working on this!

One thing I'm wondering is how we'd more quickly see whether the portal
login was successful or not so we could change our NM state to show
"online connected" instead of behind a portal.  There's two options
here:

1) check every 5 or 10 seconds for connectivity until connectivity is
successful; but this might make some portals angry

That's what I'm doing right now. It does *not* make portals angry. That's what happen in real life, when someone joins the WiFi and thousands of user programs try to reach the internet. What the hotspot do is just redirect them and reply the http requests with a 302 Moved.

This leads to a discussion which I was expecting to have far later :) : should we make connectivity code mandatory (right now it's compile-time optional) and use some global machine (something like status.gnome.org) to do the check.

 

2) have some mechanism for whatever handles the portal login to indicate
to NetworkManager that login was successful, or that NM should
reconnect/retry DHCP.  If this is what we want to do, we could move the
captive portal stuff into the Agent interface since those processes are
somewhat authenticated (as we already ask them for secrets) and they'd
theoretically also have access to any portal auto-login credentials.

I didn't understand this point. Do we have something already authenticated? I guess not. Even if the user already supplied the WiFi credentials (WPA, etc) he's still behind a captive portal, and will still be redirected.

 

Also, I got some captures of a portal in a hotel I was in recently, and
for any HTTP request it returned (1) 305 Found with a Location header
pointing to the next location, then (2) 302 Moved with another Location
header pointing to the actual login page.  In this schemed we'd somehow
detect this and then stuff the #2 Location URL into the login-url
property I guess?

That would be certainly great to have. I'll think on that when implementing the 'Moved 30x' thing.

 

Dan

> Basically we added a new method in the API: CaptivePortalState (), which
> returns a boolean indicating whether we are behind a captive portal, and a
> string that contains the login url, as supplied by the captive portal.
>
> The main change is in the internals of NMConnectivity object: We check if the
> http status is 511 and the try to discover the login url. Currently we only check
> for the url in the <meta> html tag. There's room to improve this in the future.
>
> Next step will be to patch gnome-shell to make use of this new API and show to
> the user a nice UI.
>
> For convenience, these patches are also hosted on github:
> git://github.com/jwendell/NetworkManager.git (branch rfc6585)
>
> Jonh Wendell (5):
>   connectivity: change the "connected" member for a more generic one
>   connectivity: Add libxml2 as a dependency
>   connectivity: Add the private member login_url
>   connectivity: check for http response code 511
>   api: Added the method CaptivePortalState()
>
>  configure.ac                 |  14 +++-
>  introspection/nm-manager.xml |  20 +++++
>  src/Makefile.am              |   4 +-
>  src/nm-connectivity.c        | 190 ++++++++++++++++++++++++++++++++++---------
>  src/nm-connectivity.h        |  22 +++--
>  src/nm-manager.c             |  43 ++++++++--
>  6 files changed, 234 insertions(+), 59 deletions(-)
>

--
Jonh Wendell
http://www.bani.com.br