IPv4 mobile data connection not possible

senders · 21 August 2022 11:22

Unfortunately, I have no idea how exactly the mobile data connection is established.

DISCLAMER: Everything that follows now is dangerous half-knowledge. Please correct me if you know better!

As far as I know, initially there are only the APN settings, the default values of most providers stored in “/usr/share/mobile-broadband-provider-info/serviceproviders.xml”.
The provider is contacted with this connection data and everything else, e.g. IP address, gateway, DNS server etc. is then handed over by the provider.
In the ofono log on the Xperia X I could see the corresponding entries almost in plain text.

2022-06-11 09:34:11.482 RIL1> DATA_CALL_LIST_CHANGED
2022-06-11 09:34:11.482 RIL1> 0000: 01 00 00 00 f2 03 00 00  0b 00 00 00 01 00 00 00    ........ ........
2022-06-11 09:34:11.482 RIL1  0008: 00 00 00 00 ff ff ff ff  00 00 00 00 02 00 00 00    ........ ........
2022-06-11 09:34:11.482 RIL1  0018: 06 00 00 00 49 00 50 00  56 00 34 00 56 00 36 00    ....I.P. V.4.V.6.
2022-06-11 09:34:11.483 RIL1  0028: 00 00 00 00 0b 00 00 00  72 00 6d 00 6e 00 65 00    ........ r.m.n.e.
2022-06-11 09:34:11.483 RIL1  0038: 74 00 5f 00 64 00 61 00  74 00 61 00 30 00 00 00    t._.d.a. t.a.0...
2022-06-11 09:34:11.483 RIL1  0048: 3a 00 00 00 31 00 30 00  2e 00 31 00 39 00 38 00    :...1.0. ..1.9.8.
2022-06-11 09:34:11.483 RIL1  0058: 2e 00 33 00 39 00 2e 00  31 00 36 00 2f 00 32 00    ..3.9... 1.6./.2.
2022-06-11 09:34:11.483 RIL1  0068: 37 00 20 00 32 00 61 00  30 00 31 00 3a 00 30 00    7. .2.a. 0.1.:.0.
2022-06-11 09:34:11.483 RIL1  0078: 35 00 39 00 38 00 3a 00  39 00 30 00 38 00 31 00    5.9.8.:. 9.0.8.1.
2022-06-11 09:34:11.483 RIL1  0088: 3a 00 64 00 64 00 30 00  62 00 3a 00 39 00 63 00    :.d.d.0. b.:.9.c.
2022-06-11 09:34:11.483 RIL1  0098: 65 00 63 00 3a 00 62 00  65 00 65 00 34 00 3a 00    e.c.:.b. e.e.4.:.
2022-06-11 09:34:11.483 RIL1  00a8: 35 00 37 00 33 00 35 00  3a 00 62 00 30 00 62 00    5.7.3.5. :.b.0.b.
2022-06-11 09:34:11.483 RIL1  00b8: 33 00 2f 00 36 00 34 00  00 00 00 00 6b 00 00 00    3./.6.4. ....k...
2022-06-11 09:34:11.483 RIL1  00c8: 31 00 30 00 2e 00 37 00  34 00 2e 00 32 00 31 00    1.0...7. 4...2.1.
2022-06-11 09:34:11.483 RIL1  00d8: 30 00 2e 00 32 00 31 00  30 00 20 00 31 00 30 00    0...2.1. 0. .1.0.
2022-06-11 09:34:11.483 RIL1  00e8: 2e 00 37 00 34 00 2e 00  32 00 31 00 30 00 2e 00    ..7.4... 2.1.0...
2022-06-11 09:34:11.483 RIL1  00f8: 32 00 31 00 31 00 20 00  32 00 61 00 30 00 31 00    2.1.1. . 2.a.0.1.
2022-06-11 09:34:11.483 RIL1  0108: 3a 00 30 00 35 00 39 00  38 00 3a 00 30 00 37 00    :.0.5.9. 8.:.0.7.
2022-06-11 09:34:11.483 RIL1  0118: 66 00 66 00 3a 00 30 00  30 00 30 00 30 00 3a 00    f.f.:.0. 0.0.0.:.
2022-06-11 09:34:11.483 RIL1  0128: 30 00 30 00 31 00 30 00  3a 00 30 00 30 00 37 00    0.0.1.0. :.0.0.7.
2022-06-11 09:34:11.483 RIL1  0138: 34 00 3a 00 30 00 32 00  31 00 30 00 3a 00 30 00    4.:.0.2. 1.0.:.0.
2022-06-11 09:34:11.483 RIL1  0148: 32 00 31 00 30 00 20 00  32 00 61 00 30 00 31 00    2.1.0. . 2.a.0.1.
2022-06-11 09:34:11.483 RIL1  0158: 3a 00 30 00 35 00 39 00  38 00 3a 00 30 00 37 00    :.0.5.9. 8.:.0.7.
2022-06-11 09:34:11.483 RIL1  0168: 66 00 66 00 3a 00 30 00  30 00 30 00 30 00 3a 00    f.f.:.0. 0.0.0.:.
2022-06-11 09:34:11.483 RIL1  0178: 30 00 30 00 31 00 30 00  3a 00 30 00 30 00 37 00    0.0.1.0. :.0.0.7.
2022-06-11 09:34:11.483 RIL1  0188: 34 00 3a 00 30 00 32 00  31 00 30 00 3a 00 30 00    4.:.0.2. 1.0.:.0.
2022-06-11 09:34:11.483 RIL1  0198: 32 00 31 00 31 00 00 00  34 00 00 00 31 00 30 00    2.1.1... 4...1.0.
2022-06-11 09:34:11.483 RIL1  01a8: 2e 00 31 00 39 00 38 00  2e 00 33 00 39 00 2e 00    ..1.9.8. ..3.9...
2022-06-11 09:34:11.483 RIL1  01b8: 31 00 37 00 20 00 66 00  65 00 38 00 30 00 3a 00    1.7. .f. e.8.0.:.
2022-06-11 09:34:11.483 RIL1  01c8: 30 00 30 00 30 00 30 00  3a 00 30 00 30 00 30 00    0.0.0.0. :.0.0.0.
2022-06-11 09:34:11.483 RIL1  01d8: 30 00 3a 00 30 00 30 00  30 00 30 00 3a 00 31 00    0.:.0.0. 0.0.:.1.
2022-06-11 09:34:11.483 RIL1  01e8: 30 00 34 00 62 00 3a 00  37 00 62 00 34 00 35 00    0.4.b.:. 7.b.4.5.
2022-06-11 09:34:11.483 RIL1  01f8: 3a 00 38 00 61 00 64 00  38 00 3a 00 65 00 32 00    :.8.a.d. 8.:.e.2.
2022-06-11 09:34:11.483 RIL1  0208: 38 00 36 00 00 00 00 00  00 00 00 00 00 00 00 00    8.6..... ........
2022-06-11 09:34:11.483 RIL1  0218: dc 05 00 00                                         ....
2022-06-11 09:34:11.484 src/ril_data.c: ril_data_call_list_parse() version=11,num=1
2022-06-11 09:34:11.484 src/ril_data.c: ril_data_call_parse() [status=0,retry=-1,cid=0,active=2,type=IPV4V6,ifname=rmnet_data0,mtu=1500,address=10.198.39.16/27,dns=10.74.210.210 10.74.210.211,gateways=10.198.39.17,pcscf=(null) ]

