Re: ANN: NetworkManager 1.0.0 released!

On Tue, Dec 23, 2014 at 12:43 PM, Bjørn Mork <bjorn mork no> wrote:
So you need the full context type choice for QMI as well.  The odd
two-step dual-stack connection does not change this.  The PDP type is
always selected by the first connection.

Is that true even if we use different separate WDS clients? If either
IPv4v6 and IPv4+IPv6 are selected for a QMI modem, MM's logic will
create separate WDS clients, each of them with a different "Set IP
Family Preference" set before calling "Start Network". Are we
achieving something correct with this logic? Or not? And if not, how
are we supposed to request IPv4v6 using only QMI? (i.e. not with the
default profile being configured via AT commands).

I verified a while back that this is what Verizon's connection manager
did on Windows with the UML290 to achieve a working dual-stack
connection.  And yes, all 3 PDP contexts in the modem were "IPV4V6".
AFAIK there is no way to get a dual-stack connection without starting
two WDS clients and setting the IP Family Preference.

Yes.  But note that the shared "IPV4V6" bearer is created by the *first*
WDS client issuing "start network".  The second WDS client is simply a
QMI management oddity.  It does not create or modify the bearer in any
way.  How could it?

Depending on your profile config, the results of two successive WDS
start network commands will be:

profile PDP type = IPV4V6
 ipfamily=4; WDS client A start network => success, IPV4V6 bearer created
 ipfamily=6; WDS client B start network => success

profile PDP type = IPV4
 ipfamily=4; WDS client A start network => success, IPV4 bearer created
 ipfamily=6; WDS client B start network => failure

profile PDP type = IPV6
 ipfamily=4; WDS client A start network => failure
 ipfamily=6; WDS client B start network => success, IPV6 bearer created

That's much clearer now, thanks!

The only way you can select the bearer PDP type is by modifying the
profile (either default or referenced from the profile TLV).  If you
don't control the profile, then the result is arbitrarily defined by the
existing default.

We really need to look for a way to define IPV4V6 profiles with QMI
then, there has to be some way to do that. And we should switch the
implementation to activate already predefined profiles, instead of
what we currently do with the StartNetwork passing APN explicitly.


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