Re: mmcli --simple-connect does not wait for timeout in all conditions in QMI [MM 1.18.2]
Hi Aleksander and Amol, Il giorno mar 30 nov 2021 alle ore 09:54 Aleksander Morgado ha scritto: > > 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? > The #BND command returning OK does not guarantee that the modem is actually registered, but just that the bands have been switched. Regards, Daniele > -- > Aleksander > https://aleksander.es
RE: mmcli --simple-connect does not wait for timeout in all conditions in QMI [MM 1.18.2]
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 : [modem0] state changed (registered -> connecting) info 2021-11-30T05:05:29+00:00 : [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 : [modem0] state changed (registered -> connecting) < change to a valid band in another shell> info 2021-11-30T09:27:01+00:00 : [modem0] state changed (connecting -> connected) Amol info 2021-11-30T09:27:01+00:00 : [modem0] state changed (connecting -> connected) -Original Message- From: Aleksander Morgado Sent: Tuesday, 30 November 2021 2:24 PM To: Amol Lad ; Daniele Palmas ; Carlo Lobrano Cc: ModemManager (development) 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 : [modem0] state changed > (connected -> disconnecting) info 2021-11-30T05:05:27+00:00 : > [modem0] state changed (disconnecting -> registered) info > 2021-11-30T05:05:27+00:00 : [modem0/bearer3] connection #1 finished: > duration 17s, tx: 48 bytes, rx: 88 bytes info 2021-11-30T05:05:29+00:00 : > [modem0] simple connect started... > info 2021-11-30T05:05:29+00:00 : [modem0] simple connect state > (4/8): wait to get fully enabled info 2021-11-30T05:05:29+00:00 : > [modem0] simple connect state (5/8): register info > 2021-11-30T05:05:29+00:00 : [modem0] simple connect state > (6/8): bearer info 2021-11-30T05:05:29+00:00 : [modem0] simple > connect state (7/8): connect info 2021-11-30T05:05:29+00:00 : > [modem0] state changed (registered -> connecting) info > 2021-11-30T05:05:29+00:00 : [modem0/bearer4] couldn't start network: > QMI protocol error (14): 'CallFailed' > info 2021-11-30T05:05:29+00:00 : [modem0/bearer4] verbose call > end reason (3,2001): [cm] no-service warning 2021-11-30T05:05:29+00:00 > : [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
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 : [modem0] state changed (connected -> > disconnecting) > info 2021-11-30T05:05:27+00:00 : [modem0] state changed > (disconnecting -> registered) > info 2021-11-30T05:05:27+00:00 : [modem0/bearer3] connection #1 > finished: duration 17s, tx: 48 bytes, rx: 88 bytes > info 2021-11-30T05:05:29+00:00 : [modem0] simple connect started... > info 2021-11-30T05:05:29+00:00 : [modem0] simple connect state (4/8): > wait to get fully enabled > info 2021-11-30T05:05:29+00:00 : [modem0] simple connect state (5/8): > register > info 2021-11-30T05:05:29+00:00 : [modem0] simple connect state (6/8): > bearer > info 2021-11-30T05:05:29+00:00 : [modem0] simple connect state (7/8): > connect > info 2021-11-30T05:05:29+00:00 : [modem0] state changed (registered > -> connecting) > info 2021-11-30T05:05:29+00:00 : [modem0/bearer4] couldn't start > network: QMI protocol error (14): 'CallFailed' > info 2021-11-30T05:05:29+00:00 : [modem0/bearer4] verbose call end > reason (3,2001): [cm] no-service > warning 2021-11-30T05:05:29+00:00 : [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
mmcli --simple-connect does not wait for timeout in all conditions in QMI [MM 1.18.2]
Hi, 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 : [modem0] state changed (connected -> disconnecting) info 2021-11-30T05:05:27+00:00 : [modem0] state changed (disconnecting -> registered) info 2021-11-30T05:05:27+00:00 : [modem0/bearer3] connection #1 finished: duration 17s, tx: 48 bytes, rx: 88 bytes info 2021-11-30T05:05:29+00:00 : [modem0] simple connect started... info 2021-11-30T05:05:29+00:00 : [modem0] simple connect state (4/8): wait to get fully enabled info 2021-11-30T05:05:29+00:00 : [modem0] simple connect state (5/8): register info 2021-11-30T05:05:29+00:00 : [modem0] simple connect state (6/8): bearer info 2021-11-30T05:05:29+00:00 : [modem0] simple connect state (7/8): connect info 2021-11-30T05:05:29+00:00 : [modem0] state changed (registered -> connecting) info 2021-11-30T05:05:29+00:00 : [modem0/bearer4] couldn't start network: QMI protocol error (14): 'CallFailed' info 2021-11-30T05:05:29+00:00 : [modem0/bearer4] verbose call end reason (3,2001): [cm] no-service warning 2021-11-30T05:05:29+00:00 : [modem0/bearer4] connection attempt #1 failed: Call failed: cm error: no-service info 2021-11-30T05:05:29+00:00 : [modem0] state changed (connecting -> registered) info 2021-11-30T05:05:29+00:00 : [modem0/bearer4] connection #1 finished: duration 0s, tx: 0 bytes, rx: 0 bytes err 2021-11-30T05:05:39+00:00 LTEMGR: ltemon_func.c:986 ltemonUpdateSignalParams: Failed: exitcode = 0 ret = 2 info 2021-11-30T05:05:48+00:00 : [modem0] 3GPP registration state changed (home -> idle) info 2021-11-30T05:05:48+00:00 : [modem0] state changed (registered -> enabled) info 2021-11-30T05:05:48+00:00 : [modem0] 3GPP registration state changed (idle -> unknown) warning 2021-11-30T05:05:48+00:00 : [modem0] couldn't load operator code: Current operator MCC/MNC is still unknown warning 2021-11-30T05:05:48+00:00 : [modem0] couldn't load operator name: Current operator id is still unknown Any idea how this behaviour can be prevented? As I said before, in MBIM this problem is not observed and -simple-connect only exits after timeout (or successfully connects within timeout) Please advise. Amol # mmcli -m 0 -- General | path: /org/freedesktop/ModemManager1/Modem/0 | device id: c3e7a33989113dbfd81acfae3c4e31fdc86fcae6 -- Hardware | manufacturer: Telit | model: LN920A12-WW | firmware revision: M0L.00-B013 | carrier config: default | h/w revision: 0.10 | supported: gsm-umts, lte |current: gsm-umts, lte | equipment id: 354175759991310 -- System | device: /sys/devices/platform/soc/soc:internal-regs/f10f.usb3/usb3/3-1 |drivers: option1, qmi_wwan | plugin: telit | primary port: cdc-wdm0 | ports: cdc-wdm0 (qmi), ttyUSB0 (ignored), ttyUSB1 (gps), | ttyUSB2 (at), ttyUSB3 (at), ttyUSB4 (ignored), wwan0 (net) -- Numbers |own: 9108813566 -- Status | lock: sim-pin2 | unlock retries: sim-pin (3), sim-pin2 (3), sim-puk (10), sim-puk2 (10) | state: connected |power state: on |access tech: lte | signal quality: 96% (recent) -- Modes| supported: allowed: 3g; preferred: none | allowed: 4g; preferred: none | allowed: 3g, 4g; preferred: 4g | allowed: 3g, 4g; preferred: 3g |current: allowed: 4g; preferred: none -- Bands| supported: utran-1, utran-3, utran-4, utran-6, utran-5, utran-8,
