Today a small blog post about a real headache I had with Fedora and public WiFi in hotels or at events and such places. If you work remote like me you hop from wifi to wifi all the time. Hotels, airports, venues… connect to the wifi and normally you get the portal page to accept the terms or login. Only after that internet works.

Except on Fedora this portal page never showed up. A simple workaround that helps most of the time is open a browser and go to something like http://neverssl.com. Then it often redirects to the portal.

I did some digging to find out what is going on. Here is the thing.

Why Fedora has trouble with captive portals

Its not only Fedora. Many distros do this captive portal check in networkmanager now. They ask a special url and expect a certain answer back. If they get redirected or something else they know there is a portal and show the login page.

Fedora for example fetches http://fedoraproject.org/static/hotspot.txt and wants to see just “OK” with http status 200. If networkmanager gets anything different or a redirect it figures you are behind a captive portal.

In theory this probe works fine. But in real life those portals are not always nice to it.

The issue is often HSTS

The real problem comes from HSTS. HTTP Strict Transport Security. The fedora check domain has HSTS enabled.

- Host fedoraproject.org was resolved.
> GET /static/hotspot.txt
> Host: fedoraproject.org
< HTTP/2 200
< strict-transport-security: max-age=31536000; includeSubDomains; preload

HSTS is a security thing. It forces https only and tells the system to never try unencrypted http for this domain and all subdomains. And it remembers that for a long time, here one year.

Captive portals can only mess with normal http traffic. They cant touch https. They wait for you to load some http page so they can hijack it and show their login screen.

But if your system already knows about HSTS for fedoraproject.org it will never even try the http version. So the probe fails, no portal page appears. And once it learned the rule it keeps it, even on your normal network later. Detection stays broken for quite a while.

Making Fedora’s Captive Portal Work Again

You can get around it by telling networkmanager to check a different url. One without HSTS, plain http only. Best if you control it yourself and keep it simple.

Here is what worked for me:

  1. Don’t touch files in /usr/lib/

    Fedora puts the config in /usr/lib/NetworkManager/conf.d/20-connectivity-fedora.conf.
    Dont edit it directly, Updates can just overwrite your changes.

  2. Copy the config to /etc first

    So your changes survive updates.

    sudo cp /usr/lib/NetworkManager/conf.d/20-connectivity-fedora.conf /etc/NetworkManager/conf.d/20-connectivity.conf

    Now edit the copy in /etc.

  3. Edit the file and point to your own http page

    Open it with your editor:

    sudo vim /etc/NetworkManager/conf.d/20-connectivity.conf

    Change the uri line to your own host. Or just use my workaround host if you want.

    My final file looks like this:

    [connectivity]
enabled=true
uri=http://http.mgz.de/hotspot.txt
response=OK
interval=323

    What matters: your page must return just the plain text “OK”, nothing else, no html around it. If your page returns something different just change the response= line too.
    If you dont have your own server you can host a simple one cheap on digitalocean, hetzner or linode. Just upload a plain text file with OK and make sure it is reachable over plain http without https redirect or hsts header.

  4. Restart NetworkManager

    sudo systemctl restart NetworkManager

    Thats it. Next time you hit a portal wifi it will probe your url instead. If it does not get back OK or gets redirected you should see the sign in page again.

Not only on Fedora

Of course this applies same to most linux systems which use network manager. On Ubuntu you also just create the file /etc/NetworkManager/conf.d/20-connectivity.conf with the same content.

Stay connected out there.