Re: modem is unusable when removing and putting back sim card
Hey, The issue is the same as this one https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/548 And I managed to fix it by adding a small sleep in libqmi here is the patch src/libqmi-glib/qmi-device.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/libqmi-glib/qmi-device.c b/src/libqmi-glib/qmi-device.c index 69a9b448..180352c6 100644 --- a/src/libqmi-glib/qmi-device.c +++ b/src/libqmi-glib/qmi-device.c @@ -1458,6 +1458,7 @@ qmi_device_release_client (QmiDevice *self, qmi_service_get_string (service), flags_str); g_free (flags_str); + g_usleep(10); task = g_task_new (self, cancellable, callback, user_data); Seems like it takes time to release some clients on libqmi side Le ven. 22 sept. 2023 à 15:20, Aleksander Morgado a écrit : > Hey > > > I am working with ModemManager with qmi-proxy and I have a weird > behavior when I am using ModemManager with the log-level set to DEBUG like > this "ModemManager --log-level=DEBUG &" > > everything is working fine but when I use it normally or set the > log-level to anything else except debug I have "modem is unusable" > > Here are the logs : > > [modem2] cleaning up port 'net/mhi_hwip0'... > > [modem2] cleaning up port 'unknown/wwan0qcdm0'... > > [modem2] cleaning up port 'tty/ttyUSB2'... > > [modem2] cleaning up port 'wwan/wwan0qmi0'... > > [modem2] cleaning up port 'unknown/wwan0mbim0'... > > [ttyUSB2/at] forced to close port > > [modem2] (quectel) check SIM swap completed > > [modem2] completely disposed > > [device SG520TM] Reprobing modem... > > [device SG520TM] creating modem with plugin 'quectel' and '5' > ports > > [plugin/quectel] (quectel) QMI-powered Quectel modem found... > > [wwan0qmi0/qmi] timeout monitoring enabled in QMI port > > [modem3] port 'wwan/wwan0qmi0' grabbed > > [plugin/quectel] port wwan0qcdm0 is blacklisted > > [modem3] port 'wwan/wwan0qcdm0' grabbed > > [plugin/quectel] port wwan0mbim0 is blacklisted > > [modem3] port 'wwan/wwan0mbim0' grabbed > > [modem3] port 'net/mhi_hwip0' grabbed > > [ttyUSB2/at] timeout monitoring enabled in AT port > > [ttyUSB2/at] AT port flagged as primary > > [modem3] port 'tty/ttyUSB2' grabbed > > [modem3] tty/ttyUSB2 at (primary) > > [modem3] tty/ttyUSB2 at (data primary) > > [modem3] net/mhi_hwip0 net (data) > > [modem3] wwan/wwan0qmi0 qmi > > [modem3] at data ports available but ignored > > [wwan0qmi0/qmi] endpoint info updated: type 'pcie', interface > number '0' > > [modem3] running QMI port 'wwan0qmi0' reset with data interface > 'mhi_hwip0' > > [device SG520TM] modem recreated > > [wwan0qmi0/qmi] bringing down data interface 'mhi_hwip0' > > [modem3/mhi_hwip0/net] interface index: 2 > > [wwan0qmi0/qmi] deleting all links in data interface 'mhi_hwip0' > > [wwan0qmi0/qmi] Opening QMI device... > > [wwan0qmi0/qmi] Checking if QMI device already opening... > > [wwan0qmi0/qmi] Checking if QMI device already open... > > [wwan0qmi0/qmi] Creating QMI device... > > [wwan0qmi0/qmi] Opening device with flags: version-info, proxy... > > [/dev/wwan0qmi0] opening device with flags 'version-info, > proxy'... > > [/dev/wwan0qmi0] created endpoint > > [/dev/wwan0qmi0] sent message... > > << RAW: > > << length = 29 > > << data = 01:1C:00:00:00:00:00:01:00:FF:11:00... > > > > [/dev/wwan0qmi0] sent generic request (translated)... > > << QMUX: > > << length = 28 > > << flags = 0x00 > > << service = "ctl" > > << client = 0 > > << QMI: > > << flags = "none" > > << transaction = 1 > > << tlv_length = 17 > > << message = "Internal Proxy Open" (0xFF00) > > << TLV: > > << type = "Device Path" (0x01) > > << length = 14 > > << value = 2F:64:65:76:2F:77:77:61:6E:30:71:6D:69:30 > > << translated = /dev/wwan0qmi0 > > > > [/dev/wwan0qmi0] number of consecutive timeouts: 1 > > [/dev/wwan0qmi0] transaction 0xf aborted, but message is not > abortable > > [/dev/wwan0qmi0] number of consecutive timeouts: 2 > > [/dev/wwan0qmi0] transaction 0x10 aborted, but message is not > abortable > > [/dev/wwan0qmi0] number of consecutive timeouts: 3 > > [/dev/wwan0qmi0] transaction 0x11 aborted, but message is not > abortable > > [/dev/wwan0qmi0] number of consecutive timeouts: 4 > > [/dev/wwan0qmi0] transaction 0x12 aborted, but message is not > abortable > > [/dev/wwan0qmi0] number of consecutive timeouts: 5 > > [/dev/wwan0qmi0] transaction 0x13 aborted, but message is not > abortable > > [/dev/wwan0qmi0] number of consecutive timeouts: 6 > > [/dev/wwan0qmi0] transaction 0x14 aborted, but message is not > abortable > > [/dev/wwan0qmi0] number of consecutive timeouts: 7 > > [/dev/wwan0qmi0] transaction 0x15 aborted, but message is not > abortable > > [/dev/wwan0qmi0] number of consecutive timeouts: 8 > > [/dev/wwan0qmi0] transaction 0x16 aborted, but message is not > abortable > > [/dev/wwan0qmi0] number of consecutive timeouts: 9 >
Re: May I commit binary files into MM project?
I have a concern about can we commit binary files into /data/dispatcher-fcc-unlock folder? If you want to dump a proprietary precompiled binary in the fcc-unlock folder, the answer is "no" :) Regardless, these binaries would not run on other architectures! Therefore, they must be scripts or source code that can be compiled. The modem manager is used in OpenWrt and this distribution supports many architectures. Best Regards Florian Eckert
Re: modem is unusable when removing and putting back sim card
Hey > I am working with ModemManager with qmi-proxy and I have a weird behavior > when I am using ModemManager with the log-level set to DEBUG like this > "ModemManager --log-level=DEBUG &" > everything is working fine but when I use it normally or set the log-level to > anything else except debug I have "modem is unusable" > Here are the logs : > [modem2] cleaning up port 'net/mhi_hwip0'... > [modem2] cleaning up port 'unknown/wwan0qcdm0'... > [modem2] cleaning up port 'tty/ttyUSB2'... > [modem2] cleaning up port 'wwan/wwan0qmi0'... > [modem2] cleaning up port 'unknown/wwan0mbim0'... > [ttyUSB2/at] forced to close port > [modem2] (quectel) check SIM swap completed > [modem2] completely disposed > [device SG520TM] Reprobing modem... > [device SG520TM] creating modem with plugin 'quectel' and '5' ports > [plugin/quectel] (quectel) QMI-powered Quectel modem found... > [wwan0qmi0/qmi] timeout monitoring enabled in QMI port > [modem3] port 'wwan/wwan0qmi0' grabbed > [plugin/quectel] port wwan0qcdm0 is blacklisted > [modem3] port 'wwan/wwan0qcdm0' grabbed > [plugin/quectel] port wwan0mbim0 is blacklisted > [modem3] port 'wwan/wwan0mbim0' grabbed > [modem3] port 'net/mhi_hwip0' grabbed > [ttyUSB2/at] timeout monitoring enabled in AT port > [ttyUSB2/at] AT port flagged as primary > [modem3] port 'tty/ttyUSB2' grabbed > [modem3] tty/ttyUSB2 at (primary) > [modem3] tty/ttyUSB2 at (data primary) > [modem3] net/mhi_hwip0 net (data) > [modem3] wwan/wwan0qmi0 qmi > [modem3] at data ports available but ignored > [wwan0qmi0/qmi] endpoint info updated: type 'pcie', interface number > '0' > [modem3] running QMI port 'wwan0qmi0' reset with data interface > 'mhi_hwip0' > [device SG520TM] modem recreated > [wwan0qmi0/qmi] bringing down data interface 'mhi_hwip0' > [modem3/mhi_hwip0/net] interface index: 2 > [wwan0qmi0/qmi] deleting all links in data interface 'mhi_hwip0' > [wwan0qmi0/qmi] Opening QMI device... > [wwan0qmi0/qmi] Checking if QMI device already opening... > [wwan0qmi0/qmi] Checking if QMI device already open... > [wwan0qmi0/qmi] Creating QMI device... > [wwan0qmi0/qmi] Opening device with flags: version-info, proxy... > [/dev/wwan0qmi0] opening device with flags 'version-info, proxy'... > [/dev/wwan0qmi0] created endpoint > [/dev/wwan0qmi0] sent message... > << RAW: > << length = 29 > << data = 01:1C:00:00:00:00:00:01:00:FF:11:00... > > [/dev/wwan0qmi0] sent generic request (translated)... > << QMUX: > << length = 28 > << flags = 0x00 > << service = "ctl" > << client = 0 > << QMI: > << flags = "none" > << transaction = 1 > << tlv_length = 17 > << message = "Internal Proxy Open" (0xFF00) > << TLV: > << type = "Device Path" (0x01) > << length = 14 > << value = 2F:64:65:76:2F:77:77:61:6E:30:71:6D:69:30 > << translated = /dev/wwan0qmi0 > > [/dev/wwan0qmi0] number of consecutive timeouts: 1 > [/dev/wwan0qmi0] transaction 0xf aborted, but message is not abortable > [/dev/wwan0qmi0] number of consecutive timeouts: 2 > [/dev/wwan0qmi0] transaction 0x10 aborted, but message is not > abortable > [/dev/wwan0qmi0] number of consecutive timeouts: 3 > [/dev/wwan0qmi0] transaction 0x11 aborted, but message is not > abortable > [/dev/wwan0qmi0] number of consecutive timeouts: 4 > [/dev/wwan0qmi0] transaction 0x12 aborted, but message is not > abortable > [/dev/wwan0qmi0] number of consecutive timeouts: 5 > [/dev/wwan0qmi0] transaction 0x13 aborted, but message is not > abortable > [/dev/wwan0qmi0] number of consecutive timeouts: 6 > [/dev/wwan0qmi0] transaction 0x14 aborted, but message is not > abortable > [/dev/wwan0qmi0] number of consecutive timeouts: 7 > [/dev/wwan0qmi0] transaction 0x15 aborted, but message is not > abortable > [/dev/wwan0qmi0] number of consecutive timeouts: 8 > [/dev/wwan0qmi0] transaction 0x16 aborted, but message is not > abortable > [/dev/wwan0qmi0] number of consecutive timeouts: 9 > [/dev/wwan0qmi0] transaction 0x17 aborted, but message is not > abortable > [/dev/wwan0qmi0] number of consecutive timeouts: 10 > [/dev/wwan0qmi0] transaction 0x18 aborted, but message is not > abortable > [/dev/wwan0qmi0] number of consecutive timeouts: 1 > [/dev/wwan0qmi0] transaction 0x1 aborted, but message is not abortable > [wwan0qmi0/qmi] QMI port open operation failed: Transaction timed out > [modem3] couldn't open QMI port with data format update: Transaction > timed out > [wwan0qmi0/qmi] Opening QMI device... > [wwan0qmi0/qmi] Checking if QMI device already opening... > [wwan0qmi0/qmi] Checking if QMI device already open... > [wwan0qmi0/qmi] Creating QMI device... > [wwan0qmi0/qmi] Opening device with flags: version-info, proxy... > [/dev/wwan0qmi0] opening device with flags 'version-info, proxy'... > [/dev/wwan0qmi0] created endpoint > [/dev/wwan0qmi0] sent message... > << RAW: > <<
Re: FM350-GL (installed in ThinkPad P1 Gen 5)
On Wed, Sep 13, 2023 at 12:54 PM Thilo-Alexander Ginkel wrote: > > On Tue, Sep 12, 2023 at 1:31 PM Bjørn Mork wrote: >> >> > Turns out the challenge needs to be requested via --set-fcc-lock=0,0. >> >> Right. Makes sense. >> >> > Still, I can't get a valid unlock. >> >> And those challenge input values are correct? The firware isn't >> expecting something other than 0,0? > > > I patched the Linux kernel's WWAN driver to add logging of the data sent > to/from the modem and as it turns out the MBIM code path isn't even used by > the official tool (although both the firmware and the unlock tool implement > it). Instead AT commands are being used. > > Will this work for ModemManeger's firmware unlock? So far all scripts I have > seen seem to rely on the MBIM device. > We can make this work if needed, yes. The main issue is that we don't have an "AT proxy" as we do with QMI or MBIM, so it would require some sync with MM to ensure we're not touching the AT port at the same time. -- Aleksander
Re: T-Mobile Contributions
> > I'm excited to announce that T-Mobile US is now using > ModemManager/libMBIM/libQMI > for our 5G Fixed Wireless products [https://www.t-mobile.com/home-internet]. > We > are currently the largest FWA ISP in the world with well over 3 Million > subscribers, i.e., lots of ModemManager users! We did this via an > architectural > contribution in partnership with the RDK community, a popular STB/Router Linux > distro running on over 100 Million devices. > > MM is now supported in RDK via a FOSS MM connection manager, CellularManager > [https://code.rdkcentral.com/r/plugins/gitiles/collaboration/rdkb/components/ > opensource/ccsp/RdkCellularManager-MM/+/refs/heads/main] > (need to signup for a free login), and is being worked on by dozens of major > OEMs > & ISPs. If anyone wants to provide feedback or reviews, please let me know. > > We're working hard to realize the full potential of this community by > providing > quality merge requests, via our partners & RDK, and guiding modem makers > towards > standards like QMI/MBIM. Please keep an eye out for us and our partners on the > ML & Gitlab! > Excellent news Matthew! I'm really happy this integration was possible :) -- Aleksander
Re: T-Mobile Contributions
> > I'm excited to announce that T-Mobile US is now using > > ModemManager/libMBIM/libQMI > > for our 5G Fixed Wireless products > > [https://www.t-mobile.com/home-internet]. We > > are currently the largest FWA ISP in the world with well over 3 > > Million > > subscribers, i.e., lots of ModemManager users! We did this via an > > architectural > > contribution in partnership with the RDK community, a popular > > STB/Router Linux > > distro running on over 100 Million devices. > > > > MM is now supported in RDK via a FOSS MM connection manager, > > CellularManager > > [ > > https://code.rdkcentral.com/r/plugins/gitiles/collaboration/rdkb/compo > > nents/ > > opensource/ccsp/RdkCellularManager-MM/+/refs/heads/main] > > (need to signup for a free login), and is being worked on by dozens > > of major OEMs > > & ISPs. If anyone wants to provide feedback or reviews, please let me > > know. > > > > We're working hard to realize the full potential of this community by > > providing > > quality merge requests, via our partners & RDK, and guiding modem > > makers towards > > standards like QMI/MBIM. Please keep an eye out for us and our > > partners on the > > ML & Gitlab! > > That's awesome! Never imagined the kind of reach MM has achieved when > the project got started long long ago... > We're everywhere! Flying drones, airplanes, laptops, cars, phones, and now home routers as well :D -- Aleksander
Re: May I commit binary files into MM project?
Hey > I have a concern about can we commit binary files into > /data/dispatcher-fcc-unlock folder? All the FCC unlock scripts/programs shipped by ModemManager are GPLv2+. If you can distribute your program under the GPLv2+, we could set it up to build from source along with the ModemManager project. If you want to dump a proprietary precompiled binary in the fcc-unlock folder, the answer is "no" :) Cheers! -- Aleksander
RE: ublox SARA does not connect
Hi Since I sent you this, I made some progress- - Modified ublox plugin to identify this modem as 4g - found out that the AT+COPS=0 you always send, does not return or return some proprietary CME code. that is because the modem does auto-registration and sending COPS interferes with that. That is stated in the datasheet. So removed it and it everything started working. - I do have still problems with specific devices which return error [modem0] couldn't load UE mode of operation for EPS: Serial command timed out. I guess that’s serial port hung from some previous command? ron -Original Message- From: Aleksander Morgado Sent: Monday, September 4, 2023 11:28 PM To: ron Cc: modemmanager-devel@lists.freedesktop.org Subject: Re: ublox SARA does not connect Hey > So its been a few months, and now when we install the product in US, trying > to connect to Verizon and tmobile, I face problems again. > Modem is ublox sara r5, which works through serial port AT commands only. > The modem seems to be connected, when issuing AT+CGDCONT , but modem > manager +network manager do not go ahead to create a connection > Attached logs > The modem is indeed registered as we can see the initial EPS bearer IP address for the vzwadmin APN, but for some reason MM doesn't know about that. I can see MM trying +CREG? and +CGREG? but they both seem to return the reg state as idle. Could you run +CEREG? manually in the AT port to see what it returns? The modem is detected as a 1-port AT generic modem, and none of the capability queries we do end up telling us it may be 4G capable (which is why we don't try +CEREG to check) ModemManager[573]: [1692200059.641466] [device /sys/devices/platform/soc@0/3080.bus/3086.serial] creating modem with plugin 'generic' and '1' ports ... ModemManager[573]: [1692200059.704189] [modem0/ttymxc0/at] --> 'AT+WS46=?' ModemManager[573]: [1692200059.716311] [modem0/ttymxc0/at] <-- '+CME ERROR: 100' -- Aleksander
May I commit binary files into MM project?
Hi all, I have a concern about can we commit binary files into /data/dispatcher-fcc-unlock folder? Then end user could call the script which will call this binary to do the unlock operation. This binary file are only used for specific VID/PID products. I saw project following GNU LGPLV2.1, but still want to do a double check. Hope to get your reply soon. Thanks.
