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,
Re: Lenovo/Foxconn Snapdragon X55 connection issues w/ newer firmware versions
On Sun, Nov 28, 2021 at 9:09 PM Aleksander Morgado wrote: > So it may really be that they've changed the unlock method already :/ > Are you able to flash back v48, or is the downgrade path not possible? > Fortunately, I can downgrade (via a Windows installation I have on a USB disk). > My firmware version in the SDX55 I have is T99W175.F0.0.0.5.8.TF.007. > > Could you run this just to confirm? > $ sudo qmicli -d /dev/wwan0mbim0 -p --dms-foxconn-set-fcc-authentication=0 > -v > That seems unsuccessful: error: couldn't run Foxconn FCC authentication: QMI protocol error (17): 'MissingArgument' Complete output attached. > Regarding the lenovo-wwan-dpr in https://snapcraft.io/lenovo-wwan-dpr, > does it help to unlock the module in the newer firmware versions? > Nope, unfortunately not, it apparently refuses to do its work: 2021-11-30T00:03:10+01:00 DPR_wwan[4779]: get_product(): WWAN DPR functionality is not supported in this product When I have a look at the decompiled DPR_wwan binary from the snap, they seem to have a product whitelist that does not include the X1E4. If the whitelist wasn't in place, they'd invoke some binary (the name of which I can't seem to figure out due to obfuscation or compiler optimization) with a --dms-set-bios-lock flag. I will leave v51 in place in case there is anything I can do to debug the situation. I may need some guidance, though. Regards, Thilo [29 Nov 2021, 23:56:33] [Debug] [/dev/wwan0mbim0] Opening device with flags 'proxy, auto'... [29 Nov 2021, 23:56:33] [Debug] [/dev/wwan0mbim0] automatically selecting MBIM mode [29 Nov 2021, 23:56:33] [Debug] [/dev/wwan0mbim0] created endpoint [29 Nov 2021, 23:56:33] [Debug] [/dev/wwan0mbim0] creating MBIM device... [29 Nov 2021, 23:56:33] [Debug] [/dev/wwan0mbim0] MBIM device created [29 Nov 2021, 23:56:33] [Debug] [/dev/wwan0mbim0] opening MBIM device... [29 Nov 2021, 23:56:33] [Debug] opening device... [29 Nov 2021, 23:56:33] [Debug] [/dev/wwan0mbim0] Couldn't find descriptors file, possibly not using cdc_mbim [29 Nov 2021, 23:56:33] [Debug] [/dev/wwan0mbim0] Fallback to default max control message size: 4096 [29 Nov 2021, 23:56:33] [Debug] [/dev/wwan0mbim0] Sent message... << RAW: << length = 92 << data = 03:00:00:00:5C:00:00:00:01:00:00:00:01:00:00:00:00:00:00:00:83:8C:F7:FB:8D:0D:4D:7F:87:1E:D7:1D:BE:FB:B3:9B:01:00:00:00:01:00:00:00:2C:00:00:00:0C:00:00:00:1E:00:00:00:05:00:00:00:2F:00:64:00:65:00:76:00:2F:00:77:00:77:00:61:00:6E:00:30:00:6D:00:62:00:69:00:6D:00:30:00:00:00 [29 Nov 2021, 23:56:33] [Debug] [/dev/wwan0mbim0] Sent message (translated)... << Header: << length = 92 << type= command (0x0003) << transaction = 1 << Fragment header: << total = 1 << current = 0 << Contents: << service = 'proxy-control' (838cf7fb-8d0d-4d7f-871e-d71dbefbb39b) << cid = 'configuration' (0x0001) << type= 'set' (0x0001) << Fields: << DevicePath = '/dev/wwan0mbim0' << Timeout = '5' [29 Nov 2021, 23:56:33] [Debug] [/dev/wwan0mbim0] Received message... >> RAW: >> length = 48 >> data = 03:00:00:80:30:00:00:00:01:00:00:00:01:00:00:00:00:00:00:00:83:8C:F7:FB:8D:0D:4D:7F:87:1E:D7:1D:BE:FB:B3:9B:01:00:00:00:00:00:00:00:00:00:00:00 [29 Nov 2021, 23:56:33] [Debug] [/dev/wwan0mbim0] Received message (translated)... >> Header: >> length = 48 >> type= command-done (0x8003) >> transaction = 1 >> Fragment header: >> total = 1 >> current = 0 >> Contents: >> status error = 'None' (0x) >> service = 'proxy-control' (838cf7fb-8d0d-4d7f-871e-d71dbefbb39b) >> cid = 'configuration' (0x0001) [29 Nov 2021, 23:56:33] [Debug] [/dev/wwan0mbim0] Sent message... << RAW: << length = 16 << data = 01:00:00:00:10:00:00:00:02:00:00:00:00:10:00:00 [29 Nov 2021, 23:56:33] [Debug] [/dev/wwan0mbim0] Sent message (translated)... << Header: << length = 16 << type= open (0x0001) << transaction = 2 << Contents: << max control transfer = 4096 [29 Nov 2021, 23:56:33] [Debug] [/dev/wwan0mbim0] Received message... >> RAW: >> length = 16 >> data = 01:00:00:80:10:00:00:00:02:00:00:00:00:00:00:00 [29 Nov 2021, 23:56:33] [Debug] [/dev/wwan0mbim0] MBIM device open [29 Nov 2021, 23:56:33] [Debug] [/dev/wwan0mbim0] Enabling QMI indications via MBIM... [29 Nov 2021, 23:56:33] [Debug] [/dev/wwan0mbim0] Sent message... << RAW: << length = 84 << data = 03:00:00:00:54:00:00:00:03:00:00:00:01:00:00:00:00:00:00:00:A2:89:CC:33:BC:BB:8B:4F:B6:B0:13:3E:C2:AA:E6:DF:13:00:00:00:01:00:00:00:24:00:00:00:01:00:00:00:0C:00:00:00:18:00:00:00:D1:A3:0B:C2:F9:7A:6E:43:BF:65:C7:E2:4F:B0:F0:D3:01:00:00:00:01:00:00:00 [29 Nov 2021, 23:56:33] [Debug] [/dev/wwan0mbim0] Sent message (translated)... << Header: << length = 84 <<
Re: ANN: ModemManager 1.18.4 released
On Mon, 2021-11-29 at 10:52 -0500, Peter Naulls wrote: > On 11/26/21 4:52 AM, Aleksander Morgado wrote: > > Hey hey, > > > > This is the second bugfix release in the 1.18.x series, built from > > the mm-1-18 > > branch. > > > > Thanks! > > I've been chasing, as I mentioned a while ago, where "sometimes" the > modem > connection will be brought up as PPP, not qmi. This kind of > connection fails > in our setup for a bunch of reasons, and is not desirable. > > I know that PPP is woven into ModemManager for several reasons, and > building > without is some work - I've seen several prior discussions on this > topic. > > I'm using a custom version of OpenWrt which is approximately the > current > release. I've mitigated the problem somewhat by removing the PPP > connection > scripts (/lib/netif/ppp*), which helps a little. I'm using > ModemManager > 1.18.2 presently, which seems to work pretty well against kernel > 4.14.256. > Some versions of the kernel (perhaps due to timing or whatever) seem > to > trigger the problem more often, although it's hard to confirm that > one > way or another. > > The QMI driver I have is highly customized, and may well be the root > of the > problem - recent kernels seem to have some validation around USB > devices > and whatnot. > > In any case, I tested 1.18.4 today, and 100% of the time the > connection > now comes up in PPP. It's not clear from the changes why this might > now happen - perhaps there's extra validation or something. But I'd > really like to get to the bottom of this - any suggestions in the > current > changes that I should look at? Do you have debug logs from MM? At the very least MM has to find a netdevice for the modem, otherwise it would fall back to an available AT port for PPP. Does MM find one? Dan
Re: ANN: ModemManager 1.18.4 released
On 11/26/21 4:52 AM, Aleksander Morgado wrote: Hey hey, This is the second bugfix release in the 1.18.x series, built from the mm-1-18 branch. Thanks! I've been chasing, as I mentioned a while ago, where "sometimes" the modem connection will be brought up as PPP, not qmi. This kind of connection fails in our setup for a bunch of reasons, and is not desirable. I know that PPP is woven into ModemManager for several reasons, and building without is some work - I've seen several prior discussions on this topic. I'm using a custom version of OpenWrt which is approximately the current release. I've mitigated the problem somewhat by removing the PPP connection scripts (/lib/netif/ppp*), which helps a little. I'm using ModemManager 1.18.2 presently, which seems to work pretty well against kernel 4.14.256. Some versions of the kernel (perhaps due to timing or whatever) seem to trigger the problem more often, although it's hard to confirm that one way or another. The QMI driver I have is highly customized, and may well be the root of the problem - recent kernels seem to have some validation around USB devices and whatnot. In any case, I tested 1.18.4 today, and 100% of the time the connection now comes up in PPP. It's not clear from the changes why this might now happen - perhaps there's extra validation or something. But I'd really like to get to the bottom of this - any suggestions in the current changes that I should look at? Thanks again.
