I did. 
Works with ip v4 for SF and Android apps.
Does not resolve names with ip v6 for both Android and SF apps. But is connected, can e.g. reload pagea in stock browser or Fennec.
Works with dual protocol enabled.
It seems to be an ip v6 DNS problem, doesnāt it?
On my network (Orange F) this seems to be an actual feature of the modem of the X10iii when my SIM is in slot 1. The assumption is that the OS supports IPv4 to 6 bridging on the device, a mechanism known as CLAT. Weāve been experimenting with this, and hereās a test implementation of CLAT in connman. Weād appreciate further testing from people who donāt mind getting their hands dirty.
In 4.5.0, a timeout in connman was increased slightly for networks that are slow to supply an IPv4, but really thatās still a fallback for IPv6-only mode, so that shouldnāt be needed when CLAT works.
As i already wrote in the CLAT thread everything seems to be working now using CLAT.
Since i am using Deutsche Telekom as my network operator i edited my mobile settings to use internet.v6.telekom and only ipv6 as protocol to speed up the connection when enabling mobile data.
here is the result:
Hotspot also worked after a reboot.
CRITICAL WORKAROUND FOLLOWS - EDIT: NOT TRUE (see below)
Enabling CLAT and switching the access point to IP protocol (rather than Dual) enables connectivity on Vodafone IT, and I assume on all non-working networks.
Jolla crew, please consider this in order to find the issue.
UPDATE: Connection does not work any more. Rebooting does not take it back. False alarm, the issue is still there.
Hmm, āsameā. Some of the previous posts said āit worksā and some āit doesnātā.
Please say it clearly. Ok?
I still only got an IPv6 address after updating to 4.5. But the problem seems to be solved, take a look at my post above.
My bad, sorry. I should glance through all recent posts before writing anything.
Have you tried setting the protocol to IPV6 only? If i understand correctly IP only can not work while using CLAT.
Yes, of course I did. No luck anyway. Maybe it worked for some strange combination.
Did the CLAT interface show up in ifconfig if mobile data is enabled and wifi disabled?
For me yes and only then.
When I enable (and connect) WiFi, the CLAT interface is gone.
Also when I enable (and connect) VPN, the CLAT interface is gone too.
From my point of view, the correct behavior, since the IPv4 address is then provided via WLAN or via VPN.
Interesting. Mainly because there is, and has been, a workaround for operators that seemed to, in some very rare cases, send the IPv4 address via DHCP a bit late when DUAL mode is selected for the mobile data. We just increased the time to wait for IPv4 address to arrive from 2s to 5s in 4.5.0 as an attempt to help in these kind of situations. Maybe that isnāt the case with these operators.
So yes, you are correct, if the operator fails to provide IPv4 or the device for some reason does not acquire one setting the mode for mobile data to IPv6 only will eliminate such wait. It was actually a Finnish operator Elisa that had this kind of issue of late IPv4 delivery. Because of architectural restrictions the wait was the most feasible way of addressing the issue. But it could be improved to eliminate the wait completely - since the wait, as you noticed, will not set the mobile data connection as connected until the wait has completed OR an IPv4 address was received.
Iāll just clarify a few things for many with this one post.
CLAT does not have any effect if you are setting the mobile data mode to IP (actually, this should be named as IPv4 butā¦). CLAT is meant to be a translator between IPv4 requiring applications and IPv6 only network and other resources beyond that.
Well it is the other way around. CLAT is not being enabled if the connection has an IPv4 address.
Yes, this is correct. We were considering to add CLAT support for IPv6 WLAN networks as well but it will be a task for the future - this would need the support from the operator, too. CLAT does not work on its own, it has to be able to get an AAAA (IPv6) record for ipv4only.arpa in order to be enabled.
Most of the VPNs provided by ConnMan plugins are IPv4 only so there is no CLAT enabled. Like with WLAN it might be possible to have CLAT also for IPv6 VPNs as the VPNs ConnMan plugins support do not have dual IP support so they work either on IPv4 or IPv6. But in this case the VPN provider should also support CLAT for it to work.
What is the effect, inside SFOS, of setting an access point to IPv4 mode when only an IPv6 address is provided by the mobile network?
Without the possibility to test this Iād say it would quite immediately fail. The IPv4 mode does not have any wait mechanisms in use. However, the result may be undefined still.
Well, this explains why I am not seeing the transfer arrows when doing so. This means that I was just seeing cached pages in web browsers.
As i already wrote in the CLAT Thread:
Please donāt get me wrong, CLAT seems to be a very good alternative to ārealā IPv4, the implementation of CLAT in Sailfish is very important and needs to be done.
But CLAT cannot repair an incorrect connection establishment (IPv6 only although the MNO provides ipv4) or an incorrect switching process between ipv6 only mobile data and IPv4 only WLAN.
But CLAT cannot repair an incorrect connection establishment (IPv6 only although the MNO provides ipv4)
On these operators, IPv4 is more of a legacy mode for devices that do not support IPv6 at all. The expected configuration is IPv6+CLAT.
So, if on the same provider:
XA2 receives an IPv4 address and data work
X10III only receives an IPv6 address and data do not work
where could the issue be?
It looks like the X10iii is recognized by the network as a device that should support IPv6-only connections, so thatās what itās given. These connections support DNS64 and NAT64 for resolving IPv4 host to mapped IPv6 addresses, so itās expected to support CLAT for literal IPv4 support.
