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

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
3 Likes

Related? Using mobile data although wifi connected

@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?

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

3 Likes

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.

@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.

@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.:wink:

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.