@arubislander said:

@pparent Where was this announced?

Well "annonced" maybe was not the correct term, but it was at least mentioned as a possibility here:

https://www.phoronix.com/news/Fairphone-6-Linux

Just out of curiosity, in the end is the fairphone 6 supported by mainline linux kernel as annonced?

@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

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?

@brenno.almeida

Nice! Your app could be very useful especially to receive notifications in background with lower battery costs.

Hope the whatsmeow library can remain reliable in the long run!

Maybe you would like to post some screenshots of your app?

@brenno.almeida

Very nice!

How do you interact with Whatsapp protocol? Did you reverse ingeneer it yourself? Do you use an existing library?

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.

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?

I'm wondering about something, as this problem is an IP loss problem, I think it should be noted that by defualt NetworkManager uses it's internal dhcp handler. But it is also possible to configure it to use dhclient. And I wonder if the later would not be more reliable.

So I think I will test to change the configuration of my NetworkManager to use dhclient, and see if it has any impact on this bug.

@arubislander said:

Although, to be fair the creator of the WhatsNew app has taken measure to suspend the app when it looses focus as well

I've not done that specifically in whatsnew. What happens is that normally when an electron app is not anymore in foreground it goes into a "throttling" mode meant to keep operating the website but with lower resources. This is a feature from chromium.

That being said I have no idea why XWayland/electron apps don't get suspended by default. For Signal UT or Whatsnew it is handy to get background notifications though.

The behaviour encountered by @smobilesoft (high CPU usage) is not normal , I've not been able to observe it myself, and it seems since he reinstalled the app it has gone. So this is a bit strange.

@smobilesoft

Ok well this is very strange.

Well it's possible that whatslectron take a lot of CPU on some occasions. For example when syncing messages. But this should not be a recurrent behaviour that drains the battery when the app is in background.

If there were 2 windows remaining this could explain the problem, but I don't see how uninstalling and reinstalling the app could have any effect on that, as you now seem to have the proper behaviour i.e the second window closing after few seconds.

But, so do you still have the battery drain problem?

@smobilesoft

Hum this is kind of strange as I don't observe anything similar. For me "Whatslectron" which is the process behind whatsnew, takes 1-3% CPU when in background (more or less the same that whatsweb consumed when unsuspended)

Question:

-What version of Ubuntu Touch are you using precisely? Stable or daily?

-When you use Whatsnew, when you go in the window carousel, do you see one ore two window corresponding to whatsnew, and what icon does it have under it?

-What is precisely the name of the process you see in top taking 100% CPU? Is it "Whatsnew"? "whatslectron"? Something else?

-Could you give me the result of "md5sum /lib/aarch64-linux-gnu/liblomiri-private.so" in your terminal?

@smobilesoft

Well it could help if when the battery is draining fast, you can go to the terminal and type "top", to see what program is using a lot of CPU.

@UBportsNews

I have 2 questions:

-Is there any ongoing plan to developing support for RCS? I think this could be the next blocking point for Ubuntu Touch, so I may contribute to a project to support RCS given that I can find time for that.

-What role and importance do you think offering options for all the most popular messaging protocols, have for UT's potential for adoption as a daily driver? Both the standard ones like SMS, MMS, RCS, email, but also the private ones like Whatsapp, Telegram, Signal, and even Facebook messenger?

Thank you so much for everything!

@diardaoin

You can try to update to 24.04 from the settings app in the update panel from your 20.04 install. Does it propose you the update there?

You should have a much better experience with 24.04 in the long run, and more compatible apps from the openstore!

VoLTE works for me, though sometimes the VoLTE connexion is lost after loosing network and does not necesarilly reestablish automatically.

I've just published version 0.1.6, that corrects the app that was broken by a change upstream in Whatsapp web;

Here is the changelog of the version:

• Adapt to a change upstream that broke the app
• Improve ContentHub to Import/Export files
• Fix broken app on 24.04-1.x daily

I've only tested the main features, I've not had the time to do a comprehensive testing before releasing the new version, but as it was broken it's always better to have something that works. If you find any new bug, or thing that does not work anymore with this new version or since change in Whatsapp web, please do not hesitate to report.

@danfro said:

I couldn't reboot with the power button since that was somehow blocked

I really don't think this can have anything to do with running Signal UT, including the patch I've shared above. I don't see how the app could have an impact on the effect of your power button. Especially because it's confined.

@danfro said:

I can't close it, when swiping into the drawer, it becomes a transparent window which I can't swipe to close

I see that happening from time to time, including with other apps. I think it's more a Lomiri bug. Anyway you can just start another time the app, and kill the launcher indicator, it should kill the remaining transparent window.

Or if you want to use commands in the terminal you can try to paste this in the terminal, it should fix the crash in 24.04-2.x branch (but will not solve the OSK problem):

sudo sed -i "s/\[ \"\$?\" -ne \"0\" \]/\[ \"0\" -ne \"0\" \]/g" /opt/click.ubuntu.com/signalut.pparent/current/launcher.sh
sudo sed -i "s/\[ \"\$?\" -eq \"0\" \]/\[ \"0\" -eq \"0\" \]/g" /opt/click.ubuntu.com/signalut.pparent/current/utils/filedialog-deamon.sh 

@danfro

Well no problem really, I was'nt getting you wrong!

Actually it is possible to do a small edit through the terminal to make sure the app does not crash, I will explain in post bellow.

But if the OSK still does not work I'm not sure it will be very usefull. And the OSK problem in 24.04-2x seem to concern all XWayland apps (including uWold and Chromium for UT)