<div dir="ltr">Hi Aleksander thanks so much for getting back to me!<div><br></div><div>Is this T-Mobile in the US or somewhere else?</div><div>-- Yes, in the US</div><div><br><div>Do other SIMs work fine on the same Balena setup where this issue is happening? i.e. on the same modem where this issue is happening.</div><div>-- Yes, tested close to a dozen SIMs from Twilio (on multiple networks, T-Mobile, Sprint, AT&T, Verizon all without issue) and Hologram (same number of networks without issue) each. Also changing the modem model did not have an impact, see below.<br><br>Does this SIM work fine on non-ModemManager setups but using exactly the same device?</div><div>-- Yes, this is the most confusing part. IoTDataWorks SIM performed perfectly for weeks straight on a variety of different non-ModemManager systems.</div><div><br></div><div>Current specs:<br><div>mmcli 1.14.2</div><div>qmicli 1.26.0</div><div>Quectel EG25G, firmware EG25GGBR07A08M2G. * Note, I also tested this with four other modems of varying models (i.e EC25A) with the same issue.</div><div><br></div><div>root@325da06:~# qmicli -d /dev/cdc-wdm0 -p --wds-get-profile-list=3gpp<br>Profile list retrieved:<br> [1] 3gpp - <br> APN: '<a href="http://fast.t-mobile.com">fast.t-mobile.com</a>'<br> PDP type: 'ipv4-or-ipv6'<br> PDP context number: '1'<br> Username: ''<br> Password: ''<br> Auth: 'none'<br> No roaming: 'no'<br> APN disabled: 'no'<br> [2] 3gpp - <br> APN: 'ims'<br> PDP type: 'ipv4-or-ipv6'<br> PDP context number: '2'<br> Username: ''<br> Password: ''<br> Auth: 'none'<br> No roaming: 'no'<br> APN disabled: 'no'<br> [3] 3gpp - <br> APN: 'sos'<br> PDP type: 'ipv4-or-ipv6'<br> PDP context number: '3'<br> Username: ''<br> Password: ''<br> Auth: 'none'<br> No roaming: 'no'<br> APN disabled: 'no'<br> [4] 3gpp - <br> APN: 'tmus'<br> PDP type: 'ipv4-or-ipv6'<br> PDP context number: '4'<br> Username: ''<br> Password: ''<br> Auth: 'none'<br> No roaming: 'no'<br> APN disabled: 'no'<br></div><div><br></div><div>root@325da06:~# qmicli -d /dev/cdc-wdm0 -p --wds-get-lte-attach-parameters<br>error: Unknown option --wds-get-lte-attach-parameters</div><div><br>root@325da06:~# qmicli -d /dev/cdc-wdm0 -p --wds-get-lte-attach-pdn-list<br>error: Unknown option --wds-get-lte-attach-pdn-list<br></div></div></div><div><br></div><div>Above errors unfortunately are a bit out of my control, considering the ModemManager version is controlled by Balena's OS which means upgrading would presumably require a release on their side.</div><div>I'm wondering if perhaps the IoTDataWorks default APN of `m2mglobal` should be changed to '<a href="http://fast.t-mobile.com">fast.t-mobile.com</a>' to test?</div><div><br></div><div>Can't thank you enough for assisting!</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 18, 2021 at 3:44 AM Aleksander Morgado <<a href="mailto:aleksander@aleksander.es">aleksander@aleksander.es</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hey Christopher,<br> <br> > Hello, I'm reaching out to this group in desperation.<br> > We've been trying to solve this problem with ModemManager and a specific SIM from IoTDataWorks combined with ModemManager inside BalenaOS that has us perplexed and stuck.<br> ><br> <br> What MM and libqmi version?<br> What modem model?<br> <br> > We've tested this SIM which uses T-Mobile under the hood on other devices and it works fine. The issue is when configuring it for ModemManager on Balena. In particular mmcli -m 0 shows a stalls in the connecting state and every few seconds cycles through an increasing number of bearers, never settling.<br> ><br> <br> The increasing number of bearers indicates probably that you're using<br> an old version of ModemManager. When using NM+MM, and when NM attempts<br> always with the same set of settings, the bearer count should not<br> increase (bearers with the same settings are recycled). But that's<br> unrelated to your problem, so ignore that, but you should anyway<br> probably upgrade both libqmi/MM at some point.<br> <br> > The logs show:<br> ><br> > journalctl -u ModemManager<br> > May 17 11:53:20 325da06 ModemManager[1398]: [modem0/bearer17] connection attempt #1 failed: QMI protocol error (14): 'CallFailed'<br> > May 17 11:53:20 325da06 ModemManager[1398]: [modem0] state changed (connecting -> registered)<br> > May 17 11:53:20 325da06 ModemManager[1398]: [modem0/bearer17] connection #1 finished: duration 0s, tx: 0 bytes, rx :0 bytes<br> > May 17 11:53:20 325da06 ModemManager[1398]: [modem0] simple connect started...<br> > May 17 11:53:20 325da06 ModemManager[1398]: [modem0] simple connect state (4/8): wait to get fully enabled<br> > May 17 11:53:20 325da06 ModemManager[1398]: [modem0] simple connect state (5/8): register<br> > May 17 11:53:20 325da06 ModemManager[1398]: [modem0] simple connect state (6/8): bearer<br> > May 17 11:53:20 325da06 ModemManager[1398]: [modem0] simple connect state (7/8): connect<br> > May 17 11:53:20 325da06 ModemManager[1398]: [modem0] state changed (registered -> connecting)<br> > May 17 11:53:20 325da06 ModemManager[1398]: [modem0/bearer18] couldn't start network: QMI protocol error (14): 'CallFailed'<br> > May 17 11:53:20 325da06 ModemManager[1398]: [modem0/bearer18] call end reason (1005): gsm-wcdma-insufficient-resources<br> > May 17 11:53:20 325da06 ModemManager[1398]: [modem0/bearer18] verbose call end reason (6,26): [3gpp] insufficient-resources<br> > May 17 11:53:21 325da06 ModemManager[1398]: [modem0/bearer18] couldn't start network: QMI protocol error (14): 'CallFailed'<br> > May 17 11:53:21 325da06 ModemManager[1398]: [modem0/bearer18] call end reason (1005): gsm-wcdma-insufficient-resources<br> > May 17 11:53:21 325da06 ModemManager[1398]: [modem0/bearer18] verbose call end reason (6,26): [3gpp] insufficient-resources<br> > May 17 11:53:21 325da06 ModemManager[1398]: [modem0/bearer18] connection attempt #1 failed: QMI protocol error (14): 'CallFailed'<br> ><br> <br> This is the network telling us it cannot serve the connection request<br> as it doesn't have enough resources. Is this T-Mobile in the US or<br> somewhere else?<br> <br> > mmcli -m 0<br> > SIM | dbus path: /org/freedesktop/ModemManager1/SIM/0<br> > -----------------------------------<br> > Bearer | dbus path: /org/freedesktop/ModemManager1/Bearer/802<br> ><br> > mmcli -m 0 again, a few seconds later<br> ><br> > SIM | dbus path: /org/freedesktop/ModemManager1/SIM/0<br> > -----------------------------------<br> > Bearer | dbus path: /org/freedesktop/ModemManager1/Bearer/1343<br> ><br> > Again, an hour or so later:<br> ><br> > SIM | dbus path: /org/freedesktop/ModemManager1/SIM/0<br> > -----------------------------------<br> > Bearer | dbus path: /org/freedesktop/ModemManager1/Bearer/16353<br> ><br> > Has anyone seen this behavior before? It's very odd considering that other T-Mobile SIMs work fine on Balena, and this problematic one works fine on non-ModemManager setups.<br> <br> Do other SIMs work fine on the same Balena setup where this issue is<br> happening? i.e. on the same modem where this issue is happening.<br> <br> Does this SIM work fine on non-ModemManager setups but using exactly<br> the same device?<br> <br> May be a long shot, but if you're using the expected APN settings for<br> the connection, this issue could be a misconfiguration of the initial<br> EPS bearer settings used during network attach.<br> <br> Can you run the following to see which are the configured profiles in<br> your device?<br> $ sudo qmicli -d /dev/cdc-wdm0 -p --wds-get-profile-list=3gpp<br> $ sudo qmicli -d /dev/cdc-wdm0 -p --wds-get-lte-attach-parameters<br> $ sudo qmicli -d /dev/cdc-wdm0 -p --wds-get-lte-attach-pdn-list<br> <br> -- <br> Aleksander<br> <a href="https://aleksander.es" rel="noreferrer" target="_blank">https://aleksander.es</a><br> </blockquote></div>