So yesterday I tested hotspot extensively. In the beginning I had to restart the network via the utility. After that, my Steam Deck connected to the phone without any problems. At first it was just a bit of a hassle connecting to Steam, but the internet itself worked because I was able to play Diablo IV. Had no problems with hotspot for about 6 hours. The test continues tonight.
Thank you for the excellent work!
The CLAT changes have now been released in the latest 4.5.0. Don’t forget to remove your testing repo if your mobile data is working now with ssu rr.
Work still continues on VPN compatibility with CLAT.
@abranson and all the people testing and providing logs: Thank you very much for CLAT implementation.
I want to thank you all developers for your tremendous effort, and I am ready to test what I can. I have an Xperia III with an Italian Vodafone SIM in slot 1displaying in 4.5.0.19 exactly the same behavior as in 4.5.0.18, as follows (slot 2 is empty)
Am I missing something? How could I help solving this? Thank you very much!
A few things to verify/clarify/try:
Make sure your data call settings are reset to default. There’s a menu option at the top of its page to do that. I guess it probably should be ‘dual’, as most are, but leave it as default. Often in these situations it won’t work if you request ‘IPv6’ even if that’s what you end up getting.
There still seems to be a bug where a previously obtained IPv4 address isn’t released, and keeps popping up again even though it’s invalid. Once you’ve reset the data call settings, make sure you reboot to completely reinitialize everything so there are no lingering false addresses hanging around. It sounds like this might be what is causing the issues you state.
If you have VoLTE enabled, that uses one of those rmnet interfaces, with an IPv6 configuration. In normal operation on CLAT-requiring networks you will have two IPv6 interfaces running. The VoLTE interface will not carry internet traffic. It might be worth disabling it while you debug this, to avoid confusion.
Hope that helps.
Mobile data do not work at all, and never worked (except in the time interval between flashing and rebooting), on the Xperia 10 III with Vodafone IT: Unable to use mobile data on Sony Xperia 10 III 4.4.0.64
Confirm. Nothing changed, im still without mobile data. Plus PL.
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!
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)
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
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).
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.
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.