Odd MM Bearer behavior

Christopher Penney mrpher at gmail.com
Tue May 18 08:38:45 UTC 2021 

Hi Aleksander thanks so much for getting back to me!

Is this T-Mobile in the US or somewhere else?
-- Yes, in the US

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.
-- 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.

Does this SIM work fine on non-ModemManager setups but using exactly the
same device?
-- Yes, this is the most confusing part.  IoTDataWorks SIM performed
perfectly for weeks straight on a variety of different non-ModemManager
systems.

Current specs:
mmcli 1.14.2
qmicli 1.26.0
Quectel EG25G, firmware EG25GGBR07A08M2G. * Note, I also tested this with
four other modems of varying models (i.e EC25A) with the same issue.

root at 325da06:~# qmicli -d /dev/cdc-wdm0 -p --wds-get-profile-list=3gpp
Profile list retrieved:
        [1] 3gpp -
                APN: 'fast.t-mobile.com'
                PDP type: 'ipv4-or-ipv6'
                PDP context number: '1'
                Username: ''
                Password: ''
                Auth: 'none'
                No roaming: 'no'
                APN disabled: 'no'
        [2] 3gpp -
                APN: 'ims'
                PDP type: 'ipv4-or-ipv6'
                PDP context number: '2'
                Username: ''
                Password: ''
                Auth: 'none'
                No roaming: 'no'
                APN disabled: 'no'
        [3] 3gpp -
                APN: 'sos'
                PDP type: 'ipv4-or-ipv6'
                PDP context number: '3'
                Username: ''
                Password: ''
                Auth: 'none'
                No roaming: 'no'
                APN disabled: 'no'
        [4] 3gpp -
                APN: 'tmus'
                PDP type: 'ipv4-or-ipv6'
                PDP context number: '4'
                Username: ''
                Password: ''
                Auth: 'none'
                No roaming: 'no'
                APN disabled: 'no'

root at 325da06:~# qmicli -d /dev/cdc-wdm0 -p --wds-get-lte-attach-parameters
error: Unknown option --wds-get-lte-attach-parameters

root at 325da06:~# qmicli -d /dev/cdc-wdm0 -p --wds-get-lte-attach-pdn-list
error: Unknown option --wds-get-lte-attach-pdn-list

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.
I'm wondering if perhaps the IoTDataWorks default APN of `m2mglobal` should
be changed to 'fast.t-mobile.com' to test?

Can't thank you enough for assisting!

On Tue, May 18, 2021 at 3:44 AM Aleksander Morgado <aleksander at aleksander.es>
wrote:

> Hey Christopher,
>
> > Hello, I'm reaching out to this group in desperation.
> > 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.
> >
>
> What MM and libqmi version?
> What modem model?
>
> > 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.
> >
>
> The increasing number of bearers indicates probably that you're using
> an old version of ModemManager. When using NM+MM, and when NM attempts
> always with the same set of settings, the bearer count should not
> increase (bearers with the same settings are recycled). But that's
> unrelated to your problem, so ignore that, but you should anyway
> probably upgrade both libqmi/MM at some point.
>
> > The logs show:
> >
> > journalctl -u ModemManager
> > May 17 11:53:20 325da06 ModemManager[1398]: [modem0/bearer17] connection
> attempt #1 failed: QMI protocol error (14): 'CallFailed'
> > May 17 11:53:20 325da06 ModemManager[1398]: [modem0] state changed
> (connecting -> registered)
> > May 17 11:53:20 325da06 ModemManager[1398]: [modem0/bearer17] connection
> #1 finished: duration 0s, tx: 0 bytes, rx :0 bytes
> > May 17 11:53:20 325da06 ModemManager[1398]: [modem0] simple connect
> started...
> > May 17 11:53:20 325da06 ModemManager[1398]: [modem0] simple connect
> state (4/8): wait to get fully enabled
> > May 17 11:53:20 325da06 ModemManager[1398]: [modem0] simple connect
> state (5/8): register
> > May 17 11:53:20 325da06 ModemManager[1398]: [modem0] simple connect
> state (6/8): bearer
> > May 17 11:53:20 325da06 ModemManager[1398]: [modem0] simple connect
> state (7/8): connect
> > May 17 11:53:20 325da06 ModemManager[1398]: [modem0] state changed
> (registered -> connecting)
> > May 17 11:53:20 325da06 ModemManager[1398]: [modem0/bearer18] couldn't
> start network: QMI protocol error (14): 'CallFailed'
> > May 17 11:53:20 325da06 ModemManager[1398]: [modem0/bearer18] call end
> reason (1005): gsm-wcdma-insufficient-resources
> > May 17 11:53:20 325da06 ModemManager[1398]: [modem0/bearer18] verbose
> call end reason (6,26): [3gpp] insufficient-resources
> > May 17 11:53:21 325da06 ModemManager[1398]: [modem0/bearer18] couldn't
> start network: QMI protocol error (14): 'CallFailed'
> > May 17 11:53:21 325da06 ModemManager[1398]: [modem0/bearer18] call end
> reason (1005): gsm-wcdma-insufficient-resources
> > May 17 11:53:21 325da06 ModemManager[1398]: [modem0/bearer18] verbose
> call end reason (6,26): [3gpp] insufficient-resources
> > May 17 11:53:21 325da06 ModemManager[1398]: [modem0/bearer18] connection
> attempt #1 failed: QMI protocol error (14): 'CallFailed'
> >
>
> This is the network telling us it cannot serve the connection request
> as it doesn't have enough resources. Is this T-Mobile in the US or
> somewhere else?
>
> > mmcli -m 0
> > SIM      |               dbus path: /org/freedesktop/ModemManager1/SIM/0
> >   -----------------------------------
> > Bearer   |               dbus path:
> /org/freedesktop/ModemManager1/Bearer/802
> >
> > mmcli -m 0 again, a few seconds later
> >
> > SIM      |               dbus path: /org/freedesktop/ModemManager1/SIM/0
> >   -----------------------------------
> > Bearer   |               dbus path:
> /org/freedesktop/ModemManager1/Bearer/1343
> >
> > Again, an hour or so later:
> >
> > SIM      |               dbus path: /org/freedesktop/ModemManager1/SIM/0
> >   -----------------------------------
> > Bearer   |               dbus path:
> /org/freedesktop/ModemManager1/Bearer/16353
> >
> > 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.
>
> 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.
>
> Does this SIM work fine on non-ModemManager setups but using exactly
> the same device?
>
> May be a long shot, but if you're using the expected APN settings for
> the connection, this issue could be a misconfiguration of the initial
> EPS bearer settings used during network attach.
>
> Can you run the following to see which are the configured profiles in
> your device?
> $ sudo qmicli -d /dev/cdc-wdm0 -p --wds-get-profile-list=3gpp
> $ sudo qmicli -d /dev/cdc-wdm0 -p --wds-get-lte-attach-parameters
> $ sudo qmicli -d /dev/cdc-wdm0 -p --wds-get-lte-attach-pdn-list
>
> --
> Aleksander
> https://aleksander.es
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/modemmanager-devel/attachments/20210518/d825175e/attachment.htm>

More information about the ModemManager-devel mailing list