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

[Aleksander Morgado]

On Mon, May 15, 2017 at 4:52 AM, Dan Williams <dcbw at redhat.com> wrote:
>> Some operators, most notably Verizon, require connection to be
>> performed through a specific PDP context (#3). This API update allows
>> the user to specify the PDP CID via a new 'pdp-cid' parameter given
>> in
>> either the Simple.Connect() or the Modem.CreateBearer() methods.
>
> I know Verizon "requires" this, but it's completely bogus, right?  eg,
> you can put anything you want into pdp context #3.  I'm fairly sure
> they want a specific APN instead.
>

Oh, I believe it's both things: the specific APN and in PDP context#3.

Something like 2 years ago I got in touch with a company that had this
same issue with a MBIM capable Telit LN930 device. They were told that
Verizon required them to use profile #3 for internet access and have
profiles #1, #2 and #4 defined to very specific APNs: vzwims, vzwadmin
and vzwapp, and they couldn't do so only using the current MBIM
firmware they had because the firmware would store the APN given in
"Basic Connect/Connect" in profile #2 always (checked by issuing
AT+CGDCONT after the MBIM connect). I believe they were able to
request a firmware that would select #3 by default, but the issue is
the same as the one we have here.

> Or does this have to do OTA provisioning of some kind, where they push
> something that references context #3 (and if so, I really wonder how
> that ended up in the 3GPP standards...)
>
> Forgive me if we've discussed this already, I likely forgot.
>

I don't have specific details on why they need it that way, apart from
what I've been told, but it may be something like that indeed.

> My real point is, the user has no idea what's actually *in* context #3,
> regardless of Verizon's "requirement".  It could be 'vzwinternet', but
> maybe it's not.  There's also no way for ModemManager to report the
> existing PDP contexts, nor is there a way to add/delete/modify contexts
> so that you could ensure that #3 actually was 'vzwinternet'.
>

Oh, the patch doesn't just allow to "connect what's in CID=3". It
allows to say: "I want APN vzwinternet AND I want it in CID=3". What
the code does is blindly overwrite whatever setting there is in the
PDP context referenced by the "pdp-cid" number given by the user. I
wonder if we shouldn't also start thinking about providing APIs to
add/delete/modify these? Or not worth?

> 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.

-- 
Aleksander
https://aleksander.es