modem has to stay in registered state for a second before it can connect
Aleksander Morgado
aleksandermj at chromium.org
Mon Nov 7 15:02:29 UTC 2022
Hey,
On Tue, Oct 25, 2022 at 8:44 PM Arkadiusz Drabczyk
<arkadiusz at drabczyk.org> wrote:
>
> I use ModemManager 1.18.6 on OpenWRT 22.03.0-rc4. I run it:
>
> root at OpenWrt:~# ModemManager
> [6778]: <info> ModemManager (version 1.18.6) starting in system bus...
>
> Report kernel events:
>
> root at OpenWrt:~# mmcli --report-kernel-event=action=add,name=ttyACM2,subsystem=tty
> successfully reported kernel event
> root at OpenWrt:~# mmcli --report-kernel-event=action=add,name=wwan0,subsystem=net
> successfully reported kernel event
>
> Modem is found:
>
> root at OpenWrt:~# mmcli -m any
> --------------------------------
> General | path: /org/freedesktop/ModemManager1/Modem/0
> | device id: <REDACTED>
> --------------------------------
> Hardware | manufacturer: Cinterion
> | model: PLAS9-W
> | firmware revision: REVISION 01.004
> | supported: gsm-umts, lte
> | current: gsm-umts, lte
> | equipment id: <REDACTED>
> --------------------------------
> System | device: /sys/devices/platform/soc/8af8800.usb3/8a00000.dwc3/xhci-hcd.0.auto/usb2/2-1
> | drivers: cdc_acm, cdc_ether
> | plugin: cinterion
> | primary port: ttyACM2
> | ports: ttyACM2 (at), wwan0 (net)
> --------------------------------
> Status | unlock retries: ph-fsim-pin (0), sim-puk2 (10), sim-puk (10), sim-pin2 (3),
> | ph-net-puk (0), sim-pin (3), ph-net-pin (0), ph-fsim-puk (0)
> | state: disabled
> | power state: on
> | signal quality: 0% (cached)
> --------------------------------
> Modes | supported: allowed: 2g; preferred: none
> | allowed: 3g; preferred: none
> | allowed: 4g; preferred: none
> | allowed: 2g, 3g, 4g; preferred: none
> | current: allowed: any; preferred: none
> --------------------------------
> Bands | supported: egsm, dcs, utran-1, utran-3, utran-6, utran-5, utran-8,
> | eutran-1, eutran-3, eutran-5, eutran-7, eutran-8, eutran-18,
> | eutran-19, eutran-20, eutran-26, eutran-28, eutran-38, eutran-39,
> | eutran-40, eutran-41
> | current: egsm, dcs, utran-1, utran-3, utran-6, utran-5, utran-8,
> | eutran-1, eutran-3, eutran-5, eutran-7, eutran-8, eutran-18,
> | eutran-19, eutran-20, eutran-26, eutran-28, eutran-38, eutran-39,
> | eutran-40, eutran-41
> --------------------------------
> IP | supported: ipv4, ipv6, ipv4v6
> --------------------------------
> 3GPP | imei: <REDACTED>
> --------------------------------
> 3GPP EPS | ue mode of operation: csps-2
> | initial bearer apn: internet
> --------------------------------
> SIM | primary sim path: /org/freedesktop/ModemManager1/SIM/0
>
>
> I'm using Telenor card in international roaming and I get the
> following error with --simple-connect:
>
> root at OpenWrt:~# mmcli -m any --timeout 120 --simple-connect=apn=telenor.smart,ip-type=ipv4
> error: couldn't connect the modem: 'GDBus.Error:org.freedesktop.ModemManager1.Error.MobileEquipment.GprsUnknown: Unspecified GPRS error'
>
> And a few seconds later mmcli reports 'state: searching'. But if I
> kill ModemManager, start it and report kernel events again and enable
> the modem and wait a few seconds before connecting like that:
>
> root at OpenWrt:~# mmcli -m any -e && sleep 1 && mmcli -m any --timeout 120 --simple-connect=apn=telenor.smart,ip-type=ipv4
> successfully enabled the modem
> successfully connected the modem
>
> it works (or at least worked every time so far). To my untrained eye
> it looks like modem has to be in registered state for at least 1
> second before it can connect to non-default bearer. Have you seen
> anything like that before? What could it be - ModemManager issue,
> buggy modem fw (I saw this
> https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/639),
> network issue?
>
A very similar issue was fixed for Qualcomm modems using QMI in the
following merge request:
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/789
The problem solved there was that the connection attempt was started
before the modem was fully registered properly in the PS domain. In
QMI modems we improved the detection of the PS domain registration to
use the DSD service, and only if the DSD service reports a valid
access technology we consider ourselves registered in PS. Those
changes don't introduce any arbitrary delay, instead we rely on the
modem notifying the correct state via updates. But the effect is the
same really, we're waiting just a little bit more between us getting
registered and starting a new connection attempt. Not saying the issue
is the same one, but it looked similar.
In your case, we rely on +CEREG to know whether we're registered or
not in EPS, and if we are, we go on with the connection attempt. I
don't know if we're missing something else to check before starting
the connection attempt. Would you be able to contact the manufacturer
directly (e.g. via support or forum) to ask about this?
--
Aleksander
More information about the ModemManager-devel
mailing list