Aleksander Morgado writes:
> Hey Bjørn,
>
> I'm getting some strange reports of failures in the netlink
> communication when adding new multiplexed links in a MBIM modem, using
> cdc_mbim. I also have the kernel dmesg but it doesn't give any
> reference to the error, the only valid thing I have
Aleksander Morgado writes:
> Hey all,
>
> I wrote a doc explaining how IPv4/IPv6 connectivity in LTE networks is
> setup (a very basic case scenario), including different possible
> interactions between host, modem and network, and focusing on how all
> these are exposed by ModemManager.
>
> It
Radu C writes:
> Hi,
>
> There are multiple tutorials online on how to connect a modem to a 5G core
> with multiple PDUs using mbimcli (like
> https://www.kernel.org/doc/html/latest/networking/cdc_mbim.html#mbim-data-channel-userspace-abi,
> or
>
Aleksander Morgado writes:
> On Wed, Nov 8, 2023 at 9:49 AM Bjørn Mork wrote:
>>
>> Amol Lad writes:
>>
>> > It seems the failure is occurring at the last chunk (#61). The status
>> > returned in "134". Please advise if any idea what this error
Amol Lad writes:
> It seems the failure is occurring at the last chunk (#61). The status
> returned in "134". Please advise if any idea what this error status means?
>
> Bjørn, I saw one of your post in the mailing list regarding
> qmi-firmware-update failure? Any idea what is this error?
No
Thilo-Alexander Ginkel writes:
> 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?
>> Is this problem the same
Thilo-Alexander Ginkel writes:
> By coincidence I spotted [2]. Could that be related? Both modems are
> manufactured by Fibocom.
Not sure. You're not using the proxy, are you?
But you could also try with the proxy. Some USB devices aren't
expecting clients to come and go while the MBM
Thilo-Alexander Ginkel writes:
> meanwhile I have an idea how the FCC unlock for the FM350-GL works:
>
> 1. Retrieve radio state (only continue iff locked [== 0])
> 2. Get challenge from modem
> via mbim_message_intel_mutual_authentication_fcc_lock_set_new
> 3. Compute a SHA256 hash
> 4. Unlock
Aleksander Morgado writes:
> Interestingly, I believe some of us already have some very old Sequans
> modem that was sent to us like in 2013 or 2014 to test MBIM DSS. Mine
> is broken and doesn't read the SIM card, but I still have it
> somewhere. I'm sure your new plugin additions would be
Aleksander Morgado writes:
> Are we sure this is not an issue in the xhci driver itself? Maybe the
> specific combination of modem and xhci controller triggers some corner
> case that is not fully implemented correctly in xhci?
> Last time I found something similar it took me 2 weeks of reading
Peter Naulls writes:
> On my setup, we have to both power cycle the modem and also cycle the USB
> hub to regain proper control.
OK, thanks for the information. It should not be like that, but I'm not
surprised.
> This latter step might be the key here - you
> can use uhubctl.
uhubctl is
John Marrett writes:
>> But what can be done about that? From my point of view, fixing the
>> issue in the modem firmware is out of the question. The modem is running
>> SWI9X50C_01.14.13.00, which the latest available.
>>
>
> You should either open a case with the modem manufacturer if you
This is not an issue caused by ModemManager or any of the host drivers.
Nut I don't know where else to ask. And this documents the issue for my
next Google search :-)
I'm using a Sierra Wireless EM7565 connected to the USB3 port of a
Linksys WRT1900ACv1 "Mamba" (Marvell Armada 370/XP SoC), which
Arjen Smit writes:
> This question actually does extend to IPv6, here also via the available
> control protocol (QMI/AT/etc) the connection is initiated. It is the modem
> firmware that runs a SLAAC client process to receive a /64 prefix. Then
> the data interface on the host is able retrieve
Aleksander Morgado writes:
> See also
> https://gitlab.freedesktop.org/mobile-broadband/libmbim/-/merge_requests/157
Nice. That will make it much easier to experiment with this.
I found that UUID in the Windows code earlier, but Google didn't turn up
much. Only relevant hit was this:
Thilo-Alexander Ginkel writes:
> Hi there,
>
> as Lenovo couldn't fix my ThinkPad X1E4 (featuring an SDX55) I got a P1G5
> as a replacement, that, however, comes with a FM350-GL as WWAN modem. I
> guess we need to play the FCC unlock game again (as it does not work out of
> the box), but first
Aleksander Morgado writes:
>> (ModemManager:223904): GLib-CRITICAL **: 09:22:43.830: g_regex_match_full:
>> assertion 'regex != NULL' failed
>> corrupted double-linked list
>>
>
> The issue is triggered by the pcre1->pcre2 upgrade in glib 2.73.2, see:
>
Nick writes:
> Hey,
>
> I am testing a Quectel RM500Q on OpenWrt master, and have noticed to
> my surprise that the speed is much slower when using the qmi_wwan with
> MM than it is when using qmi_wwan_q and quectel-CM (Quectel’s
> proprietary driver and connection manager).
This is sort of
Qualcomm used to publish parts of their QMI related docs, both through the Code
Aurora Gobi project and as part of a separate open developer program they had.
But they changed their policies in 2013 or thereabout. So we don't have access
to anything newer. I assume the documents are still
Still struggling with this. Would appreciate any hints. Anyone tried
IPv6 on a mobile connection with a shorter prefix than /64? How do you
do that?
Assuming DHCPv6-PD, one basic problem is the selection of source and
destination addresses for the solicit. I really don't understand how
this
"Becker, Jochen" writes:
> Version T99W175 F0 1 0 0 9 DT 003 075
..
> Invalid transition
This is a Thinkpad with original modem? If so, I believe that firmware
version uses the "new" FCC unlock method. Which means that it requires
a very recent unlock script:
You said you were using Debian Bookworm, so then I assume you are
missing the mhi_wwan_mbim.ko module Loic is referring to. It was
included with the Debian sid kernel only a couple of days ago:
https://bugs.debian.org/1011395
So upgrade your kernel to version 5.17.11-1 (or newer) as soon as it
More interesting stuff from that binary. The resource section contains
3 zip-files among other stuff. Two of these contain DPR_Table.txt files
per device-id(?) and some binary blobs I don't recognise. Names might
indicate NV entries?
bjorn@miraculix:/tmp$ unzip -l resources/101.bin
Archive:
Thilo-Alexander Ginkel writes:
> Hello again,
>
> quick update if anyone wants to have a look before I find time to do so:
> The unlock is most probably in SIMService.exe, which contains the magic
> string "KHOIHGIUCCHHII" that is checked for in DMI and also used by the
> unlocking Snap...
I
Bjørn Mork writes:
> Wrt the implementation: Any protocol depending on closed binaries is
> broken by design, without exception. It doesn't matter whether you use
> a "secret" algorithm or just store keys inside the binary. Anything that
> was compiled can be de
Thilo-Alexander Ginkel writes:
> IIRC the snap does not support the modem running in an X1E4 that I own
> and Iam not sure wthere it implements the old or the new FCC unlock.
I believe this proves the experiment failed.
I am sure Mark and others in Lenovo have tried. I do not doubt their
good
Aleksander Morgado writes:
> Yes yes, since yesterday morning we have all libqrtr-glib, libmbim and
> libqmi already built using meson in openwrt-packages, so updating them
> manually to point to git main is just about changing the
> PKG_SOURCE_VERSION to point to the git main commit that you
Aleksander Morgado writes:
> Hey,
>
> The current openwrt integration suffered from a serious problem:
> network initiated disconnections were properly detected by MM but
> never reported to netifd. Due to this, the modem may end up in
> registered state while netifd thinks it is still
"Hugo Osvaldo Barrera" writes:
> Thanks for the pointers. I figured out I can make M.2 work, but from what
> I see, these have an eSIM, and I'm not sure they have a regular [nano]sim
> slot. Doesn't this imply that I cannot simply put a SIM card that my ISP
> gives me?
The SIM slots are part of
Aleksander Morgado writes:
> Don't know of any 5G USB dongle, although I didn't really look for any
> myself.
Assuming the request for 5G is primarily for higher bandwidth, then I
believe it's impossible in a USB dongle. Not space enough for the
antennas (unless you cheat and make them
Anton Maier writes:
> Many people who use H5321gw have to adjust the udev rule to:
> https://forums.linuxmint.com/viewtopic.php?t=130708
>
> maybe this should be done on default?
>
> Secondly i have very low connection speed and i tried all kinds of things.
> Is there maybe anything else i can
Aleksander Morgado writes:
> * A new FCC unlock operation management via external scripts is
>introduced, which will avoid to automatically unlock FCC locked
>devices unless the user has configured the operation manually, or
>unless an official vendor-provided FCC unlock tool is
detailed logs if this wasn't fixed already.
>>
>
> Please, provide detailed logs, we need to understand why this failed
> in the kernel. @Bjørn Mork any idea why it may have failed like this?
> does the kernel need any additional thi
Aleksander Morgado writes:
> The people at KDE are working on some patches to better integrate the
> EG25 under suspend/resume events; they're changing not only power
> related sysfs attributes, but also patching certain parts of the
> kernel drivers, including the cdc-wdm driver.
>
>
Aleksander Morgado writes:
>> > I wanted to test the EM120 setup I have with latest MM git master and
>> > kernel 5.13.0-rc2, but unfortunately there is some issue, not sure if
>> > in device or in kernel driver. These are the kernel logs I get as
>> > output when the issue happens:
>> >
>> > [
Oskar Stenman writes:
> After that i could run:
> $ sudo qmicli -p -d /dev/wwan0p2MBIM --device-open-mbim
> --dms-dell-cuskit-unlock=00
> [11 maj 2021, 23:42:36] -Warning ** [/dev/wwan0p2MBIM] couldn't detect
> transport type of port: couldn't detect device driver
> [11 maj 2021, 23:42:36]
Aleksander Morgado writes:
> Hey,
>
>>
>> The problem we have now is that we no longer have a simple solution to snoop
>> the trafic from windows. It was simple with USB but I have no idea how to do
>> that with PCIe. I've never worked with PCI-drivers.
>> -
>
> There has
Aleksander Morgado writes:
> I have a draft setup to test the commands provided in the custkit
> tool, but never made it work I'm afraid:
> https://gitlab.freedesktop.org/aleksm/libqmi/-/tree/aleksander/dell-cuskit
>
> That branch introduces a new qmicli --dms-dell-cuskit-unlock=[XX]
> command,
Aleksander Morgado writes:
>> So maybe you'll have better luck using profiles.
>
> Oh, how convenient, if only we had the ability to connect using
> specific existing profile ids with ModemManager... :D (it's already in
> git master!)
Yes, I will find some time to retest the modem with that
Reinhard Speyerer writes:
> from the observed behaviour AT+QMBNCFG="AutoSel",1 seems to have a similar
> semantics as the Sierra Wireless PRI "AUTO-SIM" feature discussed recently
> without the need for a device reboot. Depending on the IMSI and/or other
> properties of your SIM AT+CGDCONT
Reinhard Speyerer writes:
> On Mon, Apr 26, 2021 at 06:23:01PM +0200, Bjørn Mork wrote:
>> Bjørn Mork writes:
>>
>> > Sorry, i do not think these issues are related to ModemManager at all.
>>
>> This is a test from freshly booted modem, MM not running:
&g
Bjørn Mork writes:
> Sorry, i do not think these issues are related to ModemManager at all.
This is a test from freshly booted modem, MM not running:
root@finn:~# qmicli -p -d /dev/cdc-wdm0 --device-open-sync
--wda-set-data-format=ep-type=hsusb,ep-iface-number=4,link-layer-protocol=raw-ip
Aleksander Morgado writes:
>> Some observations:
>>
>> - dual-stack fails if default bearer is connected as ipv4 only
>
> Oh, but this is expected, isn't it? or is it not expected? I have
> always assumed that to be the case.
Yes, I guess it is expected. It was mostly the APN change that
Aleksander Morgado writes:
> Hey,
>
>> > Well, the direct reason is clear from the log: We skip the
>> > CONNECT_STEP_IP_FAMILY_IPV4 step for bearer2+. So we can connect
>> > multiple IPv6 bearers after the first one. Just not any IPv4 or
>> > dual-stack.
>>
>> OK, an extra debug line proves
Bjørn Mork writes:
> Well, the direct reason is clear from the log: We skip the
> CONNECT_STEP_IP_FAMILY_IPV4 step for bearer2+. So we can connect
> multiple IPv6 bearers after the first one. Just not any IPv4 or
> dual-stack.
OK, an extra debug line proves that this is because
Well, the direct reason is clear from the log: We skip the
CONNECT_STEP_IP_FAMILY_IPV4 step for bearer2+. So we can connect
multiple IPv6 bearers after the first one. Just not any IPv4 or
dual-stack.
Still clueless wrt the underlying problem.
Bjørn
FYI, dual stack works after reordering the connection sequence a bit:
root@finn:/# mmcli -b 1
General| path: /org/freedesktop/ModemManager1/Bearer/1
| type: default
Bjørn Mork writes:
> But this works:
Except for the minor detail that qmapv5 won't work with the muxing in
qmi_wwan. Which I believe is fine, as that muxing solution is
deprecated anyway.
But MM still needs to be aware, and change the protocol to qmap when
using the qmi_wwan muxing.
Verif
Aleksander Morgado writes:
>> Pushed it to git master now, thanks for the patch!
>>
>
> I still had to push an additional fix on top of yours to fix the
> gitlab pipelines :D
Ah, right. That was a sloppy fix. Should have tested WITH_QRTR too. But
it fixed my problem :-)
Bjørn
Bjørn Mork writes:
> Or give me a few days and I might be able to bisect the problem.
A few meetings helps a lot with time for robotic work like bisecting :-)
The winner is:
commit ec375bd959f071ce01533d50a2775e8a6f69607b
Author: Andrew Lassalle
Date: Wed Nov 25 13:14:35 2020 -0
Elias Rudberg writes:
>> [6596]: [1619029470.853036] [ttyUSB0/qcdm] opening serial
> port...
>> [6596]: [1619029470.854109] [ttyUSB0/qcdm] device open count
> is 1 (open)
>> [6596]: [1619029470.854688] [cdc-wdm0/probe] probing QMI...
>>
>> Thread 1 "ModemManager" received signal SIGSEGV,
Aleksander Morgado writes:
>> I guess this could point to the problem? Or just mean that only crazy
>> people run valgrind on MIPS ;-)
>>
>
> I think it's the latter... :D
Yes. I get the feeling there are a few OpenWrt users left and not much
more.
> Could be an endianness issue? that setup
Bjørn Mork writes:
> Aleksander Morgado writes:
>
>>> Bu can't I just run valgrind on the MIPS CPU? Any hints on how to use
>>> valgrind? It's one of those tools I've been thing that I should
>>> explore, but never have..
>>>
>>
>> I ha
Aleksander Morgado writes:
>> > Guess I have to figure out how to build this with a few more symbols and
>> > running gdb.
>>
>> OK, so now I have:
>>
>> [6596]: [1619029470.853036] [ttyUSB0/qcdm] opening serial port...
>> [6596]: [1619029470.854109] [ttyUSB0/qcdm] device open count is 1
>>
Hello!
I got myself a new toy in the form of a board with dual SIM slots and a
Quectel RG502Q-EA modem. Which are hardware features I haven't had
access to before.
So I wanted to play with the dual SIM slot support in MM. The short
version is: It works like a charm!
The UI confused me at
Bjørn Mork writes:
> Guess I have to figure out how to build this with a few more symbols and
> running gdb.
OK, so now I have:
[6596]: [1619029470.853036] [ttyUSB0/qcdm] opening serial port...
[6596]: [1619029470.854109] [ttyUSB0/qcdm] device open count is 1 (open)
How did you do that? Is there any best practice?
Say I have a dual stack PDN link up and running using a USB connected
modem. But I am going to use this in a CPE and need more addresses than
that single /64.
So I want to send a DHCPv6 solicit over the mobile link requesting an
IA_PD. But a
"Carl Yin(殷张成)" writes:
> Maybe Rafal is same as me, newbie to the open source world, not clear
> the rules of open source.
> Limited by our technical ability and time, in the past , we never work
> together with customers to solve issues related to ModemManager
> In fact, If
Aleksander Morgado writes:
> And an additional question I have; what if we start using QMAP also
> for qmi_wwan based modems that support it? I think it would be very
> similar to your current needs with QRTR/IPA, right? See
>
"Hagstrom, Walter" writes:
> I have an EM9190 Sierra Wireless 5G modem, this modem only supports
> MBIM and not QMI; when I make a 5G connection (I can see via !gstatus
> the modem is connected on 5G), MBIM does not advertise any 5G
> capabilities nor does it show the access technology is 5G. I
Bjørn Mork writes:
> Aleksander Morgado writes:
>
>> I've opened a new issue in gitlab for your problem:
>> https://gitlab.freedesktop.org/mobile-broadband/libmbim/-/issues/9
>> Will take a look at the problem sometime this week.
>
> Something is incrementing t
Aleksander Morgado writes:
> I've opened a new issue in gitlab for your problem:
> https://gitlab.freedesktop.org/mobile-broadband/libmbim/-/issues/9
> Will take a look at the problem sometime this week.
Something is incrementing the transaction id between each fragment:
[21 ä¹ 2020,
Edward Chang writes:
> [17 ¹ 2020, 08:22:51] -Warning ** [/dev/cdc-wdm_pcie] Couldn't read
> descriptors file: Failed to open file
> /sys/devices/pci:00/:00:1d.0/:3a:00.0/descriptors: No such
> file or directory
Now you made me curious. Hope you'll share this driver when
Aleksander Morgado writes:
> How about this?
> https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/348
Tested now. Works fine. Ends up with an ipv4v6 bearer with only ipv4
data, but that is what we asked for so I believe that is the correct
thing to do.
Aleksander Morgado writes:
> How about this?
> https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/348
Looks like that will work. My laptop modem is a bit busy at the moment,
so I haven't tested yet. Too many APNs to reconnect, and too little
support for multiplexed
Hello!
The current MM scheme where it will tries IPV4V6 by default, and falls
back to IPV4 and then IPV6 works pretty well.
But I've been looking at the other end of this the last few days. And
been puzzled by the fact that we get a session established on the first
IPv4V6 attempt, which is then
Aleksander Morgado writes:
>>
>> WARNING: CPU: 1 PID: 0 at /linux-4.10.0/net/sched/sch_generic.c:316
>> dev_watchdog+0x22c/0x230
>> NETDEV WATCHDOG: wwp0s (qmi_wwan): transmit queue 0 timed out
>>
>
> Oh well, the infamous "transmit queue 0 timed out" error... That is,
> as far as I know, a
"Wassenberg, Dennis" writes:
> I tested the PCI approach.
>
> Unfortunately I had no luck. The kernel PCI driver at
> https://github.com/xmm7360/xmm7360-pci can not initiale the modem
> correctly. The modem stays at status=0xfeedb007. This seems to mean
> that the modem is (still) booting. After
"Wassenberg, Dennis" writes:
> After that dmesg shows this:
> [ 930.843781] usb 1-7: new high-speed USB device number 16 using xhci_hcd
> [ 930.996572] usb 1-7: New USB device found, idVendor=8087, idProduct=07f5,
> bcdDevice= 0.00
> [ 930.996577] usb 1-7: New USB device strings: Mfr=0,
Aleksander Morgado writes:
> Anyway, as you also said, having lost the AT port may indicate other
> kinds of internal problems, so attempting to trigger a reset ourselves
> wouldn't be that bad in this case? I'm open to suggestions on how to
> best handle this. Until now ModemManager hasn't done
Hello!
I am currently using my EM7565 mostly as a backup link, connected to a
Linksys WRT1900ACv1 running a recent OpenWrt build, using the current
ModemManager package there. I find this setup very convenient for
occasional testing of QMI or ModemManager stuff, whether it is OpenWrt
related or
Martin writes:
> On 2020-02-07 10:50, Bjørn Mork wrote:
>> Maybe disabling the pin is an option? MM can do that. IMHO, there's
>> not much security value in the pin anyway if you are storing it on the
>> host system...
>
> It's more about the sec
Aleksander Morgado writes:
>> I'm using a modem just for SMS, i.e. no mobile internet.
>> Therefore, NM does not control my modem and maybe I will remove NM.
>> I can set the pin using mmcli, but it should be automatic.
>> How would I configure that?
>>
>
> ModemManager doesn't keep any state or
Enrico Mioso writes:
> the subjct says it all! Thanks guys!! :)
Don't know if this is sufficient, but I have this file which I believe
allows any member of the 'netdev' group to manage NM and MM:
root@miraculix:/tmp# cat
/etc/polkit-1/localauthority/50-local.d/42-miraculix.pkla
# $Id:
James Wah writes:
> Hi gang,
>
> I've been working on a PCI driver for the Fibocom L850-GL, and while
> it's very rough at this point, it sure does transfer data.
>
> If anyone is interested in developing support in MM, or in shaping
> the kernel driver into something people might actually want
Aleksander Morgado writes:
> The user reports the following:
>
> root@angelo-thinkpad-x1-carbon-4th:~# cat /sys/bus/usb/drivers/qmi_wwan/new_id
> 1199 9079
> root@angelo-thinkpad-x1-carbon-4th:~# cat
> /sys/bus/usb/drivers/qmi_wwan/remove_id
> 1199 9079
>
> Does this mean something is injecting
Aleksander Morgado writes:
> Hey Bjørn & all,
>
> I wonder if you have any idea why this issue is happening?
> https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/165#note_368404
>
> We can see how the kernel driver reported as managing the device that
> owns the cdc-wdm port
Amol Lad writes:
> Surprising; I'm kind of sure there is a crash when running
> --firmware-list command. I'm using Sierra EM7430 in MBIM mode. qmicli
> output is below. What is your configuration?
I'm using a Sierra EM7565 in QMI mode on OpenWrt. There's only one
image installed. The qmicli
Enrico Mioso writes:
> Or the keep.d directory... ?
Except that change won't survive sysupgrade. /etc/sysupgrade.conf will
Bjørn
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
Amol Lad writes:
> root@OpenWrt:/# mmcli -m 0 --firmware-list
> error: couldn't list firmware images:
> 'GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message recipient
> disconnected from message bus without replying'
Odd. Works for me:
root@wrt1900ac-1:/# mmcli -m 0 --firmware-list
Bjørn Mork writes:
> Aleksander Morgado writes:
>
>> Just add a ID_MM_DEVICE_IGNORE rule as you would have done with udev,
>> and restart the daemon.
>
> I should obviously have tried that first. Worked perfectly. After a
> reboot though. I believe the caching made
Nick B writes:
> Ah right, I see the problem now. I think Dan’s suggestions would help
> tremendously.
>
> Nevertheless, I tried ipv4v6 on Optus and Telstra in Australia. On
> Telstra I get both, on Optus I’ll only get IPv4. Specifying IPv6 on
> Optus yields no connection. So maybe it’s
Nick B writes:
> I have noticed that when using qmi_wwan when I run a speed test I will
> start to see a fair amount (more than ten per test) of these...
> [ 643.225139] xhci-hcd xhci-hcd.0.auto: ERROR unknown event type 37
>
> I have searched around and found that it is probably an "even ring
Hello!
I noticed that the package comes with the udev rules. Why is that? The
are explicitly installed by the makefile install rule:
define Package/modemmanager/install
$(INSTALL_DIR) $(1)/lib/udev/rules.d
$(INSTALL_DATA) $(PKG_INSTALL_DIR)/lib/udev/rules.d/*.rules
Aleksander Morgado writes:
> Will have to continue investigating, but I believe the
> IPv6/IPv4v6 support in the MM protocol handler is good enough now to
> be sent to openwrt packages for review :D
Definitely.
Off Topic:
OpenWrt has lots of hidden features I really like.
I wanted to use
Aleksander Morgado writes:
> Ok! we're close then. Looks like the IPv6 part may be overwriting the IPv4
> one.
> Could you retry with the attached patch applied?
Success!
root@wrt1900ac-1:~# ifstatus mm
{
"up": true,
"pending": false,
"available": true,
Bjørn Mork writes:
>> Lovely! Thanks for doing this test. If you could try to retest after
>> rebooting the router to see if the settings are applied correctly,
>> that would be fantastic.
>
> Will try. I guess I should figure out how to get some debugging out of
Aleksander Morgado writes:
> Hey Bjørn,
>
>> > I'm trying to test IPv4v6 and IPv6 using a Quectel EG06-E, which runs
>> > in QMI mode. This is in OpenWRT, using this branch that I'm working
>> > on:
>> >
Aleksander Morgado writes:
> Hey Thomas, Bjørn and all,
>
> I'm trying to test IPv4v6 and IPv6 using a Quectel EG06-E, which runs
> in QMI mode. This is in OpenWRT, using this branch that I'm working
> on:
>
Torsten Hilbrich writes:
> Versions:
>
> ModemManager: 1.10.4
> libmbim: 1.18.2
> libqmi: 1.22.4
>
> After updating our kernel from kernel v4.14.65 to v4.19.65 we got strange
> behaviour when performing S3.
>
> The WWAN modem often disappears from the USB bus and reappears with a
> different
Dan Williams writes:
> On Wed, 2019-08-21 at 12:23 +, Amol Lad wrote:
>> Please help with this. What could be the cause of significant MM
>> startup delay?
>
> When started, or when a new modem is plugged attached, ModemManager
> runs through a hardware detection sequence to figure out
Yegor Yefremov writes:
> I have a project where I'm using dhcpcd client. It is working without
> any problems with older modems like Quectel UC20 etc. But now we want
> to switch to SIM7600G-H and it is working in raw-ip mode. So far only
> udhcpc can handle such MAC address-less interfaces.
>
>
Nick writes:
> Is there any interest in making ModemManager an official OpenWrt
> package?
Yes. Aleksander already requested help doing that:
https://lists.freedesktop.org/archives/modemmanager-devel/2019-April/007201.html
> It seems like they would accept it. Is there a TODO?
>
Ulrich Mohr writes:
> Hey,
>
> We at Semex-Engcon use ModemManager in our vibration monitoring
> solution: https://www.semex-engcon.com/en/products/menhir.
>
> The device is used to monitor vibrations for civil engineering
> (e.g. construction sites) or seismic applications.
>
> The device runs
"Bowden, Brendan" writes:
> We're looking at using the AT port to get a few status values that
> don't appear to be readily available from QMI. One we need in
> particular is device temperature (there's a hardware failure condition
> that manifests as a very high temperature value). Of course
matthew stanger writes:
>>
>> Forgot to comment on this. They use a SIMCom SIM7100E or SIM7100A WWAN
>> module according to
>> https://developer.puri.sm/Librem5/Hardware_Reference.html
>
> Oh that's new, they where going to use the PLS8 with PCIe. That's what got
> my attention.
That's also a
matthew stanger writes:
> I thought
> the (Librem 5 Linux Phone) ( https://puri.sm/products/librem-5/ ) was
> already using MM with PCIe? I know that's their plan.
Forgot to comment on this. They use a SIMCom SIM7100E or SIM7100A WWAN
module according to
matthew stanger writes:
> Is this thread implying the MM doesn't support PCIe in general?
No. Only that kernel drivers are required.
The situation for USB devices is good because there are only a few
host<->device protocols in use, and those protocols are well known by
now. We even have a
王道之 writes:
> Intel have the plan to opensource the PCIe driver. I would put it here
> once the Intel opensource it.
Looking forward to that!
Bjørn
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
cture
>now in use. And I add two UDEV flag to set the subsystem and port name
>of
>the virtual ports, flags named ID_MM_VIRTUAL_SUBSYSTEMS and
>ID_MM_VIRTUAL_NAME, the way that the two new flags work just like the
>already existing UDE flag D_MM_PHYSDEV_UID did. In this way, the MM
&g
1 - 100 of 207 matches
Mail list logo
