mmcli --simple-connect does not wait for timeout in all conditions in QMI [MM 1.18.2]
aleksander at aleksander.es
Tue Nov 30 08:54:16 UTC 2021
> I'm observing that in few cases (MM 1.18.2) that --simple-connect returns immediately in QMI mode without waiting for the timeout. No such premature exit is observed in MBIM i.e. MBIM mode works fine.
> It's easily reproducible in my setup.
> 1] Successfully connect bearer first and then run following script
> mmcli -m 0 --simple-disconnect
> mmcli -m 0 --set-current-bands=eutran-71
> mmcli -m 0 --simple-connect="apn=internet" --timeout=10
> Here, I've used eutran-71 band to reproduce the issue. My network provider does not support eutran-71. However, the problem is - if I use some valid band and it takes a little longer for the device to "latch" on the new band then -simple-connect immediately returns with failure :(
> Logs are below when above script is run:
> info 2021-11-30T05:05:27+00:00 : <info> [modem0] state changed (connected -> disconnecting)
> info 2021-11-30T05:05:27+00:00 : <info> [modem0] state changed (disconnecting -> registered)
> info 2021-11-30T05:05:27+00:00 : <info> [modem0/bearer3] connection #1 finished: duration 17s, tx: 48 bytes, rx: 88 bytes
> info 2021-11-30T05:05:29+00:00 : <info> [modem0] simple connect started...
> info 2021-11-30T05:05:29+00:00 : <info> [modem0] simple connect state (4/8): wait to get fully enabled
> info 2021-11-30T05:05:29+00:00 : <info> [modem0] simple connect state (5/8): register
> info 2021-11-30T05:05:29+00:00 : <info> [modem0] simple connect state (6/8): bearer
> info 2021-11-30T05:05:29+00:00 : <info> [modem0] simple connect state (7/8): connect
> info 2021-11-30T05:05:29+00:00 : <info> [modem0] state changed (registered -> connecting)
> info 2021-11-30T05:05:29+00:00 : <info> [modem0/bearer4] couldn't start network: QMI protocol error (14): 'CallFailed'
> info 2021-11-30T05:05:29+00:00 : <info> [modem0/bearer4] verbose call end reason (3,2001): [cm] no-service
> warning 2021-11-30T05:05:29+00:00 : <warn> [modem0/bearer4] connection attempt #1 failed: Call failed: cm error: no-service
So, you changed bands in between that disconnect and the new
connection attempt, but we don't see any log for that operation (that
could be normal, not an issue). The thing is, if you changed bands,
the modem will go through a network unregistration, then attempt to
register again in the new bands. Your connection attempt got in the
middle of that process and so MM was able to go on with the start
network operation because by the time you launched your attempt the
modem was still registered in the network (the change bands operation
is not immediately done by the modem).
There are a few ways to solve this really. You could wait a bit after
changing bands yourself, or we could improve MM so that it explicitly
waits for the bands to be changed (and notified to MM via indications)
once we have requested to change them. I think the latter should be
preferred if possible.
If this works for you in MBIM I guess it's because the AT commands to
change bands using the Telit shared utils do wait for the band change
to take effect before going on. Maybe @Daniele Palmas or @Carlo
Lobrano can confirm if this is the case?
More information about the ModemManager-devel