1.32+git193.31 now on OBS, which should fix problems with tethering so it should always work if CLAT is active now.
If people have tried this out, and haven’t already reported which mobile network is used, please let us know so I can compile a list of which ones are working and which aren’t yet. That’ll help manage people’s expectations, and identify networks that need further investigation.
I still got the problem that the clat interface sometimes doesn’t come up, when the phone switches from wifi to mobile data. I will send the log.
Thanks for the logs. Those are really helpful as it shows the error happening in resolving of the ipv4only.arpa while running as the resolving is used periodically to determine whether CLAT should be still on. It simply fails to resolv the address, I guess few errors in resolv should be tolerated.
It is really puzzling why the AAAA DNS request for the ipv4only.arpa sometimes starts to fail in your case after 2 successful ones or when the mobile data should be online. The reply clearly states that there is no answer for the request. The request is repeated every 10min (as the requirement of repeating it 10s before the record expires cannot be complied with yet because of ConnMan internal architectural requirements…) and it should not be treated as a DDoS of any sort. There is no clear indication in the logs about why it even happens. Is that a poor reception area you are located where network easily breaks?
But for the other issues I made changes that are in 1.32+git193.33 (address remaining hotspot issues and fix error in stopping CLAT when resolving fails). It may be available later on today/tomorrow.
Reception is good and i do not have any connectivity issues.
Nevertheless installing 193.33 right now 
193.33 is now building in the OBS repo, and I’ve also moved the tayga package to use the proper sailfish repo now that’ll be in the next release.
@miau 193.34 is built now, which has some retries for the DNS resolution that might help with your particular provider. If you have success with that then I think we might be pretty much there.
XA2 Dual, .18, SFR France here.
I have got a pretty foggy understanding of what is discussed here but I installed the packages and ProtonVpn is now perfectly working whereas it was completely buggy before.
Many thanks for that! (and for the rest, that I don’t get 
)
This said, if I can run some useful tests (XA2 SFR), I’d do with pleasure.
Hi, have you checked that, like with https://ipleak.net/ ? I tested this only eleven days ago and had to roll back because that time CLAT implementation did not take account VPN at all. Maybe it is now fixed? I wrote a note of my ProtonVPN configuration (without CLAT) which currently leaks “only” IPv6, oh dear (please upvote in Proton forum requests to have IPv6 VPN!)
Hi, these changes did not include support for VPN yet. We’ll have to do that later. There are a few loose ends to check first before doing that. The previously done IPv6 leak prevention is one of those.
Looking good so far
I don’t think the XA2, or any other device than the 10iii, does the IPv6 only thing that required this CLAT implementation. But it’s always good to check for new bugs it may have introduced in other devices.
Yes, leaks with IPv6.
I have IPv6 disabled in all VPN configurations.
Tests on https://ipleak.net/ show different IPs, so for that, it seems to work.
I installed these packages on my XA2 due to a reverse-understanding 
of the subject (https://forum.sailfishos.org/t/4-5-0-18-french-operator-sfr-webradio-no-sound/14877/).
It is interresting to notice than afterwards, I could enable VPN again (was not working well since .18).
If nothing related to VPN was changed, it might be a coincidence or some side effect…
I think while implementing this CLAT stuff, Jussi has fixed a number of issues and inconsistencies in connman that may well improve things for lots of other uses and devices. We couldn’t tell you what in particular though 
And here is where my part comes in. As soon as this update is official, I’ll provide a list of all bug reports with network errors and we’ll be able to check if it solved or not.
I reckon that - from .18 - the following, VPN-related packages were replaced (among others) for me when I installed CLAT (and then rolled back to these) :
...
connman-plugin-vpn-l2tp-1.32+git193-1.18.1.jolla.aarch64
connman-plugin-vpn-openconnect-1.32+git193-1.18.1.jolla.aarch64
connman-plugin-vpn-openvpn-1.32+git193-1.18.1.jolla.aarch64
connman-plugin-vpn-pptp-1.32+git193-1.18.1.jolla.aarch64
connman-plugin-vpn-vpnc-1.32+git193-1.18.1.jolla.aarch64
...
If the (replacing) VPN-related connman packages - I did not take record of those - helped to make your buggy VPN connection available again, I think we all will profit one day to get the CLAT integrated (with VPN-support) in SFOS, so let’s keep helping this great project with our testing!
Those haven’t really changed - they’re just built with connman so get the same version number as that.
I encountered a new problem with this version. Sometimes after getting out of Wifi range the clat interface shiws up but the wlan0 interface does not get dropped and there is no internet access at all. Disabling WLAN solves this issue. After enabling wlan everything is still working.
I collected a log if this helps.
Today I tried hotspot with the latest version and it worked.
Long-term test will take place next Friday when I have another week’s night shift