They’re unique within the phone, yes, but by “device” I meant the phone itself so it could be used as a means of maintaining a connection across different interfaces and, by extension, different pieces of hardware. However, since everything is so buried in other cell phones’ SOCs, it may even be simpler than that or the fact that they’re (WiFi and cell modems) so ingrained within the SOC could be why something like a YouTube video can jump from a mobile connection to a WiFi connection uninterrupted, I’m not really sure.
But, assuming my hypotheses are correct, it would explain why “priority” doesn’t matter in the wwan vs wlan scenario you’re talking about. Priority would only apply to new connections, not ones being maintained by the cell modem. If its keeping some connection alive versus creating new ones, then my question in my earlier post would apply. If its actively making new connections, then something else is going on and then the “priority” question would need to be answered, as you say.
You make a fair point. That’s probably why toggling the wifi off and on fixes the issue. Seems like there needs to be a watchdog that runs user customizable that will enforce networking rules.
If toggling WiFi on and off fixes the issue by causing the cell modem to quit communicating, then I’d say that’s a priority issue because that would mean the system is dropping the wwan connection in favor of wlan. So it seems that priority is only being taken into account when the interface comes up, not when a network is joined.
Only for curiosity, I launched tcpdump -n -i wwan0 and found some interesting things in the logs while the L5 was connected on Wifi and IP6 is disabled on wwan0 , for eample:
Yeah, I don’t think it’s even possible to do what was requested.
However there are an awful lot of different scenarios, including whether each interface does or does not support IPv4, does or does not support IPv6, has CGNAT being imposed upon it by the provider, has NAT occurring by the choice of the customer.
Once an external host (peer) sees your public WAN IP address, the TCP connection or UDP “connection” is associated with that IP address by the peer - and won’t readily move to a different IP address.
So there are really only 2 ways of dealing with this.
Use protocols that don’t need an ongoing connection (like HTTP) - and don’t bind the client to a specific interface. Hence why it may be necessary to deal with this at the application level - since the application controls both of these things.
Have both internet connections provided by the same ISP and arrange it with your ISP. However this is a niche (and usually expensive) solution, more likely applicable to a business - and won’t even work for a mobile phone in all scenarios.
@Loki already posted the most reasonable solution. If WiFi comes up then disable the mobile data connection via some software means, and reverse that when WiFi goes down.
(There could be obscure Librem 5 customer scenarios where that might not be desirable but I think for 99% of customers that is what you would want or at least would find acceptable.)
One minor caveat though … there is a difference between interface up and interface usable (because it is up and has an IP address).
May also need to take into account the state of the HKSs.
Those are link scope IPv6 addresses though. So may be harmless in the context of this topic and the concern that IPv6 traffic may be being sent to the internet and thereby consume mobile data quota.
What was that command showing before you changed sysctl.conf ?
I only added the all.disable line in my sysctl.conf and that seemed to turn off all the IPv6 traffic according to tcpdump, but maybe I should add the default line as well.
I think the solution will require some application level watchdog that is configurable along the same lines of Android where you can enable/disable background data for apps. I don’t know how difficult this would be to achieve but I think that’s where it eventually has to go, almost like a containerized solution.
I was a little scant on details because I didn’t want to get into all the considerations for all the permutations and possible network setups/configs. In it’s most simplest form, you’d block/drop mobile data when a wifi connection comes up unless that wifi connection is a shared/hotspot connection.
NetworkManager’s dispatcher works on connections rather than interfaces, a connection is only considered “up” when it has a network configuration (IP address and where applicable gateway, DNS server(s) etc,). The benefit of working on connections rather than interfaces is that it also picks up on the situations where the wifi interface is up but the connection drops (e.g. going out of range or connection dropping due to low signal etc,)
How mobile data is dropped/blocked can depend on the networks, if the available networks are all of the same single type (i.e. all IP4 only or all IP6 only) then I find using firewall rules rather than bringing down connections/interfaces work best as it blocks data with no need to track network state (HKS, or mobile data enable/disbale software option etc,).
Andorid’s options to disable network access for background apps are for power savings and have no affect on routing.
In Android world, cellular data and wifi data are considered mutually exclusive, only one can be on/active ant any one time. It applies similar logic as described above, if cellular data is enabled then wifi is enabled, cellular data gets disabled.
So how would you differentiate which network is WiFi and which is Mobile Data if it’s just based on connections, is the network interface identified in the connection status?
Would using firewall rules be dynamic and how would you identify the traffic, can you filter by interface name once the connection is up?
The dispatcher environment holds a number of variables related to he network event, two of which are $DEVICE_IFACE and $DEVICE_IP_IFACE these can be used to determine the interface associated with the network event.
A script or scripts get automatically triggered by dispatcher, the script then inserts/removes the rules based on the connection coming up/down, once setup it is all handled dynamically. Basic rules would just block/unblock by in/out interface.
See the post following yours. I was just referring to the general concept (but, yes, I meant when it has an IP address which is much more than device exists, radio is on, etc.). The exact details are left as an exercise for the reader but @Loki provides some more details.
If you mean enable/disable on an app-by-app basis then … while that will very likely be useful in its own right … I think it is the wrong solution here.
Here it is not about stomping on background data use per se. It is just about steering the background data use to use the correct interface when both interfaces are available. As it is hard to force all apps to use the correct interface, it is easier just to block or disable the interface that you don’t want used.
If you try to control it on an app-by-app basis then you can end up playing whackamole. You disable one app from using background data and then another app rears its ugly head to push you over quota. So at the very least, you would want good monitoring tools - and it will take a while to make sure that you have controlled absolutely every application that might use the network from time to time. (For example, Lollypop unless configured not to will go online to look up album info and download cover art etc. - and probably then only when it hasn’t already downloaded that specific album’s info. You won’t notice that until you run it.)
Let’s say we have a different situation: You are outside your home. WiFi is not connected. Mobile is connected but you have a modest quota on your mobile plan. Right now your only option is “all or none” i.e. you can disable mobile data entirely. Then you might want to limit on an app-by-app basis.
However even then you may not necessarily want to limit only background data. You might want to limit an app outright never to use data unless WiFi is connected e.g. downloading package updates.
A lot of this is “nice to have”. It will come eventually to the Linux mobile ecosystem but there are bigger fish to fry right now. So right now customers have to cobble together their own procedures, workarounds and solutions.