Testing CLAT for IPv6-only mobile networks

Thank you @Fubo , now I could find it. On Vodafone Spain SIM there is selectable: IP, IPv6 and Dual. In the moment Dual is selected and it works. I will try out the other options and after that report here what happened.

edit:
with IPv6 selected I can’t establish a connection, only 2G is shown and no internet connection is possible. Not even after a reboot.
After switching back to auto a reboot is necessary but then it works again.

BTW / off topic: now it is possible to power off the Xperia 10 in a normal way even with plugged in charger. (For years it always rebooted immediately after power off with plugged in charger)

Coming night I will set it to IPv6 again and check tomorrow morning if connection is established. Maybe it needs some time to self-configure with the network.

edit: With IPv6 selected the phone does never connect to the 4G network. After abt. half an hour it connects to a 3G network. No 4G connection is possible.
After switching back to ‘Dual’ it also doesn’t connect. It was necessary to activete flight mode, then disable flight mode, and after this it searches new for networks and then it reconnected to 4G and works again as before.

IPv6 does not work on Xperia 10 / SFOS 4.5.0.19 in the Vodafone Spain network in the present state.
Any ideas what to do, or how can I help on developing/troubleshooting?

1 Like

Testing CLAT improvements for VPN

Jussi is continuing to improve connman’s IPv6 handling after the introduction of CLAT in the 4.5.0.19 release. I’ve created a new repository for this, as we don’t want people who added the old repository to accidentally start testing this new version (and everyone should remove that repository from their ssu config with ssu rr now, because it’s been deleted).

If you want to try this out, you can add this repository.

Note that you shouldn’t need to change your data call settings at all from the default, and they’re not guaranteed to work even if you know which IP version you’re supposed to be getting. On the whole it’s best left as ‘dual’. Please see the first post in this thread for information on how to set up detailed logging before your testing and collect those logs afterwards to send to us to at connman-debug@jolla.com. We’d be especially grateful to get some logs from connection failures on the Vodaphone IT or ES networks, which seem to have caused some problems for users.

3 Likes

Just gave this a try. Browserleaks.com shows exactly the same data with vpn enabled ir disabled. Will collecting a log with vpn enabled be enough?

Tested with ipleak.net (ProtonVPN), shows all ISP addresses like having no VPN. Sending the logs now.

Thank you for giving it a spin. Apparently CLAT does still operate when you have VPN connected. I had to change direction here and to make ConnMan kind of aware of the CLAT in order to attempt for the VPN to function as if there was no CLAT.

But now the logs should be collected from different sources, this should be changed in /etc/sysconfig/connman to :
SYSCONF_ARGS=-d plugins/clat.c -d src/connection.c -d src/inet.c -d src/service.c -d plugins/vpn.c
and restart connman (systemctl restart connman) or the whole device.

And when you have VPN running try also https://ipv6-test.com and have tcpdump running on both VPN and CLAT interfaces with tcpdump -i <interface>, one for each, like:
tcpdump -i clat > clat.dump
tcpdump -i vpn0 > vpn.dump (provided vpn runs on vpn0)

This is mainly to see what data is going over which interface, if you wish to see it in realtime, please drop the > *.dump. If no data flows over vpn interface still then there is something wrong with the routes still.

And because these logs may contain personal information (internet traffic) we are not requiring you to send them as is. You can voluntarily send the tcpdumps in order to help debugging this problem and when preferred, you can anonymize the logs as well (remove IP addressing info). But if you decide to send the tcpdumps it will mean that you consent that we handle the data in according to GDPR as personal data. In addition, the data you send will be deleted after 30 days. This was omitted from the original post, sorry about that, but all old logs have been treated in similar manner.

With a vanilla 4.5.0.19 install i also use an openvpn vpn (see my related Feature Request Make IPv6 payload work in openvpn).
My network provider (KPN in The Netherlands) has recently changed to IPv6 only with CLAT i need a few workarounds before i’m able to use my VPN:

  • When setting up the VPN usually a host route is created for the IP address of the host on the other side of the tunnel. This fails, probably because the default gateway has a device but no gateway address. Because the default gateway is moved to the VPN the VPN tries to route it’s traffic into itself which obviously doesn’t work. My workaround is to create this route myself before starting the VPN
  • Because openvpn somehow doesn’t use the IPv6 configuration pushed to it, the default gateway for IPv6 keeps routing to the mobile data connection. My workaround is to remove this default gateway.
  • Because the CLAT traffic is actually just IPv6 traffic where IPv4 addresses are embedded inside IPv6 prefixes just removing the IPv6 default gateway breaks the tunnel connectivity. My workaround is to add a route for 64::/16 to the gateway that was used by the default gateway.

With these workarounds in place my VPN works as expected.

I still have problems with the clat interface, half of the time it doesn’t come up on a network change(switching from wifi to mobile data loosing connection etc.) Sometimes i need to reenable the mobile data connection several times ti get the clat interface up. Often Aliendalvik completely looses the network connection and needs to be restarted.

1 Like

