Regression regarding ip_type when updating from 1.10.4 to 1.12.0

Dan Williams dcbw at redhat.com
Thu Nov 14 21:24:35 UTC 2019


On Thu, 2019-11-14 at 21:59 +0100, Andreas Fett wrote:
> Hi Aleksander,
> 
> On Thu, Nov 14, 2019 at 06:57:54PM +0100, Aleksander Morgado wrote:
> > > Has the interpretation of the ip_type MM_BEARER_IP_FAMILY_IPV4V6
> > > changed when performing the connect?
> > > 
> > 
> > No it hasn't really. I really think you need to know whether the
> > network supports ipv4v6 for a given APN before attempting to use
> > it.
> 
> For writing end user oriented software where the networks and
> operators
> that will be used are unknown when implementing it this becomes a big
> problem.

I'm not sure I see how. If you pass MM_BEARER_IP_FAMILY_ANY then you
will get some kind of connectivity, most often V4 because that's what
most networks provide.

If you pass V4, V6, or V4V6 then MM will fail if the network cannot
provide that connectivity. Presumably you are passing these options
because you require the connectivity each one provides, otherwise if
all you care about is "can I get to the Internet" you could pass ANY.

> Wouldn't that mean one has to try a connect with all bearer types in
> whatever the preferred order is?

Or pass ANY and you'll get some kind of connection to the internet at
least?

Aleksander: we should probably fine-tune the logic something like this:

1) bearer default_ip_family follows what the modem is capable of via
AT+CGDCONT=? or the equivalent; eg if the modem has V4V6 contexts then
we default to IPV4V6.
2) If the user passes a specific IP family for the bearer, fail if that
family is not successfully connected (as we do now?)
3) If the user passes ANY:
  3a) use the default_ip_family (no change)
  3b) the modem accepts whatever connect result happens, eg if v4 or
v6-only that's fine, don't fail.
  3c) if the connection result failed because the network rejected a
V4V6 request for example, or the default_ip_family is V4 but the APN
only accepts V6, then should we retry with V4?

Dan

> Surely this information cannot be expected to be known
> by the user and is not even listed in registries like
> https://gitlab.gnome.org/GNOME/mobile-broadband-provider-info
> 
> Or are there any "cheaper" ways to probe for this than attempting a
> connect?
> 
> Andreas
> 
> _______________________________________________
> ModemManager-devel mailing list
> ModemManager-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel



More information about the ModemManager-devel mailing list