IPv4 mobile data connection not possible

Bug Reports
, ,
#92

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.

#93

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.

#94

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?

#95

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.

#96

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.

#97

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.

#98

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
#99

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?

#100

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
#101

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
#102

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
#103

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.

#104

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
#105

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
#106

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! :sweat_smile:

4 Likes
Testing CLAT for IPv6-only mobile networks
#107

ā€¦ 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.

#108

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.

#109

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.

#110

I had this problem yesterday - could not communicate with HSL public transportation ticket systemā€¦

ā€¦ It could be that the problem started a while ago, or it has always been
with SailfishOS 5.0 in X10 III (if now temporary lack of IPv6 in HSL).

anyway today I realized (some ssh -vvv host -4 executions) that while
many connections worked (due to IPv6), many did not (IPv4 only).

I tried all the things I could imagine, rebooting, preferring 5G (4G), preferring 4G (4G) and 2G only (2.5G). Setting Airplane mode on/off.
I also removed second sim (which I have to be able to use 2G, but thatā€™s another story).

I either had no IPv4 address (other than localhost), or only link-local,
(from 169.254.0.0/16) address from mobile interfaces.

But then I did this trick:

$ pkexec sh
# systemctl stop ofono
# rm -rf /var/lib/ofono/??*
# reboot

then, after enabling mobile internet (which were unconfigured after those removals) I got IPv4 back.

#111

Is this :thread: a duplicate of [4.6.0.13] Xperia 10 III: Android apps mobile data connectivity - worse then ever or vice versa?

It all seems to boil down to periodically restarting ofono.