Quectel EC25 bug - interaction between generic/3GPP and QMI connection methods

Paul Bartell paul.bartell at gmail.com
Thu Apr 16 17:38:29 UTC 2020


If your sim card matches with an installed MBN carrier config, that
MBN will usually inject default APN settings each time it is activated
by a new sim card installation.

Depending on the carrier, you may be able to disable MBN autoselection
with the AT+QMBNCFG command and force the use of the generic carrier
profile (without defined APN defaults).

Alternatively, you can clear these settings each time a new SIM is
inserted with qmi WDS Modify Profile.
Setting the APN of profile 1 to an empty string will cause the modem
to use the network provided default apn for IMS / default bearer
purposes. Profile #1 always corresponds to the default bearer.

You may also run into interference from the built in OMA-DM client. It
tends to use the wrong PDP context to connect and report. If you
tonnes of "+QODM" unsolicited responses on the primary at port after a
fresh restart, this is likely the issue you are running into.

On Thu, Apr 16, 2020 at 8:12 AM Dan Williams <dcbw at redhat.com> wrote:
>
> On Thu, 2020-04-16 at 15:20 +0100, Tim Small wrote:
> > Hello,
> >
> > We've got some EC25, and found the following bug...
> >
> > On all tested EC25 firmware versions.
> >
> > With ModemManager 1.10.0 and libqmi 1.22.0  and also with
> > ModemManager
> > 1.12.6 and libqmi 1.24.8.
> >
> > Due to the QMI bug recently described on this list, these modems have
> > previously been occasionally running with the generic / 3GPP plugin,
> > and
> > occasionally with the quectel / QMI plugin.
> >
> > Things were working OK, up until the time that the modems were
> > switched
> > to a different SIM card.
> >
> > The modems continuously timed out during the "connecting" phase.
> >
> > They appear to have retained the settings from the previous SIM card
> > (appears to be stored in non volatile memory), and that remembered
> > connection seems to stop the new connection (different SIM / APN).
>
> I'm pretty sure that's how all modems work.  The PDP contexts are in
> the modem NVRAM and have nothing to do with the SIM card. That's per
> the 3GPP standards and have always been that way.
>
> What might be different is that with LTE default bearer autoconnect
> each modem can decide what context to use for the autoconnect. Maybe
> the EC25 just uses context #1 and that sets up something in the
> firmware that makes it fail when trying to activate context 2 with MM.
>
> Dan
>
> > The following workaround gets it to connect:
> >
> > > > AT+CGDCONT?
> >
> > << +CGDCONT:
> > 1,"IPV4V6","EEM2M","0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0",0,0,0,0
> > << +CGDCONT: 2,"IP","giffgaff.com","0.0.0.0",0,0,0,0
> > <<
> > << OK
> >
> > > > AT+CGDCONT=1,"IP",""
> >
> > << OK
> >
> > > > AT+CGDCONT?
> >
> > << +CGDCONT: 1,"IP","","0.0.0.0",0,0,0,0
> > << +CGDCONT: 2,"IP","giffgaff.com","0.0.0.0",0,0,0,0
> > <<
> > << OK
> >
> > i.e. undefine the first PDP, and it will then connect via QMI.
> >
> > Not sure if this is a modem firmware bug, or MM?  Any thoughts?
> >
> > Tim.
> >
>
> _______________________________________________
> ModemManager-devel mailing list
> ModemManager-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel


More information about the ModemManager-devel mailing list