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/shorts/0et6I-lwwwQ

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.