Support for Hotspot wifi captive portal via RFC 8910 and RFC 8908

pparent

Hi,

Just wanted to mention that a nice and easy addition to Ubuntu touch would be wifi captive portal via RFC 8910 and RFC 8908.

It is actually very simple:

1- When you get a DHCP lease in the wifi interface look for option 114
2- If there is a URL in option 114 it's an API, just make a simple HTTP GET request on this URL (no parameters or header)
3- The result will be a json, if it contains "captive"="true" and has an "user-portal-url" field then we should just open this "user-portal-url" in the browser and it will allow the user to authenticate to the captive portal and use the wifi!

Really I think that's any easy addition, I may try to contribute this inside the OS when I have time.

Ps: Adding a simple script in /etc/dhcp/dhclient-exit-hooks.d/ to do that should do the trick I guess.

pparent

So I've found a way to have hotspot detection working with rfc8910.

Here is the behaviour when I connect to a Hotspot Wifi compatible with rfc8910: https://www.youtube.com/watch?v=h-ZQgNzHpvQ

To have it working you need to add to the filesystem the following script:

/etc/NetworkManager/dispatcher.d/99-rfc8910

#!/bin/bash
# NetworkManager dispatcher script for handling DHCP Option 114 (RFC8910)
# Opens the captive portal with URLDispatcher if the network indicates a captive portal

logger "Option 114 init $1 $2" 
IFACE="$1"
STATUS="$2"

# Only proceed if the interface is up or dhcp4-change
if [ "$STATUS" != "dhcp4-change" ]; then
    exit 0
fi

# --- Retrieve the Option 114 value using dhclient test request ---
dhclient -1 -v -lf /var/lib/NetworkManager/dhclient-rfc8910-wlan0.lease wlan0
LEASE_FILE="/var/lib/NetworkManager/dhclient-rfc8910-wlan0.lease"
CAPTIVE_API=$(grep 'option default-url' "$LEASE_FILE" | tail -n1 | awk -F'"' '{print $2}')

# Remove escaped ampersands (\&) from the URL
CAPTIVE_API=$(echo "$CAPTIVE_API" | sed 's/\\//g')

if [ -z "$CAPTIVE_API" ]; then
    logger "No DHCP Option 114 found for interface $IFACE"
    exit 0
fi

logger "DHCP Option 114 detected for $IFACE: $CAPTIVE_API"

# --- Query the captive portal API using wget ---
API_RESPONSE=$(wget -qO- "$CAPTIVE_API")

if [ -z "$API_RESPONSE" ]; then
    logger "Failed to reach captive portal API: $CAPTIVE_API"
    exit 0
fi

# --- Parse JSON for 'captive' and 'user-portal-url' ---
# Extract the 'captive' status (true/false)
CAPTIVE=$(echo "$API_RESPONSE" | grep -oP '"captive"\s*:\s*\K(true|false)')

# Extract the 'user-portal-url' and remove all backslashes
PORTAL_URL=$(echo "$API_RESPONSE" | grep -oP '"user-portal-url"\s*:\s*"\K[^"]+' | sed 's/\\//g')

logger "Captive portal API response: captive=$CAPTIVE, portal_url=$PORTAL_URL"

# --- If the network is captive, open the portal URL via D-Bus ---
if [ "$CAPTIVE" = "true" ] && [ -n "$PORTAL_URL" ]; then
    USER_NAME=phablet
    sudo -u "$USER_NAME" \
        DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/32011/bus" \
        gdbus call \
            --session \
            --dest com.lomiri.URLDispatcher \
            --object-path /com/lomiri/URLDispatcher \
            --method com.lomiri.URLDispatcher.DispatchURL \
            "$PORTAL_URL" ""

    logger "Captive portal opened: $PORTAL_URL"
fi

Don't forget to chmod +x /etc/NetworkManager/dispatcher.d/99-rfc8910 and reboot

Tested on 24.04-1.x daily on OnePlus Nord N10

Unfortunatly the script is slightly hacky because it requires to make an external dhclient request. I've not found any other way around as the internal Network Manager dhcp client does not support option 114 in any way. We'll see if it can integrated to the system despite this, and if it can be slightly improved.

On what canal should I discuss with system devs about that?

pparent

Ps: we could add in the same script the "legacy" hotspot detection (on top of the RFC8010 detection) based on make a dummy http request on a dummy URL, and it could allow have a large compatibility to detect most hotspot portals on the market.

gpatel-fr

@pparent

A thought imposes itself though: why Network Manager is not already handling this by itself ?

Someone of course already had this idea.. A merge-request attempt followed that got quietly forgotten as happens all too often.

Note that in the issue description there is mention that in the favourite all devouring monster systemd there is something related. I did not follow up to see if systemd is not already providing it. I'd suggest you could do it though

If there is nothing useful in systemd, since network-manager seems a bit stranded (no release since mid 2024), possibly you could submit your change as a merge request in the UT version of it.

Disclaimer: as you know well I'm sure, this is not official advice of the Ubuntu Touch project with which I have no relationship.

pparent

@gpatel-fr

