Odd MM Bearer behavior

[Aleksander Morgado]

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