Unfortunately, this data is no longer displayed in the ofono log of the Xperia 10III.

2022-06-08 08:08:50.982 slot1 > 10 dataCallListChanged
2022-06-08 08:08:50.982   0000: 61 6e 64 72 6f 69 64 2e  68 61 72 64 77 61 72 65    android. hardware
2022-06-08 08:08:50.982   0010: 2e 72 61 64 69 6f 40 31  2e 30 3a 3a 49 52 61 64    .radio@1 .0::IRad
2022-06-08 08:08:50.982   0020: 69 6f 49 6e 64 69 63 61  74 69 6f 6e 00 00 00 00    ioIndica tion....
2022-06-08 08:08:50.982   0030: 01 00 00 00 85 2a 74 70  00 00 00 00 b8 e1 da 6e    .....*tp .......n
2022-06-08 08:08:50.982   0040: 71 00 00 00 10 00 00 00  00 00 00 00 00 00 00 00    q....... ........
2022-06-08 08:08:50.982   0050: 00 00 00 00 00 00 00 00  00 00 00 00 85 2a 74 70    ........ .....*tp
2022-06-08 08:08:50.982   0060: 01 00 00 00 c8 e1 da 6e  71 00 00 00 78 00 00 00    .......n q...x...
2022-06-08 08:08:50.982   0070: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ........ ........
2022-06-08 08:08:50.982   0080: 00 00 00 00 85 2a 74 70  01 00 00 00 40 e2 da 6e    .....*tp ....@..n
2022-06-08 08:08:50.982   0090: 71 00 00 00 07 00 00 00  00 00 00 00 01 00 00 00    q....... ........
2022-06-08 08:08:50.983   00A0: 00 00 00 00 10 00 00 00  00 00 00 00 85 2a 74 70    ........ .....*tp
2022-06-08 08:08:50.983   00B0: 01 00 00 00 48 e2 da 6e  71 00 00 00 0c 00 00 00    ....H..n q.......
2022-06-08 08:08:50.983   00C0: 00 00 00 00 01 00 00 00  00 00 00 00 20 00 00 00    ........ .... ...
2022-06-08 08:08:50.983   00D0: 00 00 00 00 85 2a 74 70  01 00 00 00 58 e2 da 6e    .....*tp ....X..n
2022-06-08 08:08:50.983   00E0: 71 00 00 00 2b 00 00 00  00 00 00 00 01 00 00 00    q...+... ........
2022-06-08 08:08:50.983   00F0: 00 00 00 00 30 00 00 00  00 00 00 00 85 2a 74 70    ....0... .....*tp
2022-06-08 08:08:50.983   0100: 01 00 00 00 88 e2 da 6e  71 00 00 00 50 00 00 00    .......n q...P...
2022-06-08 08:08:50.983   0110: 00 00 00 00 01 00 00 00  00 00 00 00 40 00 00 00    ........ ....@...
2022-06-08 08:08:50.983   0120: 00 00 00 00 85 2a 74 70  01 00 00 00 d8 e2 da 6e    .....*tp .......n
2022-06-08 08:08:50.983   0130: 71 00 00 00 28 00 00 00  00 00 00 00 01 00 00 00    q...(... ........
2022-06-08 08:08:50.983   0140: 00 00 00 00 50 00 00 00  00 00 00 00 85 2a 74 70    ....P... .....*tp
2022-06-08 08:08:50.983   0150: 01 00 00 00 00 e3 da 6e  71 00 00 00 01 00 00 00    .......n q.......
2022-06-08 08:08:50.983   0160: 00 00 00 00 01 00 00 00  00 00 00 00 60 00 00 00    ........ ....`...
2022-06-08 08:08:50.983   0170: 00 00 00 00                                         ....
2022-06-08 08:08:50.983 src/binder_data.c: binder_data_call_list_1_0() num=1
2022-06-08 08:08:50.983 src/binder_data.c: binder_data_call_new_1_0() [status=0,retry=-1,cid=0,active=2,type=IPV4V6,ifname=rmnet_data3,mtu=1500,address=2a01:0598:a83d:02d5:e029:eddf:8fae:5e42/64,dns=2a01:0598:07ff:0000:0010:0074:0210:0221 2a01:0598:07ff:0000:0010:0074:0210:0222,gateways=fe80:0000:0000:0000:c8a1:04e3:7a52:c7dd,pcscf=]

From this, connman creates a corresponding entry for the context of the mobile network.
These context settings are saved under: /home/.system/var/lib/connman/cellular_[context_number]_context1/ in file “settings”:

[cellular_[censored]_context1]
Name=congstar
Favorite=true
AutoConnect=true
Modified=2022-08-21T12:05:06.977286+02
IPv4.method=off
IPv6.method=fixed
IPv6.privacy=disabled
IPv6.DHCP.DUID=[censored]
IPv6.netmask_prefixlen=64
IPv6.local_address=2a01:0598:d82b:e232:6871:e9df:0734:a43e
IPv6.gateway=fe80:0000:0000:0000:d185:8033:1ce4:f57f

What is immediately noticeable here is that the IPv4 configuration method is set to “off”.
In my opinion, “fixed” would actually be the right entry here.

See connman - Sailfish OS

…
For example the “Method” field has valid settings of “off”, “fixed”, “manual”
and “dhcp”. The “fixed” value however can not be set by any user program. It
is an internal value that some 3G cards require. Switching to “off” will
remove any IP configuration from the interface.
…

Unfortunately, I don’t know how to make the intermediate steps visible.
Perhaps the data is being transmitted incorrectly by the provider?
Perhaps the data transmitted by the provider are misinterpreted by ofono?
Perhaps the data is misinterpreted when passed from ofono to connman?

JoOppen · 21 August 2022 11:57

Just another observation:
It appears that a mobile connection via Congstar SIM is established faster since I shortly used the SIM in an Android phone. This may just pure incidence. However, I wonder whether anything is stored on the SIM

akikyo · 21 August 2022 12:11

Like someone already said, would be miracle. This bug should be really prio for Jolla! Basically phone without mobile data is useless.

From my point of view (as programmer) i would investigate why on fresh install mobile data works till X time reboot (it depends, but most of the time 1 is enough to break it). So for me it works 100% on fresh. Maybe its worth to check what is going on fresh install in system? Check code and dependencies etc. as semi solution till Jolla fix it… It hurts that my phone catches dust. I have no knowledge nor time to dive into mobile stuff.

Ah, after reboot (breaking mobile data) i tried to reflash only sailfish os with wiping data in recovry and android binaries, so omitted step flashing android from emma, didnt help. Maybe its worth to note also that full fresh install works.

canne · 21 August 2022 17:28

Well, that file is so old that - for my operator - it contained the settings and names which were valid before I got my Jolla 1 back in the day!

Somehow, that was a good starting point, though, I took my Android device with the same SIM and copied from its excellent APN parameter configurator the current, android-working values into the System → Cellular Network → Data access point in SFOS. (There are not as many settings in SFOS as in Android, though but in Android it is mixing the Internet and MMS settings in one APN dialog.)

The resulting configuration is written in /var/lib/ofono/123456789012345/ where 123456789012345 is as defined by DefaultDataSim parameter in file /var/lib/ofono/ril and where 123456789012345 is a profile name (aka. subscriber identity) attributed to the SIM card’s IMSI-number in file /var/lib/ofono/iccidmap.

The actual APN parameters used in the connections are therefore in /var/lib/ofono/123456789012345/gprs. One may want to check that they correspond to the known, working parameters in an Android phone for the same SIM card.

It is noteworthy that the parameter Protocol= is not using the same string values as used on an Android phone nor as defined on the provider’s configuration help pages (IPv4, IPv4/IPv6, IPv6). It is ofono’s own set of ip, ipv6, dual.

Alas, of these settings, in my case, only ipv6 and dual gives a data connection, but with only ipv6protocol enabled in both cases. In my case (I want a VPN without leaking) I must have IPv4 only. If I set the Protocol to ip, no data connection at all occurs.

I reckon that since this is a bug (it works OK on a Xperia 10) it is for Jolla to fix.

canne · 27 August 2022 22:38

In a sense, the below findings are matching the subject: it is possible to get IPv4 mobile data on Sony Xperia 10 III / 4.4.0.68 - with IPv6 !

I managed to get my VPN supplier and my ISP to love each other, despite the cryptic SailfishOS behavior described in the posts before this one (weekends wasted on this brain damage… ):

I noticed on my ISP’s web site that they have detected me having now a new Sony Xperia 10 III (they wanted to sell me a IV!), probably when I launched the Android tests on it. I concluded that since the Sony code is used from /vendor/firmware_mnt/image/modem_pr/mcfg/configs/mcfg_sw/generic my ISP does not really care if I am running SailfishOS on Sony AOSP or Android on the same device. They probably continue to provide the same service which worked on Android.

I found a tech talk from the ISP about their implementation of IPv6-only with CLAT+NAT64+DNS-DualStack. In this case the IPv6 will go unaltered to APN from the phone. IPv4 would need to go through a CLAT stack which is, basically a stateless NAT64 w/ IPv4 DNSproxy). This would be provided by the Sony AOSP (I am not sure, but if it is done by ofono, fine). IPv6-only will contain the IPv4, incorporated. (This article presents it simply.) Theoretically, this should be transparent to applications. Theoretically.

Let’s try it. Instead of using the default dual (in the gprs configuration file, see above) or Dual in the System → Cellular Network → Data access point, one would use ipv6 or select IPv6, respectively.

Now, the VPN’s configuration file. It contains the IP-address of the server (that is IPv4). That will not resolve. One can find easily the FQN name of the server (in my case, it is also in the file), which resolves fine on the phone now. I put the FQN name in the .udp.ovpn file instead of the IP-address to define the server and I import that on the SFOS. In the Advanced button of the SFOS VPN configuration, I set Disable IPv6 to No (actually, I think it does not even work, but just in case). The connection is made and test on the VPN supplier’s web-site reveals that I am connected to their servers with an IPv4 address.

A few more tests: http://ipleak.net It shows the same IPv4 address, of course, and additionally an IPv6 address, with no forwarded IP. Browser default is IPv6 (213ms) and fallback IPv4 (300ms), it says. However, it detects SailfishOS’s default browser’s leaking WebRTC which is the previously mentioned IPv6 address. So, there is an IPv6 address leak (which I wanted to avoid) by WebRTC.

Let’s try with an Android browser (Vivaldi) where one has more controls. I have turned WebRTC off. Same result as above. However, now there is a DNS leak! (It can find my ISP’s DNS servers, not those of the VPN provider’s.)

One cannot have it all, looks like. Better stick to the SFOS browser despite its uncontrollable WebRTC leak. Not too bad.

One final test (w/ VPN on), http://ds.test-ipv6.com : I get 9/10 for IPv4/IPv6 compatibility

Conclusion: I get, with my operator, IPv4/IPv6 traffic both working, even with a UDP VPN IPv4 server when I select the IPv6 protocol in ASN parameters of SFOS. My operator provides IPv6-only with CLAT+NAT64+DNS-DualStack. This is supported either by Sony AOSP or by ofono, or perhaps both.

It would be nice to get the IPv4-only working by Jolla, I do not see any added value in the complex IPv6 implementation. Otherwise, the IP-only should be disabled from the available protocol selection if that is strictly not possible to implement with certain operators. The non-availability in this case should be clearly indicated.

miau · 8 September 2022 23:33

@flypig

Is this problem on Jollas bug tracker?

flypig · 9 September 2022 08:35

The simplest way to find out is to check the tags attached to the topic. If it’s labelled with the “tracked” tag, then it’s already registered in Jolla’s database.

miau · 9 September 2022 09:33

Thank you, i should have viewed this thread with a browser.

codeandcreate · 1 October 2022 16:31

i have just installed Vanha Rauma 4.4.0.72 on my 10III:

German D1 network (Congstar) now works fine on SFOS for me
Hotspot still doesn’t work

miau · 1 October 2022 21:18

Updated to .72 and i still only get an IPv6 address. Norma Connect - D1.

codeandcreate · 1 October 2022 21:30

yeah, i still only get a IPv6 too, but mobile data works for me; with the .68 it haven’t.

0nn0 · 14 November 2022 22:15

I might be suffering the same problem. I too can’t get an IPv4 connection when the phone is set to dual and this started happening sometime this spring after I did an update. (I guess 4.4.0.64?)
It also happens on my XA2, BTW.

kaulian · 25 November 2022 18:48

My experience

In slot 1 : SimCard Orange France / No IPV4
in slot 2 : Same sim Card / IPv4 connexion OK (and so hotspot too)

smartiz · 25 November 2022 22:00

Same experience for me with the same provider.

PeegeeTips · 26 November 2022 12:14

really hoping we get 4.5 soon with a load of fixes for these mobile data problems, as talkmobile is telling me that they’re switiching off 3G in the new year and that makes my XA2 a tablet, not a phone.

i’ve done my bit; bought the 10iii and a SFOS licence…

cartron · 27 November 2022 13:34

oh, so are you saying that just swapping the SIM card and putting it in slot 2 would solve the issue?

miau · 27 November 2022 13:51

For some people this worked, so i would give it a try.

cartron · 27 November 2022 16:13

Yes! Just tried it and i can confirm it works! Thanks.

jollausar · 29 November 2022 09:56

They must be kidding… swapped sims: sim 1 lidl connect (DE), sim 2 ja mobil (congstar/t-mobile DE) now sim2 hotspot is working IPv4 is going to the clients in the WLAN.

(10-III, 4.4.0.72)

Thanks!

(Now i “just” have to swap sims if I want to use the data connection from the other one… )

Edit: Downside: VOLTE / 4G calling(beta) is not working anymore… - “not registered” and blinking all the time in the mobile network menu

codeandcreate · 29 November 2022 10:55

lol, nice find!
but not a solution. i hope this helps jolla to fix the bug!