I still have some issues if I go to France. I have no data and Sailfish ask me to start my phone again, as he thinks I inserted a SIM card. Once I’m back in Switzerland, everything works as before.

My operator is: Digitec
Network automatically choosen by Sailfish in France: Orange FR

Thanks for your report. That version did not have support for VPN yet. It WILL function in weird manner.

OpenVPN, and most of the VPNs, except OpenConnect, have only IPv4 support. That comes from ConnMan upstream originally. I cannot make any promises of adding IPv6 for them. So any IPv6 configuration locally or as a push goes to /dev/null.

The VPN support should just do that what you did. It does inject the CLAT IPv4 details into the cellular service inside ConnMan so the use would be transparent and work similarly to without CLAT having the normal IPv4 support.

For clarity, could you provide an example of this for others to use as well? If the recent changes in hopefully soon published 1.32+git194.11 version are not enough we would like to hear if adding that kind of route would help.

Which version are you using? Could you send the logs with the sysconfig options detailed in Testing CLAT for IPv6-only mobile networks - #134 by jlaakkonen

And remember to check that the journal has enough space reserved for the massive amount of logging, instructions were in post Testing CLAT for IPv6-only mobile networks - #11 by jlaakkonen

1 Like

No problem, i can do it tommorow.

I’m not sure what you mean, can you please elaborate?
I have been using this VPN for years on my FP2 and never had any problem.

Aha, i actually assumed connman used the openvpn binary which is available on the system, according to the help (openvpn --help) IPv6 support is available. I’ll see if i can use this instead of the GUI/connman method.
Personally i think lacking IPv6 support in a connection manager is a no-go these days.

