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.
2 Likes
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.
1 Like
But why do I get an IPv4 address on the X10III with Android?
XQ-BT52:/ $ ip route
10.207.181.32/30 dev rmnet_data2 proto kernel scope link src 10.207.181.33
XQ-BT52:/ $ ifconfig
dummy0 Link encap:UNSPEC
inet6 addr: fe80::3c6e:1aff:fe66:aa5e/64 Scope: Link
UP BROADCAST RUNNING NOARP MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 TX bytes:630
lo Link encap:UNSPEC
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope: Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:133 errors:0 dropped:0 overruns:0 frame:0
TX packets:133 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:16099 TX bytes:16099
rmnet_data2 Link encap:UNSPEC
inet addr:10.207.181.33 Mask:255.255.255.252
UP RUNNING MTU:1500 Metric:1
RX packets:20041 errors:0 dropped:0 overruns:0 frame:0
TX packets:10404 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:53852296 TX bytes:1089326
rmnet_data0 Link encap:UNSPEC
inet6 addr: fe80::7a79:1686:f61e:279b/64 Scope: Link
UP RUNNING MTU:1500 Metric:1
RX packets:28 errors:0 dropped:0 overruns:0 frame:0
TX packets:24 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3479 TX bytes:1599
rmnet_ipa0 Link encap:UNSPEC
UP RUNNING MTU:9216 Metric:1
RX packets:3029 errors:0 dropped:0 overruns:0 frame:0
TX packets:3491 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:10319313 TX bytes:1282308
And why do I get an IPv4 address on the X10III with Sailfish after flashing it with Android, testing IPv4 (see above) and flashing it back to Sailfish? Only after the first reboot does IPv4 stop working.
[root@Xperia10III defaultuser]# ifconfig
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:634 errors:0 dropped:0 overruns:0 frame:0
TX packets:634 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:82851 (80.9 KiB) TX bytes:82851 (80.9 KiB)
rmnet_data0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet6 addr: fe80::2b37:34ac:a642:f159/64 Scope:Link
UP RUNNING MTU:1500 Metric:1
RX packets:9 errors:0 dropped:0 overruns:0 frame:0
TX packets:13 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:488 (488.0 b) TX bytes:760 (760.0 b)
rmnet_data2 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.207.68.45 Mask:255.255.255.252
inet6 addr: 2a01:598:d802:2c0b:bafb:57ad:b488:3aa2/64 Scope:Global
inet6 addr: 2a01:598:d802:2c0b:a641:317b:9f32:8c3/64 Scope:Global
inet6 addr: fe80::bafb:57ad:b488:3aa2/64 Scope:Link
UP RUNNING MTU:1500 Metric:1
RX packets:43 errors:0 dropped:0 overruns:0 frame:0
TX packets:67 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:6116 (5.9 KiB) TX bytes:4942 (4.8 KiB)
rmnet_ipa0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
UP RUNNING MTU:9216 Metric:1
RX packets:52 errors:0 dropped:0 overruns:0 frame:0
TX packets:69 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:6351 (6.2 KiB) TX bytes:7674 (7.4 KiB)
rndis0 Link encap:Ethernet HWaddr 6A:0B:5E:94:CB:F8
inet addr:192.168.10.1 Bcast:192.168.10.255 Mask:255.255.255.0
inet6 addr: fe80::680b:5eff:fe94:cbf8/64 Scope:Link
UP BROADCAST RUNNING MULTICAST DYNAMIC MTU:1500 Metric:1
RX packets:211 errors:0 dropped:0 overruns:0 frame:0
TX packets:118 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:23516 (22.9 KiB) TX bytes:35542 (34.7 KiB)
1 Like
Im waiting for answer 9 months, from May, my X10 III more then one year, since i bought more then one year ago. Phone without mobile data is useless phone, cannot consider as daily. Does Jolla is really going to take this as serious problem?
3 Likes
Based on quick tests, my X10 III (4.5.0.18) gets dualstack address (IPv4/IPv6) no matter what is the protocol selection under APN (IP, IPv6 or dual) - Elisa network in Finland.
And to be exact, the flight mode was used (on/off) after protocol selection changed.
Different hardware adaptation, different vendor blobs, any number of variables. I’ve also had points where I’ve been given a 10.x address for a while on my X10iii on SailfishOS. The point I’m trying to make is that, given the existence of NAT64 and CLAT, IPv6-only is a viable, scalable and deliberate mode for providers to support, so SailfishOS needs to be able to function properly in that situation. Then it doesn’t matter which mode you end up getting put in.
1 Like
Thank you for your comment and I understand your point that an IPv6-only connection +CLAT should work for all use cases by now.
But unfortunately, some use cases with IPv6-only +CLAT are still problematic and require appropriate workarounds.
On the one hand, it’s clearly a bug in these applications that they don’t work properly with IPv6-only.
On the other hand, some MNOs also support IPv4 as a fallback solution for this very reason. And if, for unknown reasons, SFOS cannot establish a mobile IPv4 connection to one of these providers, while it works on other operating systems (e.g. Android), it is a bug in SFOS from my point of view.
Unfortunately, as I understand from your explanations, there are no plans to address this issue.
1 Like
I just updated to 4.5.0.19 on my 10 iii and internet connection sharing over t-mobile Germany (and surely congstar as well) now works!
So does the app Stadtrad Hamburg, which previously didn’t, but was updated in the meantime.
So for me the status now is that with the newest release introducing CLAT my mobile data connection problems seem to be solved! 
4 Likes
… for my setup with two SIM cards (Vodafone Germay / SIMon mobile in slot 1, t-mobile Germany in slot 2), both enabled, mobile data over slot 1 with firefox i have a much better surfing experience or some websites just load (fast and complete) at all, if i set slot 1 (Vodafone Germany) connection type to protocol IP only!
e.g. www.spiegel.de
This is reproducible on my setup by switching connection protocol for slot 1 from IP only to IPV6 or dual and rebooting.
Maybe a sticky thread with optimal connection settings per country, provider and Sailfish OS version is a good idea!?
Edit: e-mail seems also to be affected.
My hostpot didn’t work even in SIM slot 2, so started to dig into the topic.
And I have just made it working by changing DHCP to manually set IP. Used the same network settings (172.28.172.2/24, 172.28.172.1 as gateway) + manually set DNS to 1.1.1.1 and 9.9.9.9, as I saw they are IPv6 not IPv4.
I have Xperia 10III, in ORANGE.pl SIM in the first slot.
Hope it helps somebody.
I don’t think this could help the issue reported here, since it concerns the total lack of data services, not just hotspot, and this happens when only IPv6 is available.