[PATCH] api: allow specifying the PDP CID to use

Dan Williams dcbw at redhat.com
Mon May 15 14:57:52 UTC 2017


On Mon, 2017-05-15 at 12:05 +0200, Bjørn Mork wrote:
> Aleksander Morgado <aleksander at aleksander.es> writes:
> 
> > On Mon, May 15, 2017 at 10:42 AM, Bjørn Mork <bjorn at mork.no> wrote:
> > > > > Lastly, QMI doesn't even use PDP contexts, so how is that
> > > > > going to
> > > > > work?  I guess you can assign the context # in the creation
> > > > > message,
> > > > > but still, what does verizon recommend that QMI users do if
> > > > > they cannot
> > > > > use PDP contexts?
> > > > 
> > > > In a QMI based implementation the "pdp-cid" setting would be
> > > > ignored,
> > > > and the connection setting would just go on only with the APN
> > > > setting
> > > > given. I'm assuming that having "carrier certified" QMI
> > > > firmware
> > > > configuration images would have something to do with how all
> > > > this is
> > > > organized internally, but not sure. Although, QMI also has APIs
> > > > for
> > > > profiles and these match the PDP context configurations seen
> > > > with
> > > > AT+CGDCONT, or not? I didn't play much with the QMI profiles
> > > > myself,
> > > > no idea.
> > > 
> > > I believe they match.  You should be able to use the "Profile
> > > Index"
> > > TLVs of the "Start Network" request to force it.
> > 
> > So, can we specify e.g. APN and "profile index" in the same Start
> > Network request, and make the firmware reconfigure the given
> > profile
> > with the given APN? or is the "profile index" just a way to select
> > which profile to start network with?
> 
> Don't know.  Probably the latter, similar to AT+CGACT

If we really want to do this for QMI, we need to complicate the setup
logic.  Maybe we should do it anyway.

But whenever connecting with a pdp-cid, we'd need to WDSGetProfileList,
 then for each profile we WDSGetProfileSettings for the given profile
index (which isn't the same as PDP Context ID AFAIK), and look for the
one with the given "WDS PDP Context Number" (TLV 0x25), and then verify
the APN.

If the APN doesn't match, we'd probably want to fail the connection. 
I'd rather have that operation fail, and add Create/Modify/Delete
"Context" objects (eg, EPS or PDP contexts) functions to ModemManager
than have the connect call overwrite some arbitrary context.  I feel
like that's a lot clearer from an API perspective.

And of course, I have no idea how we'd handle this with MBIM.  And
obviously CDMA/3GPP2 devices wouldn't support this since they don't
really do APNs.

Dan


More information about the ModemManager-devel mailing list