Confirm. Nothing changed, im still without mobile data. Plus PL.
2 Likes
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.
Thank you for this update!
3 Likes
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!
3 Likes
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.
1 Like
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!
1 Like
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.