GNOME Bugzilla – Bug 699509
Support NetworkManager connectivity checking
Last modified: 2013-11-21 14:57:22 UTC
NetworkManager includes support for connectivity checking to determine whether a machine actually has access to the internet and whether or not it may be behind a captive portal. Since portals are so awful and rarely implement standards, NM implements two OR-ed checks: 1) an HTTP header, "X-NetworkManager-Status: online" 2) body content, which by default is "NetworkManager is online" which are done whenever network connections change or (by default) every 120 seconds. We haven't turned this on by default in any distributions that I know of, mainly because there hasn't been a generic server with good reliability that we can use for this. So I'd like to propose that gnome.org host one for now. A quick PHP page for this would be: <html> <?php header('X-NetworkManager-Status: online'); ?> NetworkManager is online </html> Obviously GNOME wouldn't necessarily use PHP, but you get the idea.
We can easily set up a vhost on one of our machines, what I need is: - the subdomain you're going to use: i.e nm.gnome.org or similar - the code that you plan to use for the check Please provide me the following details, so I can move forward and put this up.
What about a page off of the main networkmanager site? http://projects.gnome.org/NetworkManager Dan, could you create a page there named online with the contents of something like: "NetworkManager is online" http://projects.gnome.org/NetworkManager/online Then in the projects.g.o apache vhost config I'm relatively confident (untested) this will work: <Location /NetworkManager/online> Header unset ETag Header set X-NetworkManager-Status online </Location> Then in the nm code you could do a HEAD http request like I simulate here with netcat: [jschroeder@desktopmonster ~]$ nc projects.gnome.org 80 HEAD /NetworkManager/ HTTP/1.1 Host: projects.gnome.org HTTP/1.1 200 OK Date: Fri, 03 May 2013 00:07:52 GMT Server: Apache/2.2.15 (Red Hat) Last-Modified: Thu, 02 May 2013 10:06:26 GMT ETag: "1abf6-195d-4dbb9632a6c80" Accept-Ranges: bytes Content-Length: 6493 Connection: close Content-Type: text/html; charset=UTF-8 That should be less overhead than a GET request even if only marginally. It would also not include the ETag which doesn't make a lot of sense for checking if the host is online. Thoughts gentleman? A subdomain seems massively overkill when you can do this faster with an apache config tweak.
This is broadening the term a bit but we have api.gnome.org, currently used by evolution, it could also have a NM part; the good thing over projects.gnome.org is that it's clear to us we have software depending on the existence of that very URI and content. (reusing an existing page on projects.gnome.org looks like too easy to miss when migrating stuff).
1) I think large downstream vendors of GNOME (Canonical, Red Hat, etc.) should have copies of this page, and NM should try them first 2) Does NM try to reuse the Microsoft or Apple ones at all? Are there legal limitations to doing so?
Agree with Colin and Frederic. First rely on api.gnome.org, but also check if we can use the Microsoft thing.
Dan was also mentioning the Android implementation on IRC yesterday. For reference I think it's at https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/net/CaptivePortalTracker.java .
I think there are all sorts of external things that we could use from different vendors out on the internet, and most are going to provide better performance and reliability than anything we host on gnome.org. But it's not performance and reliability that we can rely on as a project. That especially refers to anything hosted by Apple/Microsoft/Google/etc - companies that have no relationship to our software. I don't see any real issue with handling tens of millions of requests a day if: - We don't share the web server processes with anything dynamic - We don't log the requests At that point, probably the web server isn't the bottleneck compared to the network card - but you could further hyper-optimize it arbitrarily. [ That being said - if we have someone shipping millions of copies of NetworkManager it would be nice if they would reconfigure NM not to use our service - especially if there's a 120s ping frequency (is that necessary to make it that fast?) or provide resources to handle the service. ] While we may be somewhat limited at what we can configure now by an IP address shortage and not wanting to get complex, to make sure that we have the flexiblity to do whatever we want in the future, having a separate domain name seems like a good idea. Even if we have a separate domain name, I'd suggest using an URL that isn't / - that is, say http://nmcheck.gnome.org/check_network_status.html - so that we can do: nmcheck CNAME www.sponsoring-company-with-cool-multihomed-network.com.
There's another alternative, for GNOME to pay a 3rd party CDN such as Akamai or Amazon Cloudfront.
Dan: Thanks to the sysadmin team it looks like we'll have a vhost on one of the servers very soon. Can you provide some details on what code or static page we'll need to host there? Are we cool with Owen's suggestion of the hostname and URL? "http://nmcheck.gnome.org/check_network_status.html"
comment 0 explains what NM checks for. Since returning a specific HTTP header probably requires PHP or something, and we want to keep the load down, it's probably better to go with the specific body content. So, you want the URL to be a plaintext file containing "NetworkManager is online" (with or without a newline after it). The URL doesn't matter, although to be accurate, it should be ".txt", not ".html". You can test by adding [connectivity] uri=http://nmcheck.gnome.org/check_network_status.txt or whatever to /etc/NetworkManager/NetworkManager.conf (although not with stock Fedora packages, since we're still building without connectivity-checking support).
OK, it should be there now at http://nmcheck.gnome.org/check_network_status.txt. I did set it up on a machine that currently doesn't run any other vhost than nmcheck. In addition I did disable logging completely for the whole httpd. Let me know if you need anything else on my side.
The GNOME Infrastructure Team is currently migrating its bug / issue tracker away from Bugzilla to Request Tracker and therefore all the currently open bugs have been closed and marked as OBSOLETE. The following move will also act as a cleanup for very old and ancient tickets that were still living on Bugzilla. If your issue still hasn't been fixed as of today please report it again on the relevant RT queue. More details about the available queues you can report the bug against can be found at https://wiki.gnome.org/Sysadmin/RequestTracker. Thanks for your patience, the GNOME Infrastructure Team