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
