* Aleksander Morgado > MBIM allows to request IPv4v6 or separate IPv4 and IPv6; currently we > try one or the other, because the ModemManager API allows asking for > both cases. The fact that in QMI we default to separate IPv4 and IPv6 > is because we can do so using different WDS clients on the same > control port, but maybe we shouldn't, and instead just expose we > support separate IPv4 and IPv6?
I'm not familiar with QMI, so I might be out of my depth here, but are you saying that for those modems MM will *always* split an IPV4V6 connection request into two (IP+IPV6) bearers? If so I think that's not the ideal thing to do, because IPV4V6 looks different from IP+IPV6 from the network side. For example, with IP+IPV6 you might be provisioned with DNS64 resolvers on the IPV6 PDP context (because the network can't know that you'll establish a separate IP(v4) PDP context), while in IPV4V6 you might get normal resolvers without DNS64. It is also possible for a network operator to limit the amount of parallel PDP contexts allowed. So if that limit is 1, by splitting IPV4V6 unconditionally you'll end up with either IPv4 *or* IPv6 connectivity, not both. Another thing that is technically possible, but probably not very common, is for an operator to only support the IPV4V6 PDP context type but not IP/IPV6. If so splitting would prevent connectivity. If the modem supports the true IPV4V6 context type, and the network does too, then I think that's the one that should be used. Splitting it into two bearers should only be done if either the modem or the network lacks support for true IPV4V6, IMHO. > Probing requires a connection attempt; and a connection attempt will > require some prerequisites like the modem being registered to the > network, or packet service activated. I haven't tried to see what the > error could be if we try a connection even before all those are ready, > but I wouldn't rely on that, even if we do get NoDeviceSupport. Very > firmware specific I would say. Ack. Well, with a fallback mechanism in place you'd recover gracefully from the NoDeviceSupport error anyway, so I'd focus any efforts on that... > It probably makes sense to have this retry mechanism in place in > NetworkManager, although ModemManager could also be a good place to do > this. It all depends on how we want to treat errors in connection to > the different PDP context types: either fail if the exact one is not > supported, or retry with some other combination. A new boolean > property passed in connection details could instruct ModemManager to > work in one way or the other. If you want to explicitly test for > IPv4IPv6 and fail if not supported, we could allow passing a > "strict-pdp-type" boolean flag set to TRUE; otherwise, the default > could be to try with separate IPv4 and IPv6 or even with just IPv4 in > the worst case. ModemManager could be a good place to handle this so > that other connection managers using MM benefit from the change as > well, not just NetworkManager (being this change very mobile broadband > specific). Yes, I think the fallback could be implemented in MM as well - it just needs to be *somewhere*. :-) Note that (AIUI), PDP context type requests are merely advisory; it is possible for a network operator to give you an IPv4-only PDP context if you requested IPv6 or vice versa. So you could say that this "looseness" extends to MM's API, i.e., that NM can say ip-type=ipv6 but if that's not supported it can end up with a ip-type=ipv4 bearer due to an internal MM fallback mechanism kicking in. Anyway, I have no strong opinions on where the fallback should be located and how it should work in detail, but I do think *something* is needed if you want to avoid lots of bug reports complaining that their WWAN connection profiles no longer work after upgrading to NM1.0+MM1.4. Tore _______________________________________________ networkmanager-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/networkmanager-list
