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)
It does not work for Vodafone IT, since it only provides an IPv6 address.
Where is this setting? I can’t find it in Settings/Mobile network and also not elsewhere.
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
1 Like
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™ 
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 .
Tested. Compared to git194.10 now IPv4 does not leak 
while IPv6 still does. Looks better, thanks! I’ve sent you the dumps and logs by e-mail.
1 Like