Sure. In the mean time I learned that the actual prefix should be 64:ff9b::/96 (see IPv6 transition mechanism - Wikipedia and https://www.rfc-editor.org/rfc/rfc6052.txt).

I’ll just share the script i made to make the VPN work. The loop at the start is just to wait for me to start the VPN via the GUI, i’m not aware of a way to do that from CLI.

#!/bin/sh

BASEDIR="/home/defaultuser/vpn"
HOME_IP=x.x.x.x
HOME_DNS=y.y.y.y

if [ "$1" = "start" ]
then
 # Wait for VPN
 echo "Now start VPN from settings "
 ip address show vpn0
 while [ "$?" = "1" ]
 do
  sleep 1
  ip address show vpn0
 done
 sleep 5

 # Fix IPv4 settings
 ip route add $HOME_IP dev clat
 cp /etc/resolv.conf $BASEDIR/resolv.conf.old
 echo "nameserver $HOME_DNS" > /etc/resolv.conf

 # Fix IPv6 settings
 ip -6 route | grep "^default " | cut -d " " -f 1-5 > $BASEDIR/def-gw6.old
 ip -6 route add `cat $BASEDIR/def-gw6.old | sed -e "s/default/64:ff9b::\/16/"`
 ip -6 route del `cat $BASEDIR/def-gw6.old`
fi

if [ "$1" = "stop" ]
then
 # Undo IPv4 settings
 cp $BASEDIR/resolv.conf.old /etc/resolv.conf

 # Undo IPv6 settings
 ip -6 route del `cat $BASEDIR/def-gw6.old | sed -e "s/default/64::\/16/"`
 ip -6 route add `cat $BASEDIR/def-gw6.old`                               
fi

It’s intended to be run as root, variable HOME_IP is my home IPv4 address which is the other endpoint of the VPN. HOME_DNS is the DNS for when the VPN is running, somehow the setting pushed via the VPN is ignored.
Intended use is to save as vpn.sh and use ./vpn.sh start and ./vpn.sh stop to start/stop the VPN. I’m sure it’s quite hacky, but it works for me™ :slight_smile:

The topic is about CLAT. CLAT with that version you have has no support for VPN. The one that has, is mentioned in post 131. And now it has been updated to 1.32+git194.11.

ConnMan uses a specific binary for each VPN type. The plugins for using these binaries have no IPv6 support, except the aforementioned OpenConnect. The plugins come mostly from ConnMan upstream.

No-one said that there is no IPv6 support. ConnMan relies on most IPv6 functionality on the kernel.

Thanks. I’ll need to take a closer look on that later on. Basically that should be done by ConnMan so it would be completely aware of the routing changes. Some events come through netlink but cannot be sure if it is enough, cannot remember that part.

Added a small fix that pauses prefix query for the time VPN is connected over CLAT. This updates the version to 1.32+git194.11. Please try it out and tell us if it makes any difference.

Alternative to this fix would have been attempting to keep the DNS server of the cellular service, i.e. the transport of the VPN and have a static route for it but with IPv4 VPNs, to which this is targeted at and which consist the major portion of supported VPNs, it would mean a direct DNS and in most cases a data leak rendering VPN useless.

Thanks for your answer.

I’m sorry, i misunderstood your remark.

Ok, so the plugin is the actual cause of the VPN being IPv4 support, good to know. Thanks.

I hope to have some time to test with the repo next weekend. I do have one question: The first posts tells about the risk of needing to re-flash. How big is this risk? My install and getting all my data in was a painful process and i don’t want to risk to re-do that :slight_smile: .

Tested. Compared to git194.10 now IPv4 does not leak :+1: while IPv6 still does. Looks better, thanks! I’ve sent you the dumps and logs by e-mail.

1 Like

If you have already done some devel-su over USB ssh the risk is about nil - there is no risk of a clat version bricking your phone that I can imagine. Of course, when one works as root and can destroy everything as super user, that’s one risk but the only one I can see. Probably your are familiar with the most of the below, sorry about that, but for the record (also for myself) I put here how I work to contribute back the logs Jussi may find helpful (he cannot get connected to our IPs), in no time:

Add the repository, only once, of course, until told to move to another repository - you can use clattest or whatever name you like:

ssu ar clattest <the URL link from @abranson latest post about new repository>

You want to remove it ? (at least before next Jolla’s update to the next official version)

ssu rr clattest

I keep the repo as long as there is no Jolla updates coming, it is stable enough.

After adding (or removing) the repository use pkcon (or zypper)

pkcon refresh
pkcon update

If you remove the repository and get back the original rpm’s one may need to force the downgrade, I did that once but found it too cumbersome, I just keep Jussi’s clat version(s) until it becomes official from Jolla.

I created, on my computer the following text file to memorize how to turn on Jussi’s required debug settings:

cat <<EOF >/etc/sysconfig/connman
SYSCONF_ARGS=-d plugins/clat.c -d src/connection.c -d src/inet.c -d src/service.c -d src/provider.c -d src/network.c -d plugins/vpn.c
EOF
mkdir -p /etc/systemd/journald.conf.d/
cat <<EOF >/etc/systemd/journald.conf.d/debug.conf
[Journal]
Storage=persistent
RateLimitIntervalSec=0s
RateLimitBurst=0
SystemMaxUse=100M
RuntimeMaxUse=2M
EOF
systemctl restart systemd-journald
systemctl restart connman

Just cut and paste the above to the command prompt.

To run the dump before you launch the connection / and during the connection to (like) http://ipv6-test.com or https://ipleak.net (not sponsored, I’ve been using these for some reason, there are others),

you would run, in one shell window (if vpn0 is the device name, it may change)

tcpdump -i vpn0 > vpn0.dump

and on another shell window

tcpdump -i clat > clat.dump

I noticed that most of the time, with VPN the clat device dump was empty. Or at times, the device is not there. Report this information, anyway.

And finally, you can copy the script as a bash-shell script from @abranson post (very first post in this thread) to collect the log files in an archive to post (not here but by e-mail to connman-debug@jolla.com - the dump-files without the log files are not enough. (You may want to change $(date +%Y%M%d_%H%M%S) with $(date +%Y%m%d_%H%M%S) for correct month - not a big deal if you don’t.)

To finish your debugging session and calm down the verbose logging, you can memorize, like it is done above the following commands to continue to use your phone normally:

rm -f /etc/sysconfig/connman
rm -f /etc/systemd/journald.conf.d/debug.conf
systemctl restart systemd-journald
systemctl restart connman

Of course, you can also reboot, but remove the configuration files with debug settings first.

3 Likes

Thank you. These logs were useful. I hope the issue pointed by them is now solved with 1.32+git194.12 that is available in the same repo. The IPv6 issue is under work.

Confirmed with the procedure above. tcpdump clat - device is now rock solid when the VPN connection is set off/on/off/on… Log files in your Inbox by now.

1 Like

After a closer look, yes, I agree that the script is hacky. Following things arose while testing and checking that:

  1. Why do you have /16 as the CLAT prefix length? By default and according to the RFC it is defined int he global prefix is declared with /96 prefix length.

  2. Removing the default route is kind of a tricky case with the default traffic going over IPv6. There are many reasons: in many cases the address is delivered with router advertisements or DHCPv6, so it would be set back at some point. And in my tests apparently kernel can enforce it back as well. So might it be enough just to add the extra route? It might be that the gateway setting within ConnMan causes this to be re-added, which might not be the case with real CLAT (I can only fake so much…)

  3. Adding the IPv4 DNS as sole DNS service in the resolv.conf, which normally points to ConnMan’s own dnsproxy is usually really bad. But then again, that version you had of CLAT support the VPN side, as said, was not intended to work. Might be better to add a nameserver with connmanctl, like:
    connmanctl config $(connmanctl services|grep <visibleVPNnamehere>|grep -o "vpn_.*$") --nameservers <DNSServerHere>.

But after looking at that I got some ideas and those should be in 1.32+git194.13 when it is built. However, the gateway setting needs apparently improvements. Just noticed that. It is lacking support for the injected CLAT IPv4 in the sense that two separate indexes for a service should be supported. That is something for the next week. The route to the VPN IP (in OpenVPN terms, “trusted_ip” that is called via the openvpn-script back to ConnMan) should be then set correctly when VPN connects over CLAT.

1 Like