Re: ANN: NetworkManager 1.0.0 released!

[Tore Anderson <tore fud no>]

* 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