Yes but, that being said on desktop this feature is not as important as on mobile. Even in windows the portal does not open automatically, and it's handled browser-side. So on desktop it seems more "OK" not to have this feature system-side.

On Ubuntu Touch given that Morph does not handle at all captive portal internally, it seems to me very important to be able to open it automatically. I've seen several users complaining of not being able to use networks with captive portals, and even cited as one of the reasons they can't use it as a daily driver. (Example here: https://www.youtube.com/watch?v=HjfwyMuLnPo&t=475s )

I will look at the pull request you mentioned, thanks! Ps: Ha but it was not a merge request it was just an issue wasn't it?

gpatel-fr

@pparent said:

on desktop this feature is not as important as on mobile

I did not say that the feature was useless, what I was meaning is that when there is already a feature upstream it's not the best idea of reinventing it unless there is good reason that the upstream wheel don't fit the use case.

In fact upstreaming (when it makes sense) is in the UT COC, so somehow maintainers are supposed to think of that.

@pparent said:

it's handled browser-side

Hum, I did not even think of that. If Google has absorbed the idea in its gigantic browser, it could trickle in QT browser engine. That's another case where it could be better not to use a specific UT implementation.

@pparent said:

it was not a merge request it was just an issue

it was an issue but there is a MR linked (look under 'Development'). The idea is that it's a generic feature, not something specific to Ubuntu Touch. After all, mobile is far from a remote consideration for so called 'desktop' environments such as Kde and Gnome.

pparent

@gpatel-fr said:

The idea is that it's a generic feature, not something specific to Ubuntu Touch.

Well yes and no. It is a generic feature to detect option 114 and make the request to the API. BUT It is an OS sepcific feature to decide how you are going to display the captive portal. Here I display it using urlDispatcher via DBus that is an UT-specific feature that could hardly be upstreamed. Android has it's own mini-browser designed exclusively to display captive portal.

So this is kind of hard to have a generic way to handle captive portals in all OS that embed NetworkManager, independenty of the OS specifics. And all the existing OS (Android, iOS, Windows, MacOS) handle captive portal each, their own way.

I don't think in that regard UT should limit itself to what is availiable upstream, i.e keep basic things not working and not implemented, while it requires a 20 line script to have things running fine. If some day NetworkManager improve it's implementation, it will allways be time to use it then.

gpatel-fr

@pparent said:

this is kind of hard

yes

pparent

I've made a pull request here:

https://gitlab.com/ubports/development/core/hybris-support/lxc-android-config/-/merge_requests/184

projectmoon

@pparent so if I dump this script into the network manager scripts dir, it will Just Work?

pparent

@projectmoon

Yes!

Use the latest script from my PR:

https://gitlab.com/pparent/lxc-android-config/-/blob/main/etc/NetworkManager/dispatcher.d/99captive_portal?ref_type=heads

Make sure to make it executable (chmod +x) and reboot before testing

gpatel-fr

@pparent said:

it is an OS sepcific feature to decide how you are going to display the captive portal.

now you have seen the reaction to your MR

Quote from Gitlab:

I have a deep interest in captive portal as a feature being also available to other distros (such as pmOS or Mobian)

pparent

Here is what looks like a new prototype:

https://www.youtube.com/shorts/MrFvLvAq4bc

More info here:

https://gitlab.com/ubports/development/core/hybris-support/lxc-android-config/-/merge_requests/184#note_3271557185

projectmoon

@pparent so I was not able to get this script or app to work. Is there something I should look for in the logs?

pparent

@projectmoon

With the latest version of the script you need to install this app first:

https://github.com/pparent76/Captiveviewer-UT/releases/tag/0.1.0

Then install the latest version of the script, and chmod +x the script, and reboot

https://gitlab.com/pparent/lxc-android-config/-/blob/main/etc/NetworkManager/dispatcher.d/99captive_portal?ref_type=heads

Then you should get a notification when you connect to a wifi with captive portal, and if you click the notification it will open the captive portal app.

projectmoon

Ok I had to fix ownership and perms on the script. Portal app loads, but not the portal itself. But that's not the fault of the portal app.

pparent

@projectmoon

What do you mean, do you get the notification when you connect to the wifi network with captive portal?

(You should not open the app from the app grid, it is useless, it will open when you click on the notification, in the notification panel, like in the video)

projectmoon

@pparent yeah I got the notification and opened the app from it. But i couldn't load the page. But I think that it's a problem with my network configuration.

pparent

@projectmoon

Ok well I don't know, are you testing with a specific wifi network with captive portal? Does it support RFC 8910 and RFC 8908, or is it legacy? Did you try with other wifi networks?

Ps: You can also retry with mobile data disabled, sometimes it's better.

projectmoon

@pparent said:

@projectmoon

Ok well I don't know, are you testing with a specific wifi network with captive portal? Does it support RFC 8910 and RFC 8908, or is it legacy? Did you try with other wifi networks?

Ps: You can also retry with mobile data disabled, sometimes it's better.

Disabling mobile data didn't help. The app receives the captive portal URL, but I get connection refused. I don't think this has anything to do with the captive portal helper. I thought it might be uAdblock, but seems no. So, no idea. I also have no idea if the captive portal is RFC or legacy.