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 <aleksan...@aleksander.es> 
Sent: Tuesday, 30 November 2021 2:24 PM
To: Amol Lad <amol....@4rf.com>; Daniele Palmas <dnl...@gmail.com>; Carlo 
Lobrano <c.lobr...@gmail.com>
Cc: ModemManager (development) <modemmanager-devel@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

Reply via email to