Hey, On Tue, Oct 25, 2022 at 8:44 PM Arkadiusz Drabczyk <arkadi...@drabczyk.org> wrote: > > I use ModemManager 1.18.6 on OpenWRT 22.03.0-rc4. I run it: > > root@OpenWrt:~# ModemManager > [6778]: <info> ModemManager (version 1.18.6) starting in system bus... > > Report kernel events: > > root@OpenWrt:~# mmcli > --report-kernel-event=action=add,name=ttyACM2,subsystem=tty > successfully reported kernel event > root@OpenWrt:~# mmcli > --report-kernel-event=action=add,name=wwan0,subsystem=net > successfully reported kernel event > > Modem is found: > > root@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@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@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
