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

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/ubports/development/core/hybris-support/lxc-android-config/-/merge_requests/184/diffs

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