Fwd: Cinterion plugin patch

[matthew stanger]

Hi Reinhard


> Can we please get back QMI as an alternative to AT^SWWAN & CDC ECM for the
> next PLS8 firmware update


FYI we told Gelmalto that, for us, moving away from QMI seemed like a step
in the wrong direction. It seems like they want to support building modules
with chipsets from other vendors like Intel. To keep things uniform they
are dropping QMI across the boarding and going the SWWAN route & something
about making windows developers lives easier.... That is just my 2 cents
though. I confirmed, after hacking the ECM driver to work with the 3.x
firmware, from Cinterion that QMI logic has been dropped from the module
all together and will not be brought back in the foreseeable future :o

On Mon, Nov 28, 2016 at 2:41 PM, Reinhard Speyerer <rspmn at arcor.de> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/modemmanager-devel/attachments/20161128/1f9b92a4/attachment.html>