[EXTERNAL] Re: connect using a specific PDP CID

[Dan Williams]

On Thu, 2019-03-14 at 16:53 +0000, Taff, Philip wrote:
> > From: Aleksander Morgado <aleksander at aleksander.es>
> > Sent: Friday, March 08, 2019 2:01 PM
> > 
> > I have mixed feelings about this patch :) in one side, it's not the
> > best way to do it, as a proper profile management API would be
> > best,
> > but from the other side it's a quick way to get the issue resolved
> > until that API is developed; if ever!
> > @Dan Williams what do you think? should we think in integrating
> > this
> > workaround until the profile management API is done?
> > 
> 
> The patch would work for us. Do we need permission to use it? It's
> GPL?
> 
> > > On Fri, Mar 8, 2019 at 11:40 AM Aleksander Morgado
> > <aleksander at aleksander.es> wrote:
> > > > Right now, you could manually create the PDP context with the
> > > > settings
> > > > you want, and MM should re-use the already created context if
> > > > the
> > > > settings requested match the existing ones.
> > > > 
> 
> I did try letting MM find the right PDP context this way, but the
> recommendation
> I got from Sierra Wireless was to leave the APN blank when connecting
> to CAT-M
> networks and allow the network to provide the APN name during network
> registration.
> Since PDP context #1 was also blank, MM tried that, which didn't
> work.
> 
> Calling pppd directly using context #3 with a blank APN works fine.

In these scenarios, does anybody know if the issues with a random
context # are:

 (a) the modem itself caring about the context #
 (b) or somehow the network caring about the context # (which I didn't
think was passed to the network at all)
 (c) or is it settings on the PDP Context itself that are wrong and if
the settings were correct any context # would work
 (d) or something else entirely?

I was under the impression that a context is a context is a context,
and as long as the APN, auth, traffic template, etc were all correct
then it shouldn't matter what context # you pick.  Obviously some
contexts are special (like the default/initial bearer/#0 one) but I
didn't think that extended beyond the initial bearer/#0.

Dan