Use of mobile data (IPv6) although a WLAN connection (IPv4) is active

[senders]

REPRODUCIBILITY: 100%
OS VERSION: 4.4.0.64
HARDWARE: Xperia X, Xperia 10 III
UI LANGUAGE: German
REGRESSION: (compared to previous public release: Yes, No, ?): ?

DESCRIPTION:

If you have a mobile data connection with IPv6-only, the mobile data connection remains if a IPv4-only WLAN connection with internet access is established.
The IPv6 default gateway and the name server entry are also retained.
This means that the mobile data connection is still used when an IPv6 address is resolved.

PRECONDITIONS:

IPv6-only mobile data connection. APN settings → Protocol: IPv6
(or: APN settings → Protocol: DUAL and IPv4 won’t work - see IPv4 mobile data connection not possible)
IPv4-only WiFi network with internet access

STEPS TO REPRODUCE:

Turn off mobile data.
Turn off WLAN.
Turn on mobile data.
Check mobile data icon in top menu → M(V)NO name appears.
Check IPv6 routing table (ip -6 route) → The M(V)NO’s IPv6 default route for mobile data has been entered.
Turn on WLAN and connect to your IPv4-only WiFi network.
Check mobile data icon again-> M(V)NO name remains.
Check IPv6 routing table again (ip -6 route) → The M(V)NO IPv6 default route for mobile data still exists.
Check the remaining IPv6 connectivity via mobile data with the following URL in sailfish browser: https://test-ipv6.com/

EXPECTED RESULT:

After a WLAN connection with internet access has been established (no matter what protocol), the mobile data connection is no longer used and is deactivated.

ACTUAL RESULT:

After an IPv4-only WLAN connection with internet access has been established, the IPv6-only mobile data connection remains active and will continue to be used (instead of WiFi network).

ADDITIONAL INFORMATION:

(Please ALWAYS attach relevant data such as logs, screenshots, etc…)

Xperia X:

[root@Sailfish nemo]# ip -4 route | grep default & ip -6 route | grep default
default via fe80::91ec:d3f6:7396:8614 dev rmnet_data0 proto ra metric 1024 expires 65485sec hoplimit 255
default via 192.168.2.1 dev wlan0

Xperia 10 III:

[root@Xperia10III defaultuser]# ip -4 route | grep default & ip -6 route | grep default
default via 192.168.2.1 dev wlan0
default via fe80::c461:39d9:bdd5:3d6f dev rmnet_data1 proto ra metric 1024 expires 61367sec

[thigg]

Related? Using mobile data although wifi connected

[senders]

@thigg
I had seen your Bugreport, but I thought your problem occurs only with the android app newpipe.
My issue is system wide, but nevertheless it may be the same underlying problem.
Were you able to reproduce the issue by following the steps I describe?

[nekron]

A detailed analysis covering this issue can be found here: Android Connectivity Issues Analysis

[senders]

Some sort of workaround seems to be implemented in SFOS 4.4.0.68.

The mobile data connection is still active, but at least the default route is deleted, so that a connection via IPv6 mobile data is no longer possible.

[defaultuser@Xperia10III ~]$ version
Sailfish OS 4.4.0.68 (Vanha Rauma)

[defaultuser@Xperia10III ~]$ ip -6 route
::1 dev lo  proto kernel  metric 256 
2a01:598:7ff:0:10:74:210:210 via fe80::ccc6:701e:25e1:63fd dev rmnet_data1  metric 1 onlink 
2a01:598:7ff:0:10:74:210:211 via fe80::ccc6:701e:25e1:63fd dev rmnet_data1  metric 1 onlink 
2a01:598:a90d:af7e::/64 dev rmnet_data1  proto kernel  metric 256 
fe80::ccc6:701e:25e1:63fd dev rmnet_data1  metric 1 onlink 
fe80::/64 dev rmnet_data0  proto kernel  metric 256 
fe80::/64 dev rmnet_data1  proto kernel  metric 256 
fe80::/64 dev wlan0  proto kernel  metric 256 
fe80::/64 dev rndis0  proto kernel  metric 256 

[defaultuser@Xperia10III ~]$ curl -6 ifconfig.net/
curl: (7) Couldn't connect to server

Not particularly elegant, but I’ll take that as a solution.

[flypig]

@senders: since you’ve marked a solution I’ve tagged this bug as fixed to avoid it getting added to the Bug Coordination Team’s list. Even as you say it may not be the most elegant solution, my understanding is that this essentially resolves it for you, so I hope that makes sense.

[senders]

@flypig
The bug I described no longer exists, so closing the bug report is appropriate in my view.
Whether the issue was resolved well or not is another story, maybe for another bug report.

But maybe you could please take a look at my other bug report 11917 and remove the “fixed” tag there.
I was probably a little too quick with my supposed solution and now I can no longer edit the initial post.

[jlaakkonen]

This is actually a side effect in positive manner from the rather odd case that when VoLTE is in use we for unknown reason will get default route set also for the VoLTE IPv6 interface. So two IPv6 default routes when mobile data is in use. And it is a clear race depending on which just simply is setup first. I know the approach is not elegant but the networking component we use, ConnMan, relies heavily on kernel to do the IPv6 correctly. And in this case we had to become a bit creative.

There may be something to be done for the mobile data getting disconnected when WLAN is enabled and connected but previous attempts did not work well regarding all the possible cases there are. There is an option in connman.conf, SingleConnectedTechnology that would do this but as the comment states, apps will notice more network breakups with that. And VPNs may not work properly - this part of code should be fixed at some point.

However, one of the reasons why you see traffic on a IPv4 WLAN going also over IPv6 capable mobile data is DNS. If you query an address with DNS over the IPv4 using WLAN’s defined DNS servers they may return also AAAA records. And when you have AAAA record and IPv6 connected Linux kernel by default prefers IPv6. I have a WIP PR to address also this but there is more work required on that.

However, the removal of the default route does not seem to break anything so it is the safest albeit not the most elegant approach as of now.

EDIT: and when one has the IPv6 active there is still occasional router advertisement etc. IPv6 connection maintaining communication ongoing.