Aw: Re: Unable to set preferred mode to 4G from ModemManager for Quectel BG96
Hi Alkesander, Thanks for the advice. Attached are my log files from MM and qmi-proxy. This time when I set the preferred mode to 2G via MM, the sequence from AT-cmd did not change (first 4G then 2G). And after setting to 4G, the sequence from modem changed to: first 2G then 4G. See my test sequence below. # mmcli -m 0 --set-allowed-modes='2g|4g' --set-preferred-mode='2g' successfully set current modes in the modem # mmcli -m 0 --command="AT+QCFG=\"nwscanseq\"" response: '+QCFG: "nwscanseq",020301' # mmcli -m 0 --set-allowed-modes='2g|4g' --set-preferred-mode='4g' successfully set current modes in the modem # mmcli -m 0 --command="AT+QCFG=\"nwscanseq\"" response: '+QCFG: "nwscanseq",010203' Usually only "set-preferred-mode='4g'" does not work for me. Maybe this is a speical test run. if you need logs from NetworkManager or from other test runs, just let me know and I will do more tests and send the logs. Thanks, Songwei Gesendet: Mittwoch, 01. Dezember 2021 um 11:16 Uhr Von: "Aleksander Morgado" An: songwei...@web.de Cc: "ModemManager (development)" Betreff: Re: Unable to set preferred mode to 4G from ModemManager for Quectel BG96 Hey, > 2. Then I set the priority to 2G. Both MM and AT-cmd shows the 2G has now priority. > > # mmcli -m 1 --set-allowed-modes='2g|4g' --set-preferred-mode='2g' > successfully set current modes in the modem > # > # mmcli -m 1 --command="AT+QCFG=\"nwscanseq\"" > response: '+QCFG: "nwscanseq",010203' > > 3. Then I wanted to set the priority to 4G again. But could not do it with MM. AT comamnd shows the search sequence does not change. But the MM "thinks" the priority is already set back to 4G. > > # mmcli -m 1 --set-allowed-modes='2g|4g' --set-preferred-mode='4g' > successfully set current modes in the modem > # > # > # mmcli -m 1 --command="AT+QCFG=\"nwscanseq\"" > response: '+QCFG: "nwscanseq",010203' > We need to see what kind of QMI responses we get from the modem, maybe there is something we're not processing right. Could you please retry this sequence but with debugging enabled? see https://modemmanager.org/docs/modemmanager/debugging/ -- Aleksander https://aleksander.es ModemManager[2138]: [1638396501.096660] Periodic signal check refresh requested ModemManager[2138]: [1638396501.097207] loading signal quality... ModemManager[2138]: [/dev/cdc-wdm0] sent message... << RAW: << length = 13 << data = 01:0C:00:00:03:03:00:0E:00:20:00:00:00 ModemManager[2138]: [/dev/cdc-wdm0] sent generic request (translated)... << QMUX: << length = 12 << flags = 0x00 << service = "nas" << client = 3 << QMI: << flags = "none" << transaction = 14 << tlv_length = 0 << message = "Get Signal Strength" (0x0020) ModemManager[2138]: [/dev/cdc-wdm0] received message... << RAW: << length = 25 << data = 01:18:00:80:03:03:02:0E:00:20:00:0C:00:02:04:00:00:00:00:00:01:02:00:B5:04 ModemManager[2138]: [/dev/cdc-wdm0] received generic response (translated)... << QMUX: << length = 24 << flags = 0x80 << service = "nas" << client = 3 << QMI: << flags = "response" << transaction = 14 << tlv_length = 12 << message = "Get Signal Strength" (0x0020) << TLV: << type = "Result" (0x02) << length = 4 << value = 00:00:00:00 << translated = SUCCESS << TLV: << type = "Signal Strength" (0x01) << length = 2 << value = B5:04 << translated = [ strength = '-75' radio_interface = 'gsm' ] ModemManager[2138]: [1638396501.136095] Signal strength (gsm): -75 dBm ModemManager[2138]: [1638396501.136409] Signal strength: -75 dBm --> 62% ModemManager[2138]: [1638396501.137125] Modem /org/freedesktop/ModemManager1/Modem/0: signal quality updated (62) ModemManager[2138]: [1638396501.137558] Periodic signal quality and access technology checks scheduled ModemManager[2138]: [/dev/cdc-wdm0] sent message... << RAW: << length = 20 << data = 01:13:00:00:01:03:00:08:00:24:00:07:00:01:04:00:C0:00:00:00 ModemManager[2138]: [/dev/cdc-wdm0] sent generic request (translated)... << QMUX: << length = 19 << flags = 0x00 << service = "wds" << client = 3 << QMI: << flags = "none" << transaction = 8 << tlv_length = 7 << message = "Get Packet Statistics" (0x0024) << TLV: << type = "Mask" (0x01) << length = 4 << value = C0:00:00:00 << translated = tx-bytes-ok, rx-bytes-ok ModemManager[2138]: [/dev/cdc-wdm0] received message... << RAW: << length = 42 << data = 01:29:00:80:01:03:02:08:00:24:00:1D:00:02:04:00:00:00:00:00:19:08:00:D2:00:00:00:00:00:00:00:1A:08:00:00:00:00:00:00:00:00:00 ModemManager[2138]: [/dev/cdc-wdm0] received generic response (translated)... << QMUX: << length = 41 <<
Re: ANN: ModemManager 1.18.4 released
Hey Peter, > > > Wondering, would you be able to also test 1.18.4 but with these 2 > > > changes reverted? The regex related fix was a big one, maybe it broke > > > something else. > > > > > > 2beae71a6 kerneldevice,generic: simplify DEVPATH matching logic > > > 1bd70df8a kerneldevice,generic: input pattern to string match is not regex > > > > > > If you could get debug logs for both tests, that would be best > > > > It doesn't work with only the newer patch reversed, but with both it does. > > Both > > logs, respectively below. > > > > Thanks for testing this; I'll try to give it a run myself and see if I > can reproduce the problem. > Could you please test the following single patch on top of 1.18.4? https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/700 -- Aleksander https://aleksander.es
Re: ANN: ModemManager 1.18.4 released
Hey Peter, > > Wondering, would you be able to also test 1.18.4 but with these 2 > > changes reverted? The regex related fix was a big one, maybe it broke > > something else. > > > > 2beae71a6 kerneldevice,generic: simplify DEVPATH matching logic > > 1bd70df8a kerneldevice,generic: input pattern to string match is not regex > > > > If you could get debug logs for both tests, that would be best > > It doesn't work with only the newer patch reversed, but with both it does. > Both > logs, respectively below. > Thanks for testing this; I'll try to give it a run myself and see if I can reproduce the problem. -- Aleksander https://aleksander.es
Re: ANN: ModemManager 1.18.4 released
On 12/1/21 5:11 AM, Aleksander Morgado wrote: Hey Peter Wondering, would you be able to also test 1.18.4 but with these 2 changes reverted? The regex related fix was a big one, maybe it broke something else. 2beae71a6 kerneldevice,generic: simplify DEVPATH matching logic 1bd70df8a kerneldevice,generic: input pattern to string match is not regex If you could get debug logs for both tests, that would be best It doesn't work with only the newer patch reversed, but with both it does. Both logs, respectively below. I'm just using syslog output here; if you need me to run on command line or whatever to get different debug, let me know. Mon Nov 29 15:40:56 2021 user.notice ModemManager: hotplug: add network interface ip6tnl0: event processed Mon Nov 29 15:40:56 2021 user.notice ModemManager: hotplug: error: parent device sysfspath not found Mon Nov 29 15:40:56 2021 user.notice ModemManager: hotplug: add network interface gre0: event processed Mon Nov 29 15:40:56 2021 user.notice : Added device handler type: bonding Mon Nov 29 15:40:56 2021 user.notice : Added device handler type: 8021ad Mon Nov 29 15:40:56 2021 user.notice : Added device handler type: 8021q Mon Nov 29 15:40:56 2021 user.notice : Added device handler type: macvlan Mon Nov 29 15:40:56 2021 user.notice : Added device handler type: veth Mon Nov 29 15:40:56 2021 user.notice : Added device handler type: bridge Mon Nov 29 15:40:56 2021 user.notice : Added device handler type: Network device Mon Nov 29 15:40:56 2021 user.notice : Added device handler type: tunnel Mon Nov 29 15:40:56 2021 user.notice ModemManager: hotplug: error: parent device sysfspath not found Mon Nov 29 15:40:57 2021 user.notice ModemManager: hotplug: add network interface gretap0: event processed Mon Nov 29 15:40:57 2021 user.notice ModemManager: hotplug: error: parent device sysfspath not found Mon Nov 29 15:40:58 2021 user.notice ModemManager: hotplug: add network interface erspan0: event processed Mon Nov 29 15:40:58 2021 user.notice ModemManager: hotplug: error: parent device sysfspath not found Mon Nov 29 15:40:59 2021 daemon.notice netifd: Interface 'lan' is enabled Mon Nov 29 15:40:59 2021 daemon.notice netifd: Interface 'lan' is setting up now Mon Nov 29 15:40:59 2021 daemon.notice netifd: Interface 'lan' is now up Mon Nov 29 15:40:59 2021 daemon.notice netifd: bridge 'br-lan' link is up Mon Nov 29 15:40:59 2021 daemon.notice netifd: Interface 'lan' has link connectivity Mon Nov 29 15:40:59 2021 daemon.notice netifd: VLAN 'eth0.1' link is up Mon Nov 29 15:40:59 2021 daemon.notice netifd: Interface 'loopback' is enabled Mon Nov 29 15:40:59 2021 daemon.notice netifd: Interface 'loopback' is setting up now Mon Nov 29 15:40:59 2021 daemon.notice netifd: Interface 'loopback' is now up Mon Nov 29 15:40:59 2021 daemon.notice netifd: Interface 'wwan' is setting up now Mon Nov 29 15:40:59 2021 daemon.notice netifd: Network device 'eth0' link is up Mon Nov 29 15:40:59 2021 daemon.notice netifd: Network device 'lo' link is up Mon Nov 29 15:40:59 2021 daemon.notice netifd: Interface 'loopback' has link connectivity Mon Nov 29 15:40:59 2021 user.notice ModemManager: hotplug: add network interface ip6gre0: event processed Mon Nov 29 15:40:59 2021 daemon.notice netifd: wwan (2493): error: couldn't get bus: Could not connect: No such file or directory Mon Nov 29 15:40:59 2021 daemon.notice netifd: wwan (2493): Device not managed by ModemManager Mon Nov 29 15:40:59 2021 user.notice ModemManager: hotplug: error: parent device sysfspath not found Mon Nov 29 15:40:59 2021 daemon.notice netifd: wwan (2531): stopping network Mon Nov 29 15:40:59 2021 user.notice firewall: Reloading firewall due to ifup of lan (br-lan) Mon Nov 29 15:40:59 2021 daemon.notice netifd: wwan (2531): error: couldn't find the ModemManager process in the bus Mon Nov 29 15:40:59 2021 daemon.notice netifd: wwan (2531): couldn't load bearer path Mon Nov 29 15:40:59 2021 daemon.notice netifd: Interface 'wwan' is now down Mon Nov 29 15:40:59 2021 daemon.err procd: failed to open pidfile for writing: : No such file or directory Mon Nov 29 15:41:00 2021 user.notice ModemManager: hotplug: add network interface wwan0: event processed Mon Nov 29 15:41:00 2021 user.notice ModemManager: hotplug: interface 'wwan' is set to configure device '/sys/devices/platform/1e1c.xhci/usb2/2-1' Mon Nov 29 15:41:00 2021 user.notice ModemManager: hotplug: now waiting for modem at sysfs path /sys/devices/platform/1e1c.xhci/usb2/2-1 Mon Nov 29 15:41:00 2021 user.notice ModemManager: hotplug: add cdc interface cdc-wdm0: custom event processed Mon Nov 29 15:41:00 2021 user.notice ucitrack: Setting up /etc/config/network reload dependency on /etc/config/dhcp Mon Nov 29 15:41:00 2021 user.notice ucitrack: Setting up /etc/config/wireless reload dependency on /etc/config/network Mon Nov 29 15:41:00 2021 daemon.err odhcpd[2086]: Failed to send to ff02::1%lan@br-lan (Address not available) Mon Nov 29
Re: Unable to set preferred mode to 4G from ModemManager for Quectel BG96
Hey, > 2. Then I set the priority to 2G. Both MM and AT-cmd shows the 2G has now > priority. > > # mmcli -m 1 --set-allowed-modes='2g|4g' --set-preferred-mode='2g' > successfully set current modes in the modem > # > # mmcli -m 1 --command="AT+QCFG=\"nwscanseq\"" > response: '+QCFG: "nwscanseq",010203' > > 3. Then I wanted to set the priority to 4G again. But could not do it with > MM. AT comamnd shows the search sequence does not change. But the MM "thinks" > the priority is already set back to 4G. > > # mmcli -m 1 --set-allowed-modes='2g|4g' --set-preferred-mode='4g' > successfully set current modes in the modem > # > # > # mmcli -m 1 --command="AT+QCFG=\"nwscanseq\"" > response: '+QCFG: "nwscanseq",010203' > We need to see what kind of QMI responses we get from the modem, maybe there is something we're not processing right. Could you please retry this sequence but with debugging enabled? see https://modemmanager.org/docs/modemmanager/debugging/ -- Aleksander https://aleksander.es
Re: Can't connect using ModemManager when modem is in QMI mode
Hey Jeff, > I'm running a Sierra Wireless MC7455 modem with SWI9X30C_02.32.11.00 r8042 > CARMD-EV-FRMWR2 firmware. Using ModemManager 1.18.2 on Ubuntu 20.04. > > I can get the modem to connect using mmcli -m 0 --simple-connect=. when the > modem is in MBIM mode. > I can get the modem to connect using qmicli and qmi-network when the modem is > in QMI mode. > > But when I use mmcli with ModemManager, --simple-connect fails with > > error: couldn't connect the modem: > 'GDBus.Error:org.freedesktop.ModemManager1.Error.Core.Cancelled: operation > cancelled' > Oh, that is very strange. > What is strange is that the modem seems to create a default bearer channel > when it is enabled. Using simple-connect seems to create a second bearer > channel which is rejected. But using -connect on the default bearer channel > also fails. > The default bearer when enabled is the "initial EPS default bearer". In ModemManager, this is an informative bearer object exclusively, you cannot use it to trigger a connection. When simple connect creates the new bearer, that's the one that should end up connected. > > Using simple connect results in two bearers. > > root@de-01:~# mmcli -m 1 --simple-connect='apn=broadband' > error: couldn't connect the modem: > 'GDBus.Error:org.freedesktop.ModemManager1.Error.Core.Cancelled: operation > cancelled' This is what we need to understand. Could you gather MM daemon debug logs while you attempt this simple-connect operation? https://modemmanager.org/docs/modemmanager/debugging/ -- Aleksander https://aleksander.es
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
