<div dir="ltr"><div>Hi Reinhard</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px">Can we please get back QMI as an alternative to AT^SWWAN & CDC ECM for the</span><br style="font-size:12.8px"><span style="font-size:12.8px">next PLS8 firmware update </span></blockquote><div><br></div><div>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</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 28, 2016 at 2:41 PM, Reinhard Speyerer <span dir="ltr"><<a href="mailto:rspmn@arcor.de" target="_blank">rspmn@arcor.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Nov 28, 2016 at 08:23:23PM +0100, Aleksander Morgado wrote:<br>
> On Mon, Nov 28, 2016 at 7:03 PM, matthew stanger <<a href="mailto:stangerm2@gmail.com">stangerm2@gmail.com</a>> wrote:<br>
> >> Ah, yeah. If the plugin does its own logic to select which CID to use,<br>
> >> it should not rely on the parent's connection status check. In our<br>
> >> case, though, I think we should default back to letting the generic<br>
> >> logic decide the CID to use (i.e. don't fix to use the CIDs 1 and 3).<br>
> >> If we do so, we could avoid subclassing the whole connect_3gpp()<br>
> >> sequence and instead subclass some of its sub-steps, like<br>
> >> dial_3gpp()).<br>
> ><br>
> ><br>
> > I agree I think using the default CID method would be best but we'd have to<br>
> > have something in there to default to CID 3 for Verizon or none of the -X<br>
> > modems will work with that carrier for LTE.<br>
><br>
> Yes, but what :)<br>
><br>
> BTW, your initial implementation does use CID 1, but you said we<br>
> couldn't use it according to Verizon?<br>
<br>
</span>Hi,<br>
using CID 1 when this CID could be used for RAT LTE when used with<br>
AT!SCACT or AT^SWWAN may generally be problematic for the following<br>
reason: when the mobile is registering to LTE CID 1 is used by most<br>
mobiles to handle the default bearer assigned by the network during<br>
the EPS attach procedure.<br>
<br>
This means that whenever a value that differs from "IPV4V6","" is stored<br>
there the mobile asks the network to use this value for the EPS attach<br>
default bearer parameters whenever it performs the next EPS attach (e.g.<br>
after poweron) instead of letting the network assign them in the Activate<br>
Default Bearer request.<br>
<br>
Using a value which is not accepted by the network (e.g. by mistyping the<br>
APN) normally causes the network to send a EPS Attach reject to the mobile<br>
which causes the mobile to fall back to UMTS instead of using LTE.<br>
<br>
If one uses another free CID > 1 and the default "IPV4V6","" for CID 1 the<br>
mobile would be able to register to LTE and one would only get an error<br>
after AT!SCACT or AT^SWWAN in case a value which is not accepted by the<br>
network is used.<br>
<br>
A disadvantage of this scheme is that one has to read the<br>
parameters from AT+CGCONTRDP=1 instead of AT+CGCONTRDP=<n> when the<br>
APN used for CID <n> matches the APN assigned to the default bearer.<br>
<br>
This is not necessary for Gobi/QMI as the WDSGetCurrentSettings implicitly<br>
refers to the preceeding WDSStartNetworkInterface.<br>
Can we please get back QMI as an alternative to AT^SWWAN & CDC ECM for the<br>
next PLS8 firmware update ;-)<br>
<br>
Regards,<br>
Reinhard<br>
</blockquote></div><br></div>