Never reconnected after SIM desactivate/activate

Aleksander Morgado aleksander at aleksander.es
Sun Jul 4 21:12:50 UTC 2021


Hey,

>
> Desactivate SIM from operator lead to Status state enabled after a while.
> But when activate SIM again, it loops between those states:
> Jun 29 15:23:11 ws-box-v1.3 ModemManager[630]: <info> [modem1] simple
> connect started...
> Jun 29 15:23:11 ws-box-v1.3 ModemManager[630]: <info> [modem1] simple
> connect state (4/8): wait to get fully enabled
> Jun 29 15:23:11 ws-box-v1.3 ModemManager[630]: <info> [modem1] simple
> connect state (5/8): register
> Jun 29 15:23:11 ws-box-v1.3 ModemManager[630]: <info> [modem1] simple
> connect state (6/8): bearer
> Jun 29 15:23:11 ws-box-v1.3 ModemManager[630]: <info> [modem1] simple
> connect state (7/8): connect
> Jun 29 15:23:11 ws-box-v1.3 ModemManager[630]: <info> [modem1] state
> changed (enabled -> connecting)
> Jun 29 15:23:11 ws-box-v1.3 ModemManager[630]: <info> [modem1/bearer52]
> couldn't start network: QMI protocol error (14): 'CallFailed'
> Jun 29 15:23:11 ws-box-v1.3 ModemManager[630]: <info> [modem1/bearer52]
> call end reason (3): generic-no-service
> Jun 29 15:23:11 ws-box-v1.3 ModemManager[630]: <info> [modem1/bearer52]
> verbose call end reason (2,231): [internal] ip-version-mismatch
> Jun 29 15:23:11 ws-box-v1.3 ModemManager[630]: <warn> [modem1/bearer52]
> connection attempt #1 failed: QMI protocol error (14): 'CallFailed'
> Jun 29 15:23:11 ws-box-v1.3 ModemManager[630]: <info> [modem1] state
> changed (connecting -> enabled)
> Jun 29 15:23:11 ws-box-v1.3 ModemManager[630]: <info> [modem1/bearer52]
> connection #1 finished: duration 0s, tx: 0 bytes, rx :0 bytes
>
> 3GPP bearer is connected
>    Status   |                    lock: sim-pin2
>             |          unlock retries: sim-pin (3), sim-puk (10),
> sim-pin2 (3), sim-puk2 (10)
>             |                   state: enabled
>             |             power state: on
>             |             access tech: umts
>             |          signal quality: 65% (recent)
>
>    -----------------------------------
>    3GPP EPS |    ue mode of operation: csps-2
>             |     initial bearer path:
> /org/freedesktop/ModemManager1/Bearer/21
>             |  initial bearer ip type: ipv4
>    -----------------------------------
>    SIM      |        primary sim path: /org/freedesktop/ModemManager1/SIM/1
>             |          sim slot paths: slot 1:
> /org/freedesktop/ModemManager1/SIM/1 (active)
>             |                          slot 2: none
>    -----------------------------------
>    Bearer   |                   paths:
> /org/freedesktop/ModemManager1/Bearer/52
>             | /org/freedesktop/ModemManager1/Bearer/22
>
>
>    ------------------------
>    General    |       path: /org/freedesktop/ModemManager1/Bearer/21
>               |       type: default-attach
>    ------------------------
>    Status     |  connected: yes
>               |  suspended: no
>               | ip timeout: 20
>    ------------------------
>    Properties |        apn: iot.1nce.net
>               |    ip type: ipv4
>

There seems to be some re-registration problem? Once the module is
kicked out the network, the internal LTE stack timings should control
when the module attempts to re-register to the network. The MM simple
connect operation may trigger a request to register automatically, but
it's up to the device to serve that user request or not.

If you ask me, this is something you need to discuss with the
manufacturer of the module, to see if they can explain why the module
doesn't auto-register.

>
> Only a modem reset allow to get connectivity back:
> mmcli -m X -r
>

Yes, because after the reset, the internal LTE stack state is reseted,
and any detail about when it was kicked out of the network is lost, so
the state starts fresh.

Also, IIRC, depending on the type of error returned by the base
station, the module may be instructed to never re-register again, or
to re-register again after some time. If your case is the former and
the network tells the module to never re-register again, it would make
sense that only the module reset solves the situation.

-- 
Aleksander
https://aleksander.es


More information about the ModemManager-devel mailing list