After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 739994 - Captive portal detection doesn't work if network limits HTTPS access
Captive portal detection doesn't work if network limits HTTPS access
Status: RESOLVED DUPLICATE of bug 747866
Product: NetworkManager
Classification: Platform
Component: general
0.9.x
Other Linux
: Normal normal
: ---
Assigned To: NetworkManager maintainer(s)
NetworkManager maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2014-11-12 07:31 UTC by Oded Arbel
Modified: 2015-07-16 14:26 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Oded Arbel 2014-11-12 07:31:19 UTC
Recently a network with captive portal that I frequently use has changed their configuration in that they now do not allow DNS lookup through their network before authenticating. 

I'm not sure how this affects other devices, as my Android phone still detects the captive portal, but on Fedora 21 the captive portal detection stopped working - I get a question mark on the network manager wifi display, but no captive portal pop-up. If I type an host name in a browser, I get DNS timeouts while if I type an IP address, I get redirected to the captive portal login screen (which uses a non-routable IP address without a DNS name).

I get this error in the system log, but no captive portal detection:

Nov 12 09:11:52 mionior NetworkManager[691]: <info> Connectivity check for uri 'https://fedoraproject.org/static/hotspot.txt' failed with 'Error resolving 'fe
doraproject.org': Name or service not known'.
Comment 1 Thomas Haller 2014-11-12 09:41:49 UTC
You enabled the "connectivity" check via the NetworkManager configuration:

[connectivity]
uri=https://fedoraproject.org/static/hotspot.txt
response=OK
interval=300

Probably, you installed NetworkManager-config-connectivity-fedora package which provides this configuration. If you want to disable this configuration, remove the package.




How does it work for you if you change the configuration to specify the IP address?

For that, remove the package and add the following to NetworkManager.conf

[connectivity]
uri=https://66.35.62.166/static/hotspot.txt
response=OK
interval=300


(or add a file /etc/NetworkManager/conf.d/21-connectivity-fedora-my.conf):
[connectivity]
uri=https://66.35.62.166/static/hotspot.txt


(restart NM afterwards)


In such an environment, how does detection of captive portal work? I mean, if you type into your browser http://www.google.com, it will fail to resolve the DNS name (and not redirect you to the captive portal).
Comment 2 Oded Arbel 2014-11-12 19:42:37 UTC
OK, my bad - not sure if the DNS timeouts I had was a temporary failure or me misunderstanding the actual problem, which is that the captive portal blocks HTTPS (port 443), so access to Google search (over HTTPS) is blocked, but HTTP traffic gets redirected to the captive portal (I assume its likely to solve the problem of Android devices and Chrome browser throw up a really frightening error message when the captive portal tries to redirect an HTTPS request).

Because the default fedora connectivity is over HTTPS, it never succeeds and you get the error message I've pasted above (which I still get), or this (that I got now):

Nov 12 21:32:32 mionior NetworkManager[21318]: <info> Connectivity check for uri 'https://fedoraproject.org/static/hotspot.txt' failed with 'Could not connect: Network is unreachable'.

After I've changed the configuration file to use only the HTTP protocol, everything started working again.
Comment 3 Dan Williams 2015-07-16 14:19:44 UTC
We should get Fedora to change to just HTTP anyway, for a variety of reasons.  See bug #747866 for more details.

But in any case, should NM just "s/https/http/" for the moment internally and log a warning?  I think that's probably the best option.
Comment 4 Dan Williams 2015-07-16 14:26:42 UTC
Actually, I'm just going to dupe htis bug to that one...

*** This bug has been marked as a duplicate of bug 747866 ***