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 <d...@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@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel _______________________________________________ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
