Re: ANN: NetworkManager 1.0.0 released!

* 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

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

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

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]