Fwd: Cinterion plugin patch

[Reinhard Speyerer]

On Mon, Nov 28, 2016 at 08:23:23PM +0100, Aleksander Morgado wrote:
> On Mon, Nov 28, 2016 at 7:03 PM, matthew stanger <stangerm2 at gmail.com> wrote:
> >> Ah, yeah. If the plugin does its own logic to select which CID to use,
> >> it should not rely on the parent's connection status check. In our
> >> case, though, I think we should default back to letting the generic
> >> logic decide the CID to use (i.e. don't fix to use the CIDs 1 and 3).
> >> If we do so, we could avoid subclassing the whole connect_3gpp()
> >> sequence and instead subclass some of its sub-steps, like
> >> dial_3gpp()).
> >
> >
> > I agree I think using the default CID method would be best but we'd have to
> > have something in there to default to CID 3 for Verizon or none of the -X
> > modems will work with that carrier for LTE.
> 
> Yes, but what :)
> 
> BTW, your initial implementation does use CID 1, but you said we
> couldn't use it according to Verizon?

Hi,
using CID 1 when this CID could be used for RAT LTE when used with
AT!SCACT or AT^SWWAN may generally be problematic for the following
reason: when the mobile is registering to LTE CID 1 is used by most
mobiles to handle the default bearer assigned by the network during
the EPS attach procedure.

This means that whenever a value that differs from "IPV4V6","" is stored
there the mobile asks the network to use this value for the EPS attach
default bearer parameters whenever it performs the next EPS attach (e.g.
after poweron) instead of letting the network assign them in the Activate
Default Bearer request.

Using a value which is not accepted by the network (e.g. by mistyping the
APN) normally causes the network to send a EPS Attach reject to the mobile
which causes the mobile to fall back to UMTS instead of using LTE.

If one uses another free CID > 1 and the default "IPV4V6","" for CID 1 the
mobile would be able to register to LTE and one would only get an error
after AT!SCACT or AT^SWWAN in case a value which is not accepted by the
network is used.

A disadvantage of this scheme is that one has to read the
parameters from AT+CGCONTRDP=1 instead of AT+CGCONTRDP=<n> when the
APN used for CID <n> matches the APN assigned to the default bearer.

This is not necessary for Gobi/QMI as the WDSGetCurrentSettings implicitly
refers to the preceeding WDSStartNetworkInterface.
Can we please get back QMI as an alternative to AT^SWWAN & CDC ECM for the
next PLS8 firmware update ;-)

Regards,
Reinhard