1.32+git194.1 (post devel merge of the original CLAT branch) now building. The aim now is to get VPN working over CLAT.
1 Like
I guess this is not related to CLAT changes but I’ll take a look on the logs. Any idea on the timecode when it happened? It would narrow down the search.
1 Like
A note for all: this is highly experimental. In theory it should work but without the possibility to test that it may be just complete either or.
1 Like
A little bit offtopic although I am not participating actively in this testing I am very happy to see this interactive development and testing cycle with the community. It would be great to see this for other areas of the OS that it makes sense → connman modification & test scenarios could be great to test things that have been plaguing the OS when switching between WiFi & Data and so on for example. Great work! 
3 Likes
Sorry, if this happens again, i’ll rake a new log and check the time.
Installing the new clat version right now.
I just tested a VPN connection to a NordVPN Server, but there is no change in the ip addresses.
Logs sent to connman-debug@jolla.com: Tested w/ ProtonVPN: leaks IPv4 and IPv6 and DNS. w/ NordVPN: leaks (still, like 4.5.0.18) IPv6. In both, one can now turn on, in Advanced profile “Disable IPv6 Yes”, while before it was not possible, it did not connect. Now it connects w/ VPN but leaks IPv6.
Hotspot works as w/ earlier versions, OK but it takes loooonger time time to get on Internet (seen from the Win11 client) than if using a gulag phone as Hotspot for the same… Cannot tell if this because of CLAT (since before it did not work at all with 4.5.0.18…).
Keep up the good work! 
4 Likes
No worries, we might need to tackle that WLAN issue in another scope anyways. There seems to be something to do with the WLAN on the X10 III. Just need to find out what.
The VPN fix was not then complete yet.
And after getting these logs - much appreciated! - it was evident what was wrong. The old implementation to remove routes in ConnMan was made only for host routes and when trying to remove the default route from clat interface when the VPN mode is set it just simply returned “ok” even though nothing could be done. Well, these things are common, apparently I fixed that later on only for IPv6.
There is now 1.32+git194.2 in the build that should address the issue of dropping the clat default route in case VPN is on. The logs show that the process does detect VPN correctly and hopefully now there is an improvement to the use and functionality.
And IPv6 will be unfortunately leaked when running an IPv4 VPN over CLAT that is using the IPv6 as transport. Dropping anything related to IPv6 in that case would, in theory, cripple the network. But one step at a time.
2 Likes
Apparently this is now built and is available for testing.
With 194.2 output on browserleaks.com/ip is the same with vpn enabled or disabled.
VPN and clat interfaces are both up.
Log is on its way.
Updated to 1.32+git194.2 - regression observed - now also NordVPN leaks both IPv4 and IPv6 only DNS remains in the target location. Logs have been sent. Voting systematically on ProtoVPN forum for IPv6-enabled VPN but no more points to put in there, maybe other ProtonVPN users here: vote you too!
Right. I’m really not sure how the VPN over clat will be shown there. I have a 1.32+git194.3 in the build soon which could help with that issue. It might be good to also check that if the traffic on the actual interface is encrypted VPN traffic or regular traffic that would show all the HTTPS requests made, for instance.
I noticed that the host route was missing for the VPN. That is added in the new version and figuring out that was a quite a struggle since this might be working better if we’d move whole CLAT as integral part of ConnMan instead of plugin. But that is a completely separate work task, a big one. Having the whole implementation as a plugin requires some not-so-clean approaches.
But let us know how this version pans out. I’ll be away from this for the next few weeks, so no updates unfortunately for a while. The PR to add VPN support is there so if someone has the time, willpower and knowhow please add proposals there if something obvious was missed.
1 Like
I wonder how that can be. That version had only the default route dropped from CLAT when VPN is up. Interesting. But it was quite obvious from the logs you’ve sent (thank you) that there was something else needed, and hopefully 1.32+git194.3 has that addressed.
Checking the output with tcpdump -i clat and tcpdump -i vpn0 (or which vpn interface is used, 0…9) might give some hint where data is going. tcpdump is available in the tools repo.
Logs for 1.32+git194.3 sent 2023-03-18.
1 Like
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!
2 Likes
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.
8 Likes
@abranson and all the people testing and providing logs: Thank you very much for CLAT implementation.
5 Likes
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)
- the clat interface shows up in no case (at least, I don’t see it)
- VoLTE registers OK in all cases
- If I choose IP or Dual in the APN configuration, it gets an IP address but says “limited connectivity”, doesn’t even ping the gateway, so no joy
- If I choose IP6, it does get an IP6 address on rmnet_data0@rmnet_ipa0 and an IP4 address at rmnet_data1@rmnet_ipa0, happily says “enabled” (not “connected”), but in fact the network is unreachable, no double triangle icon shows up near the 4G indicator, but in the upper menu the mobile data icon is lit, as if the service was enabled.
- Another difference between IP and IP6 is that with IP, if I try to ping the gateway it waits forever, while with IP6 it says Network unreachable immediately.
Am I missing something? How could I help solving this? Thank you very much!
3 Likes
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.
2 Likes
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
2 Likes
Confirm. Nothing changed, im still without mobile data. Plus PL.
2 Likes