Some positive news (expected, but always welcome), after 4.5.0.19 update (CLAT), after removing connman 1.32+git194.3 + the clat test repository, the phone can be used as hotspot with my IPv6-only operator. With plain vanilla 4.5.0.18 the hotspot did not work. CLAT is doing its work OK!
VPNs (Nord- and Proton-) still do not work (expected): one new ‘feature’ with those still useless VPN settings is that if you have the Advanced → Disable IPv6 Yes and you attempt to turn that VPN on, it is a kiss of death to the network connection, the VPN will not connect but the non-VPN network will not come back, either. If the setting remains Default, the VPN connects but has no effect whatsoever (ipleak dot net site). Same operator, different SIM, same network, a gulag phone: both (paid) VPNs work as expected on the aforementioned lP-leak test site. When needed, I can provide more logs, as I did above.
Sony Xperia 10III user here. On 4.5.19 ja mobil (t-mobile de/congstar reseller) hotspot now working with protocol dual - which did not work before.
Thanks for your work!
There seem to be issues still with a couple of providers. Can’t say for certain that CLAT is the answer to these, but if anyone on those networks could collect some logs as described at the top of this thread then it’s possible that they might give a clue towards how this fix could be extended to cover those networks. Please make sure that your data call settings are set to the default for your testing.
The Xperia 10 that I use as internet gateway ‘for everything in the house’ provides now a much more ‘reactive’ connection, will say, response to user actions (clicks, interactive pages) is noteable faster now. Pages with a lot of pictures (e.g. gmx.at, orf.at) load much faster now.
This is both on the phone and on a laptop connected with the mobile access point of the phone.
Provider is Vodafone Spain.
Thank you so much!
To all of you with Vodafone as provider, try to set connection type for the Vodafone SIM slot to IP only!
In my case Vodafone Germany still provides IPv4 addresses and it help to solve my connections problems with Vodafone under 4.5.0.19.
(IPv4 mobile data connection not possible - #106 by Fubo)
Under
Settings → cellular networks → in the affected sim card area → Data access point → Protocol
i’ve switched to “IP” instead of “IPv6” or “Dual” for the Vodafone Germany sim card, for which an IPv4 address is provided
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?
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).
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.
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.
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.
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.
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™
