mmcli --simple-connect does not wait for timeout in all conditions in QMI [MM 1.18.2]

[Amol Lad]

Hi Aleksander,

Thanks for your reply.

I don’t think this problem is due to need for delay after band change or explicit wait needed for band change to take into effect. I've applied Daniele's change to use "QMI over MBIM" for bands change on 1.18.2 so MBIM not using AT commands for bands update.

Also, the same problem is observed in Sierra EM7565 also so this is not specific to Telit.

It seems in QMI, immediate failure is returned in (registered -> connecting) without waiting for timeout

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'

However, in MBIM the state machine stays in (registered -> connecting) till timeout.

As an experiment, in MBIM, I changed band again to a valid band when SM was in (registered->connecting) and it immediately went to connected

info 2021-11-30T09:26:46+00:00 : <info>  [modem0] state changed (registered -> connecting)
< change to a valid band in another shell>
info 2021-11-30T09:27:01+00:00 : <info>  [modem0] state changed (connecting -> connected)

Amol










info 2021-11-30T09:27:01+00:00 : <info>  [modem0] state changed (connecting -> connected)

-----Original Message-----
From: Aleksander Morgado <aleksander at aleksander.es> 
Sent: Tuesday, 30 November 2021 2:24 PM
To: Amol Lad <Amol.Lad at 4rf.com>; Daniele Palmas <dnlplm at gmail.com>; Carlo Lobrano <c.lobrano at gmail.com>
Cc: ModemManager (development) <modemmanager-devel at lists.freedesktop.org>
Subject: Re: mmcli --simple-connect does not wait for timeout in all conditions in QMI [MM 1.18.2]

Hey

>
> 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
>
> #!/bin/bash
>
> 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?

--
Aleksander
https://aleksander.es