fibocom: Minimum PDP context ID

[Aleksander Morgado]

Hey!

>
> I finally had a chance to investigate this a little further.
>
> >> Which marks the bearer intermediately as not connected and the ECM
> >> connection is torn down on the host.
> >
> > Shouldn't we then change the connection check to use the RNDIS state
> > query instead of +CGACT?
>
> I was wondering about this, but I'm not sure. The documentation isn't
> clear about this. Perhaps it is the way to go, more on this later :)
>
> >> Querying with +CGCONTRDP confirms
> >> that the modem is actually only using CID=1.
> >
> > It could be totally possible that you're seeing IP address reported in
> > CID=1 due to the initial EPS bearer being active. But that doesn't
> > explain why you don't see the CID=2 as active as well, if the
> > connection succeeded (unless it was disconnected right away after a
> > successful connection, which could also be possible)
>
> I believe I found out why the modem behaves this way. When the initial
> bearer is set up using the same APN as the ECM bearer, the former is
> internally re-used. Image the following scenario: We configure cid=1
> with the empty APN which makes the SIM use some default which happens to
> match the APN used later on. When the modem is in registered state, we
> have the following situation:
>
> +CGDCONT: 1,"IP","","10.80.129.7",0,0,0
> +CGCONTRDP:
> 1,5,"internet.gma.iot","10.80.129.7",,"193.181.245.57","193.181.245.58"
>

This would match with the idea that "settings" are queried with
+CGDCONT while "state" is queried with +CGCONTRDP; i.e. we request
blank APN in settings, but the network assigns "internet.gma.iot".

> Then, when setting up the ECM connection, i.e. connecting using
> +GTRNDIS, leads to the following situations:
>
> +CGDCONT: 1,"IP","","10.80.129.7",0,0,0
> +CGDCONT: 2,"IP","internet.gma.iot","0.0.0.0",0,0,0

The CID=2 context was created because we're now explicitly requesting
a specific APN in settings. I think that should be fine.

> +CGCONTRDP:
> 1,5,"internet.gma.iot","10.80.129.7",,"193.181.245.57","193.181.245.58"
> +GTRNDIS: 1,2,"10.80.129.7","193.181.245.57","193.181.245.58"
> +CGACT: 1,1
> +CGACT: 2,0

So CID=2 is not being used at all because the runtime state already
matches the settings we were requesting. So this is like, we create
some specific bearer settings to use in CID=2 but the modem decides to
reuse the already connected CID=1 that had the same runtime settings.
We should handle this somehow definitely.

>
> However, when configuring different APN for initial and ECM bearer, this
> is the behavior after the +GTRNDIS connection:
>
> +CGDCONT: 1,"IP","gemalto.ericsson.iot","10.118.26.77",0,0,0
> +CGDCONT: 2,"IP","internet.gma.iot","10.80.196.82",0,0,0
> +CGCONTRDP:
> 1,5,"gemalto.ericsson.iot","10.118.26.77",,"193.181.245.57","193.181.245.58"
> +CGCONTRDP:
> 2,6,"internet.gma.iot","10.80.196.82",,"193.181.245.57","193.181.245.58"
> +GTRNDIS: 1,2,"10.80.196.82","193.181.245.57","193.181.245.58"
> +CGACT: 1,1
> +CGACT: 2,1
>

All this above is expected, right? I don't see any issue with that.

> I'm guessing we can deal with the first scenario by using +GTRNDIS? to
> monitor the connection instead of +CGACT? when using the Fibocom ECM
> bearer. Do you believe that would be sufficient or is it a problem that
> +CGDCONT? doesn't contain an IP for our ECM bearer context?
>

Once the connection attempt has succeeded, we should run an explicit
+CGCONTRDP to look for which CID is the one that got really connected
matching the APN we requested, and if the CID is different to the one
that we thought would be, then internally change the CID value so that
the connection checks can go on normally with the correct CID,
something like that? What do you think?

> When hacking the initial EPS bearer setup into a connection manager
> (e.g. NetworkManager), should this be done before or after enabling the
> modem device?
>
> In a previous response, you wrote:
>
>  > load_initial_eps_bearer_settings() refers to loading the initial EPS
>  > bearer settings as configured and stored in the modem
>
> and
>
>  > load_initial_eps_bearer() refers to loading the initial EPS bearer
>  > settings currently agreed with the network.
>
> However, when looking at the cinterion implementation, I can see that
> the former queries +CGCONTRDP while the latter queries +CGDCONT. Isn't
> that exactly opposite to what you said?
>

Looks like that would be mixed in the Cinterion plugin? Or maybe the
Cinterion modules behave in a different way?
Giacinto, what do you think?

-- 
Aleksander