Re: Quectel EC25 bug - interaction between generic/3GPP and QMI connection methods
Tim, On Thu, Apr 16, 2020 at 1:29 PM Tim Small wrote: > > Hi Paul, > > Thanks for your response... > > On 16/04/2020 18:38, Paul Bartell wrote: > > 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. > > > The current model that NetworkManager and ModemManager use is that all > state is defined in the nm connection settings, so from what you say I > think that mm should probably (at least by default) remove configured > settings to get the modem to a consistent state, irrespective of > previous configurations that mm has installed on the modem in the past? > It's really about configuring the initial EPS bearer. The SetInitialEpsBearerSettings api exposed by MM in the Modem3gpp interface seems like a good way to expose this setting to MM client apps. So far it has only been implemented for mbim modems. EC25 modems in mbim mode do not support this feature though. I'm not sure if this gets set in the NetworkManager world. In most cases, the apn setting that is hardcoded in the carrier config mbn is correct. For AT in the US, the default eps bearer apn changes depending on the rate plan. Most other US carriers use a common default EPS bearer apn for all of their rate plans. I've seen a similar quirk when using other MDM9x07 modems (Telit LE910C4-NF). > Regards. > > Tim. > > -- > South East Open Source Solutions Limited > Registered in England and Wales with company number 06134732. > Registered Office: 2 Powell Gardens, Redhill, Surrey, RH1 1TQ > VAT number: 900 6633 53 http://seoss.co.uk/ +44-(0)1273-808309 > ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Quectel EC25 bug - interaction between generic/3GPP and QMI connection methods
Hi Paul, Thanks for your response... On 16/04/2020 18:38, Paul Bartell wrote: > 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. The current model that NetworkManager and ModemManager use is that all state is defined in the nm connection settings, so from what you say I think that mm should probably (at least by default) remove configured settings to get the modem to a consistent state, irrespective of previous configurations that mm has installed on the modem in the past? Regards. Tim. -- South East Open Source Solutions Limited Registered in England and Wales with company number 06134732. Registered Office: 2 Powell Gardens, Redhill, Surrey, RH1 1TQ VAT number: 900 6633 53 http://seoss.co.uk/ +44-(0)1273-808309 ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Quectel EC25 bug - interaction between generic/3GPP and QMI connection methods
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 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
Re: Quectel EC25 bug - interaction between generic/3GPP and QMI connection methods
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
Quectel EC25 bug - interaction between generic/3GPP and QMI connection methods
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). 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. -- South East Open Source Solutions Limited Registered in England and Wales with company number 06134732. Registered Office: 2 Powell Gardens, Redhill, Surrey, RH1 1TQ VAT number: 900 6633 53 http://seoss.co.uk/ +44-(0)1273-808309 ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
