Anyway, I just tested Vodafone IT on 4.5.0.16 and it does not work yet.
SIMon mobile is a 100% affiliate to Vodafone germany. Triggered through @ziellos and @miau i disabled and later removed the SIMon mobile card form slot 1 of my phone.
Unfortunately if have also to confirm: no IPv4 address assignment for Deutsche Telekom / t-mobile / congstar!
Switching t-mobile sim card from slot 2 to slot 1 with SIMon card removed didn’t help either.
The phone was restarted after every configuration change.
I will perform additional tests.
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.
4 Likes
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.
3 Likes
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.
1 Like
My bad, sorry. I should glance through all recent posts before writing anything.
1 Like
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.
2 Likes