Re: Inhibit example
I got it working eventually but it took a while. I'd suggest you make it easier in the documentation to figure out where parameters come from. For instance, mm_object_get_modem() takes an MMObject parameter: https://www.freedesktop.org/software/ModemManager/libmm-glib/libmm-glib/MMObject.html#mm-object-get-modem But if you click on MMObject there's no explanation as to how to create it: https://www.freedesktop.org/software/ModemManager/libmm-glib/libmm-glib/MMObject.html I eventually copied find_modem() from https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/blob/main/cli/mmcli-common.c#L193 On Mon, Nov 28, 2022 at 11:20 PM Aleksander Morgado wrote: > > Hey Tom, > > > I've got an existing application that uses AT commands to setup a > > modem then qmicli to setup the data connection. For various reasons > > I'm trying to move to use ModemManager instead. My problem is that in > > order to keep the AT commands for setup I need to stop ModemManager > > for a bit. > > > > A previous email here said you can use the inhibit function but I'm > > having trouble figuring out how to use mm_manager_inhibit_device() > > because there are too many layers in the code. For instance, it takes > > a MManager pointer that comes from mmcli_get_modem_sync() but that's > > not in mm-glib. Is there a relatively simple example that shows how to > > do an inhibit/uninhibit so we can do setup? > > > > If using libmm-glib, you would roughly need: > > 1. Create a MMManager, e.g. with > mm_manager_new()/mm_manager_new_finish() --> > https://www.freedesktop.org/software/ModemManager/doc/latest/libmm-glib/MMManager.html#mm-manager-new > 2. Call mm_manager_inhibit_device() --> > https://www.freedesktop.org/software/ModemManager/doc/latest/libmm-glib/MMManager.html#mm-manager-inhibit-device > > Both calls have their sync counterparts as well, but you anyway > require a GLib main loop running. > > The mm_manager_inhibit_device() call takes a modem "uid" which is > basically the string exposed in the "Device" field in mmcli -m 0. This > is usually the sysfs path of the modem, or a custom name you may have > given to it with the ID_MM_PHYSDEV_UID udev tag. > > The method you're pointing out, mmcli_get_modem_sync(), is an > implementation done inside the mmcli sources to get a Modem object > from the MMManager object. mmcli is also using libmm-glib. > > -- > Aleksander -- Tom Isaacson
Re: Telit FN990: All supported/current modes not reported (MM 1.20.2)
> > Attaching full log and relevant portion seems below. No it's not > > regression. I just loaded 1.20.2 mainly for 5g support. > > > > I've got a bunch of changes fixing this and adding modes retrieval > through QMI (which makes more sense than using AT commands when > available), just need to find the time to polish and submit... > Great! thanks for letting us know -- Aleksander
Re: Telit FN990: All supported/current modes not reported (MM 1.20.2)
Hi Amol and Aleksander, Il giorno lun 28 nov 2022 alle ore 12:19 Amol Lad ha scritto: > > Attaching full log and relevant portion seems below. No it's not regression. > I just loaded 1.20.2 mainly for 5g support. > I've got a bunch of changes fixing this and adding modes retrieval through QMI (which makes more sense than using AT commands when available), just need to find the time to polish and submit... Regards, Daniele > == > [1669633765.148778] [modem0] no carrier config currently selected > (default in use) > [1669633765.149038] [modem0] device identifier built: > 1bc7107135917239176FN990TelitWirelessSolutions -> > d04794b2e195986e2087001f45f6a4b81d1e3f16 > [1669633765.149153] [ttyUSB2/at] device open count is 2 (open) > [1669633765.149226] [ttyUSB2/at] --> 'AT+WS46=?' > [1669633765.163992] [ttyUSB2/at] <-- '+WS46: > (22,28,31,36-38,40)OK' > [1669633765.164170] [modem0] (shared-telit) device allows (3GPP) mode > combination: 3g > [1669633765.164198] [modem0] (shared-telit) device allows (3GPP) mode > combination: 4g > [1669633765.164230] [modem0] (shared-telit) device allows (3GPP) mode > combination: 3g, 4g > [1669633765.164253] [modem0] (shared-telit) device allows (3GPP) mode > combination: 5g > [1669633765.164281] [modem0] (shared-telit) device allows (3GPP) mode > combination: 4g, 5g > [1669633765.164312] [modem0] (shared-telit) device allows (3GPP) mode > combination: 3g, 4g, 5g > [1669633765.164341] [modem0] (shared-telit) device allows (3GPP) mode > combination: 3g, 5g > [1669633765.164366] [modem0] filtering 7 supported mode combinations > with 1 modes > [1669633765.164390] [modem0] device supports 3 different mode > combinations > === > [1669633765.212244] [ttyUSB2/at] device open count is 2 (open) > [1669633765.212331] [ttyUSB2/at] --> 'AT+WS46?' > [1669633765.225404] [ttyUSB2/at] <-- '+WS46: > 37OK' > [1669633765.225529] [modem0] couldn't load current allowed/preferred > modes: Couldn't parse unexpected +WS46 response: '+WS46: 37' > > From the FN990 AT command guide: > AT+WS46=[] > integer 38 WDS-Side Stack to be used by the TA. > Values: > 22 : UTRAN only > 28 : E-UTRAN only > 31 : UTRAN and E-UTRAN > 36 : NG-RAN only > 37 : NG-RAN and E-UTRAN > 38 : NG-RAN, E-UTRAN and UTRAN > 40 : NG-RAN and UTRAN > > > From: Aleksander Morgado > Sent: Monday, November 28, 2022 4:03 PM > To: Amol Lad > Cc: Daniele Palmas ; ModemManager (development) > > Subject: Re: Telit FN990: All supported/current modes not reported (MM 1.20.2) > > Hey, > > > > > I'm trying Telit FN990 with MM 1.20.2 release and "supported" and "current" > > modes always report "4g" in MBIM mode. I believe it's reported correctly in > > QMI. It seems not all +WS46 combinations are supported in MBIM. > > > > Modes | supported: allowed: 4g; preferred: none > > |current: allowed: 4g; preferred: none > > > > Could you please run MM with debug logs to see what the modem is replying? > > Also, just to confirm, this is not a regression, right? > > -- > Aleksander > > The information in this email communication (inclusive of attachments) is > confidential to 4RF Limited and the intended recipient(s). If you are not the > intended recipient(s), please note that any use, disclosure, distribution or > copying of this information or any part thereof is strictly prohibited and > that the author accepts no liability for the consequences of any action taken > on the basis of the information provided. If you have received this email in > error, please notify the sender immediately by return email and then delete > all instances of this email from your system. 4RF Limited will not accept > responsibility for any consequences associated with the use of this email > (including, but not limited to, damages sustained as a result of any viruses > and/or any action or lack of action taken in reliance on it).
Re: Telit FN990: All supported/current modes not reported (MM 1.20.2)
Hey, > > I'm trying Telit FN990 with MM 1.20.2 release and "supported" and "current" > modes always report "4g" in MBIM mode. I believe it's reported correctly in > QMI. It seems not all +WS46 combinations are supported in MBIM. > > Modes | supported: allowed: 4g; preferred: none > |current: allowed: 4g; preferred: none > Could you please run MM with debug logs to see what the modem is replying? Also, just to confirm, this is not a regression, right? -- Aleksander
Re: ModemManager and d-bus permissions in OpenWrt
Hey! > > This is really an OpenWrt question, but I wanted to understand the specifics > with MM. We're undergoing a security review, and it's been pointed out that > d-bus runs as non-root. I've created a new "dbus" user and group like ubus > has and have d-bus run under it as per its config file. > You mean in your openwrt setup, d-bus is running as non-root, right? Or is it a generic openwrt thing? I truly don't know what's the default. > Everything seems OK with MM, and indeed I think this is the only user of > it under my OpenWrt setup, hence the question here. > > Is this likely to break anything? If MM is the only user of the DBus system bus you're probably fine. I'd assume that the dbus-daemon may require extra privileges if e.g. it needs to do DBus activation of services, but that is not the case in your setup. -- Aleksander
Telit FN990: All supported/current modes not reported (MM 1.20.2)
Hi Daniele, I'm trying Telit FN990 with MM 1.20.2 release and "supported" and "current" modes always report "4g" in MBIM mode. I believe it's reported correctly in QMI. It seems not all +WS46 combinations are supported in MBIM. Modes | supported: allowed: 4g; preferred: none |current: allowed: 4g; preferred: none Any suggestions? Thanks Amol root@AprisaLTE:/opt/conf# mmcli -m 0 --- General | path: /org/freedesktop/ModemManager1/Modem/0 | device id: 7b4287e8b63ca38658b141592a754cc901670808 --- Hardware | manufacturer: Telit Wireless Solutions | model: FN990 | carrier config: default | h/w revision: FN990A40 | supported: gsm-umts, lte, 5gnr |current: gsm-umts, lte, 5gnr | equipment id: 35917239192 --- System| device: /sys/devices/platform/soc/soc:internal-regs/f10f.usb3/usb3/3-1 |drivers: option1, cdc_mbim | plugin: telit | primary port: cdc-wdm0 | ports: cdc-wdm0 (mbim), ttyUSB0 (ignored), ttyUSB1 (ignored), | ttyUSB2 (at), ttyUSB3 (at), ttyUSB4 (ignored), wwan0 (net) --- Status| lock: sim-pin2 | unlock retries: sim-pin2 (3) | state: connected |power state: on |access tech: lte, 5gnr | signal quality: 48% (recent) --- Modes | supported: allowed: 4g; preferred: none |current: allowed: 4g; preferred: none --- Bands | supported: utran-1, utran-4, utran-6, utran-5, utran-8, utran-2, | eutran-1, eutran-2, eutran-3, eutran-4, eutran-5, eutran-7, eutran-8, | eutran-12, eutran-13, eutran-14, eutran-17, eutran-18, eutran-19, | eutran-20, eutran-25, eutran-26, eutran-28, eutran-29, eutran-30, | eutran-32, eutran-34, eutran-38, eutran-39, eutran-40, eutran-41, | eutran-42, eutran-43, eutran-46, eutran-48, eutran-66, eutran-71, | utran-19, ngran-1, ngran-2, ngran-3, ngran-5, ngran-7, ngran-8, | ngran-20, ngran-25, ngran-28, ngran-30, ngran-38, ngran-40, ngran-41, | ngran-48, ngran-66, ngran-71, ngran-75, ngran-77, ngran-78, ngran-79 |current: eutran-1, eutran-2, eutran-3, eutran-4, eutran-5, eutran-7, | eutran-8, eutran-12, eutran-13, eutran-14, eutran-18, eutran-19, | eutran-20, eutran-25, eutran-26, eutran-28, eutran-29, eutran-30, | eutran-32, eutran-34, eutran-38, eutran-39, eutran-40, eutran-41, | eutran-42, eutran-43, eutran-46, eutran-48, eutran-66, eutran-71, | ngran-1, ngran-2, ngran-3, ngran-5, ngran-7, ngran-8, ngran-20, | ngran-25, ngran-28, ngran-30, ngran-38, ngran-40, ngran-41, ngran-48, | ngran-66, ngran-71, ngran-75, ngran-77, ngran-78, ngran-79 --- IP| supported: ipv4, ipv6, ipv4v6 --- 3GPP | imei: 35917239192 | enabled locks: fixed-dialing |operator id: 53001 | operator name: vodafone NZ | registration: home | packet service state: attached |pco: 0: (partial) '27048000' --- 3GPP EPS | ue mode of operation: csps-2 |initial bearer path: /org/freedesktop/ModemManager1/Bearer/0 | initial bearer apn: internet | initial bearer ip type: ipv4 --- 3GPP 5GNR | mico mode: unsupported | drx cycle: unsupported --- SIM | primary sim path: /org/freedesktop/ModemManager1/SIM/0 | sim slot paths: slot 1: /org/freedesktop/ModemManager1/SIM/0 (active) | slot 2: none ---
Re: Upgrade from 1.18 to 1.21.1 causes change in behavior
Hey, > > I am working with an mPCI Telit LE910C4 modem connected to a Linux System on > a Chip running Ubunut 20.04. > > With 1.18 ModemManager installed I noticed that serial ports were being > listed as ignored except for a GPS port was available through a tty, this > meant I couldnt issue AT commands. I also needed bit error rate from the > mmlib-glib API so I decided to build ModemManager 1,21. > > Upon upgrading the modem no longer recognizes as a qmi device, but the AT > command tty terminals are available. I was hoping for some advice on how to > investigate this behavior. I did not build libqmi from source because > whenever I try to compile on the device compilation freezes (overnight) on > compiling certain *.o files. However, I am able to get the modem connected. > > Any advice on how to debug why the modem is no longer being recognized as a > qmi device? I'm a bit confused, you built MM 1.21 but you didn't build the corresponding libqmi? If so, it looks like you built MM without QMI support, and that is the reason why your device isn't recognized as a QMI device. -- Aleksander
Re: DNS and MTU
Hey Tom, On Tue, Nov 22, 2022 at 9:35 AM Tom Isaacson wrote: > > I'm moving over to ModemManager / NetworkManager integration but I'm > not sure I understand how DNS and MTU are handled. > > My device has a Sierra RC7611 or RC7620 (depending on location). I'm > setting up the data connection using: > nmcli connection add type gsm ifname 'cdc-wdm0' con-name 'sierra' > connection.autoconnect yes > > That works fine for data, but I'm confused as to how DNS and MTU are > supposed to be setup. Systemd correctly sets up > /var/run/systemd/resolve/resolv.conf > with the DNS settings, but /etc/resolv.conf gets setup with: > # Generated by NetworkManager > nameserver 127.0.0.1 > > I have to delete it and setup a symbolic link to > /var/run/systemd/resolve/resolv.conf. Shouldn't Systemd take care of > this? > > Secondly, the bearer sets the MTU at 1428: > # mmcli --modem=0 --bearer=0 > > General| dbus path: /org/freedesktop/ModemManager1/Bearer/0 > | type: default > > Status | connected: yes > | suspended: no > | interface: wwan0 > | ip timeout: 20 > > Properties |apn: internet > |roaming: allowed > |ip type: ipv4v6 > > IPv4 configuration | method: static > |address: 100.95.39.213 > | prefix: 30 > |gateway: 100.95.39.214 > |dns: 198.224.183.135, 198.224.182.135 > |mtu: 1428 > > Statistics | duration: 240 > | bytes rx: 28188070 > | bytes tx: 1066621 > > But that doesn't seem to be applied automatically? Do I have to read > it then apply it myself? > I have absolutely no idea how the systemd-resolved integration works along with NetworkManager, they may be clashing. When using MM+NM, NM should take the DNS servers reported by ModemManager and apply them if the WWAN connection is the primary one. NM should also apply the MTU reported by ModemManager to the specific network interface. -- Aleksander
Re: Inhibit example
Hey Tom, > I've got an existing application that uses AT commands to setup a > modem then qmicli to setup the data connection. For various reasons > I'm trying to move to use ModemManager instead. My problem is that in > order to keep the AT commands for setup I need to stop ModemManager > for a bit. > > A previous email here said you can use the inhibit function but I'm > having trouble figuring out how to use mm_manager_inhibit_device() > because there are too many layers in the code. For instance, it takes > a MManager pointer that comes from mmcli_get_modem_sync() but that's > not in mm-glib. Is there a relatively simple example that shows how to > do an inhibit/uninhibit so we can do setup? > If using libmm-glib, you would roughly need: 1. Create a MMManager, e.g. with mm_manager_new()/mm_manager_new_finish() --> https://www.freedesktop.org/software/ModemManager/doc/latest/libmm-glib/MMManager.html#mm-manager-new 2. Call mm_manager_inhibit_device() --> https://www.freedesktop.org/software/ModemManager/doc/latest/libmm-glib/MMManager.html#mm-manager-inhibit-device Both calls have their sync counterparts as well, but you anyway require a GLib main loop running. The mm_manager_inhibit_device() call takes a modem "uid" which is basically the string exposed in the "Device" field in mmcli -m 0. This is usually the sysfs path of the modem, or a custom name you may have given to it with the ID_MM_PHYSDEV_UID udev tag. The method you're pointing out, mmcli_get_modem_sync(), is an implementation done inside the mmcli sources to get a Modem object from the MMManager object. mmcli is also using libmm-glib. -- Aleksander
Re: SIM7070G support using regular uart (not usb)
Hey Jorge > So I'm back again with my questions about the SIM7070G modem using a regular > UART instead of USB. > I have the modem fully working with a simple PPP + CHAT script, but it hangs > if I try to use ModemManager. > The problem is now I don't have much time to investigate where/why it exactly > hangs (ie: which at command delivered by ModemManager is "offending" the > modem). > > As a quick&dirty fix: Is there any way to specify a "custom" chat script to > ModemManager? > There is no such thing sorry. The way to go from here would be to gather the MM debug logs and analyze where it is not working as expected: https://modemmanager.org/docs/modemmanager/debugging/ -- Aleksander
Re: Upgrade from 1.18 to 1.21.1 causes change in behavior
I wanted to provide an additional piece of information I realized: When trying to set the initiali EPS bearer settings I get the following error from mmcli: 'GDBus.Error:org.freedesktop.ModemManager1.Error.Core.Unsupported: Operation not supported' and I also noticed that mmcli reports the following in 3gpp eps : ue mode of operation: csps-2 Im assuming this has something to do with my issue? Previously I had no problem with ModemManager 1.18 setting up the EPS bearer settings. Thanks again Sent with [Proton Mail](https://proton.me/) secure email. --- Original Message --- On Thursday, November 24th, 2022 at 9:26 AM, VT102 wrote: > Hello all, > > I am working with an mPCI Telit LE910C4 modem connected to a Linux System on > a Chip running Ubunut 20.04. > > With 1.18 ModemManager installed I noticed that serial ports were being > listed as ignored except for a GPS port was available through a tty, this > meant I couldnt issue AT commands. I also needed bit error rate from the > mmlib-glib API so I decided to build ModemManager 1,21. > > Upon upgrading the modem no longer recognizes as a qmi device, but the AT > command tty terminals are available. I was hoping for some advice on how to > investigate this behavior. I did not build libqmi from source because > whenever I try to compile on the device compilation freezes (overnight) on > compiling certain *.o files. However, I am able to get the modem connected. > > Any advice on how to debug why the modem is no longer being recognized as a > qmi device? > I am wondering if I need to change the USB configuration of the modem,but > this seems likee it would be strange, as it was interacting with the modem > via qmi previously via cdc_wdm0. > > Below I will post output from mmcli from version 1.21 with QMI not working. > > Thanks, > Rick > > > General | path: /org/freedesktop/ModemManager1/Modem/0 > | device id: > > Hardware | manufacturer: Telit > | model: LE910C4-NF > | firmware revision: 25.21.660-P0F.661806 > | supported: gsm-umts, lte > | current: gsm-umts, lte > | equipment id: > > System | device: > /sys/devices/platform/soc@0/32c0.bus/32e5.usb/ci_hdrc.1/usb1/1-1/1-1.2 > | drivers: option, qmi_wwan > | plugin: telit > | primary port: ttyUSB2 > | ports: ttyUSB0 (ignored), ttyUSB1 (gps), ttyUSB2 (at), > | ttyUSB3 (at), ttyUSB4 (ignored), wwan0 (ignored) > > Status | unlock retries: sim-pin (3), sim-puk (10), sim-pin2 (10), sim-puk2 > (10) > | state: connected > | power state: on > | access tech: lte > | signal quality: 85% (recent) > > Modes | supported: allowed: 2g; preferred: none > | allowed: 3g; preferred: none > | allowed: 2g, 3g; preferred: none > | allowed: 4g; preferred: none > | allowed: 2g, 4g; preferred: none > | allowed: 3g, 4g; preferred: none > | allowed: 2g, 3g, 4g; preferred: none > | current: allowed: 3g, 4g; preferred: none > > IP | supported: ipv4, ipv6, ipv4v6 > > 3GPP | imei: > | operator id: 310410 > | operator name: AT&T > | registration: roaming > | packet service state: attached > > 3GPP EPS | ue mode of operation: csps-2 > > SIM | primary sim path: /org/freedesktop/ModemManager1/SIM/0 > Bearer | paths: > /org/freedesktop/ModemManager1/Bearer/0 > > Sent with [Proton Mail](https://proton.me/) secure email.
Upgrade from 1.18 to 1.21.1 causes change in behavior
Hello all, I am working with an mPCI Telit LE910C4 modem connected to a Linux System on a Chip running Ubunut 20.04. With 1.18 ModemManager installed I noticed that serial ports were being listed as ignored except for a GPS port was available through a tty, this meant I couldnt issue AT commands. I also needed bit error rate from the mmlib-glib API so I decided to build ModemManager 1,21. Upon upgrading the modem no longer recognizes as a qmi device, but the AT command tty terminals are available. I was hoping for some advice on how to investigate this behavior. I did not build libqmi from source because whenever I try to compile on the device compilation freezes (overnight) on compiling certain *.o files. However, I am able to get the modem connected. Any advice on how to debug why the modem is no longer being recognized as a qmi device? I am wondering if I need to change the USB configuration of the modem,but this seems likee it would be strange, as it was interacting with the modem via qmi previously via cdc_wdm0. Below I will post output from mmcli from version 1.21 with QMI not working. Thanks, Rick General | path: /org/freedesktop/ModemManager1/Modem/0 | device id: Hardware | manufacturer: Telit | model: LE910C4-NF | firmware revision: 25.21.660-P0F.661806 | supported: gsm-umts, lte | current: gsm-umts, lte | equipment id: System | device: /sys/devices/platform/soc@0/32c0.bus/32e5.usb/ci_hdrc.1/usb1/1-1/1-1.2 | drivers: option, qmi_wwan | plugin: telit | primary port: ttyUSB2 | ports: ttyUSB0 (ignored), ttyUSB1 (gps), ttyUSB2 (at), | ttyUSB3 (at), ttyUSB4 (ignored), wwan0 (ignored) Status | unlock retries: sim-pin (3), sim-puk (10), sim-pin2 (10), sim-puk2 (10) | state: connected | power state: on | access tech: lte | signal quality: 85% (recent) Modes | supported: allowed: 2g; preferred: none | allowed: 3g; preferred: none | allowed: 2g, 3g; preferred: none | allowed: 4g; preferred: none | allowed: 2g, 4g; preferred: none | allowed: 3g, 4g; preferred: none | allowed: 2g, 3g, 4g; preferred: none | current: allowed: 3g, 4g; preferred: none IP | supported: ipv4, ipv6, ipv4v6 3GPP | imei: | operator id: 310410 | operator name: AT&T | registration: roaming | packet service state: attached 3GPP EPS | ue mode of operation: csps-2 SIM | primary sim path: /org/freedesktop/ModemManager1/SIM/0 Bearer | paths: /org/freedesktop/ModemManager1/Bearer/0 Sent with [Proton Mail](https://proton.me/) secure email.
