Re: Quectel EC25 & AT connection Catch-22
On Fri, Apr 19, 2024 at 04:39:46PM +, Bruce Johnson wrote: > I have a question about using both QMI and the serial interface with > ModemManager. > > I had little difficulty getting ModemManager's SimpleModem to connect to > T-Mobile (USA) using a Quectel EG25-G, but we found that modem wasn't > compatible with AT and/or a private APN used by one of our customers. We > were advised to use the Quectel EC25, and after engaging both Quectel and > AT, we were told that we need to insert the APN into the modem using an AT > command, AT+CGDCONT=1,"IPV4V6","mcm.com.attz". I had to tweak the kernel > config and the ModemManager build. > > Mods: > > * I built ModemManager 1.18.4 with --with-at-command-via-dbus. > * In the kernel config, I added USB Serial Converter support -> USB > driver for GSM and CDMA modems. > > After I did this, the /dev/ttyUSB[1-4] files showed up, and I was able to > issue AT commands using ModemManager, but while the modem would sort-of > connect with SimpleModem's connect method -- I am getting a Bearer, and mmcli > shows "connected" -- I receive no IP address information from the carrier. > Port wwan0 is showing up as "ignored". (mmcli output below) > > The Quectel docs also said to patch the kernel a certain way to allow use of > serial and the QMI_WWAN driver, but wwan0 is still ignored. > > Does anyone have any suggestions? > > Thanks! > > -- > Bruce Johnson > Chantilly, Virginia > USA I will stand corrected in case - but... I don't think you need AT commands via d-bus to do this, but giving the APN via QMI somehow, depending on the object or method you use to connect. That said, you probably won't need qmi_wwan_q or whatever - the stock qmi_wwan driver from kernel, and "option" for serial should suffice. For some reason you have wwan0 (gnored) in your output which doesn't sound right. I would try to look at it/fix it first. Enrico > > > > General | path: /org/freedesktop/ModemManager1/Modem/0 >|device id: > > Hardware | manufacturer: Quectel >|model: EC25 >|firmware revision: EC25AFFAR07A14M4G >|supported: gsm-umts, lte >| current: gsm-umts, lte >| equipment id: 359401089771197 > > System | device: > /sys/devices/pci:00/:00:15.0/usb1/1-4 >| drivers: option, qmi_wwan >| plugin: quectel >| primary port: ttyUSB3 >|ports: ttyUSB2 (gps), ttyUSB3 (at), ttyUSB4 (at), > wwan0 (ignored) > > Status | unlock retries: sim-pin (3), sim-puk (10), sim-pin2 (3), > sim-puk2 (10) >|state: connected >| power state: on >| access tech: lte >| signal quality: 60% (recent) > > Modes|supported: allowed: 2g, 3g, 4g; preferred: none >| current: allowed: 2g, 3g, 4g; preferred: none > > IP |supported: ipv4, ipv6, ipv4v6 > > 3GPP | imei: 3594010 >| operator id: 310410 >|operator name: AT >| registration: home > > 3GPP EPS | ue mode of operation: csps-2 > > SIM | primary sim path: /org/freedesktop/ModemManager1/SIM/0 > > Bearer |paths: /org/freedesktop/ModemManager1/Bearer/0 > >
Re: Question regarding usage on laptops
On Tue, Aug 22, 2023 at 09:59:30AM -0400, Stephen Conley wrote: > Hello folks; > > First, let me apologize if this is already answered. It "feels like" a > question that should already be answered, but I've read the docs, searched > the mailing list archives, even read through the archives a bit ... So I > have to go on the assumption that it isn't a common question. > > Anyway, my desire is to take a small what-we-used-to-call "netbook" sized > laptop, such as one made by GPD, and basically turn it into a functional > "cell phone" that can make and receive calls and SMSes using an m.2 internal > card rather than some dangly dongle. > > I am aware of, and own, both a Pinephone and a Pinephone Pro with keyboard > case and this is pretty close to this, but the hardware has the worst > "performance to battery life" ratio I've ever seen (almost no performance > but burns power like crazy) and I would rather have something with a > trackpad/tracknub interface instead of a touch screen. > > Anyway, my questions are ... > > 1. There is a ton of mention about modem cards and laptops for *data*, > however I find almost no mention of calls/SMS on laptops (or the mentions > are so dilluted I can't find them). I think, theoretically, the same > software that powers the Pinephone's ability to make/receive calls and SMS > should "just work" on a laptop too, right? And I believe that software is > ModemManager which is why I'm posting here! :D SMS is easy, voice calsl is a different story. And ModemManager will help you manage them - and via purple-sms or mmcli itself youcan handle sms pretty well. For voice calls - the thing is very modem device dependant. Audio over USb is an option but then you might miss the software implementing that. If you have alsa PCM over I2S or something like that, things might be easier. > > 2. For power saving reasons, I'd want the thing to be sleeping most of the > time. Is it possible for the modem to wake up the laptop on a call/SMS? > This may be dependent on hardware specifics, I know, but has anyone at least > heard of this? I can't find anything, anywhere, about this. > > 3. Lastly ... has anyone out there done this already and has a > recommendation for a successful combination of parts to assemble such a > thing? My current plan is to use a spare laptop I have for experimentation > purposes, and once I have something working, find the smallest form factor > laptop I can cram the card into :) > > To elaborate on [3] -- I am interested in any hardware recommendations, even > modems that are known to work particularly well, not just complete > solutions. I've heard SierraWireless cards are really well supported and to > avoid the branded ones (i.e. the "Dell" versions and such). > > > Thanks so much for your time in reading this, you're helping make a > decade-or-so long dream into reality :) If I'm able to get this to work, I > will certainly do a write-up as to how I accomplished it so the knowledge > can be passed along. > > > - Steve > > Anyone please correct me if I'm wrong. Thanks, Enrico
Re: Add script handling on modem detection
Hi all!! I have a question regarding this - is MM actually the correct place to implement differenty dispatcher script calls? Wouldn't it be better to build an external application monitoring different aspects and invoking scripts with the relevant informations? Thanks, Enrico On Mon, Jul 10, 2023 at 12:19:26PM +0200, Aleksander Morgado wrote: > > >> I am using the modemmanager on openwrt (master). > > >> While playing around, I noticed that it might be useful to trigger > > >> an event after the modemmanager has detected a modem. > > >> We already use '/usr/lib/ModemManager/connection.d' one a successful > > >> connection. > > > > > > > > > There's already such interface, but it is not one provided by > > > ModemManager, but ModemManager re-uses one from Freedesktop. You can > > > watch for new modems by using the Freedesktop ObjectManager: > > > > > > https://www.freedesktop.org/software/ModemManager/api/latest/ref-dbus-standard-interfaces-objectmanager.html > > > > > > > > > Thanks for the hint. I'll have a look at it right away. > > > > I believe Florian is asking for a "dispatcher script" to be called > once we detect a new modem and before MM probes it, right? similar to > e.g. the dispatcher scripts we run when a bearer gets connected. I may > be mistaken though > > -- > Aleksander
Re: Automatic Reconnect
Hi! May i ask if you are able to reproduce it with OpenWrt master + packages in the feeds for master? Thanks, Enrico On Tue, Nov 01, 2022 at 10:40:58AM +, Lynx de Cat wrote: > I am using ModemManager version 1.18.6 on OpenWrt 22.03.2 with my > RG502Q-EA Quectel modem. My 4G ISP disconnects any connection after > exactly 48 hours, in relation to which ModemManager reports: > > Mon Oct 31 17:37:46 2022 daemon.info [2719]: [modem0/bearer1] > verbose call end reason (6,36): [3gpp] regular-deactivation > > and just leaves things disconnected. So I lose internet connectivity, > and, worse still, netifd / ifstatus wan still seems to think the > connection is active. > > This seems related to this: > > https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/775 > > In any question, my question is: why is the default behaviour not to > automatically reconnect, and how can I ensure that ModemManager will > reconnect upon: > > Mon Oct 31 17:37:46 2022 daemon.info [2719]: [modem0/bearer1] > verbose call end reason (6,36): [3gpp] regular-deactivation > > So that I retain internet connectivity?
Re: After modem reset is USB connections not re-added
Hi! If possible, I would recommend using newer versions of both ModemManager and OpenWRt. This may not fix your current issue, but may be beneficial in the long term. Enrico On Fri, 22 Jul 2022, Aleksander Morgado wrote: Date: Fri, 22 Jul 2022 10:25:42 From: Aleksander Morgado To: kars...@miwire.net Cc: "ModemManager (development)" Subject: Re: After modem reset is USB connections not re-added Hey Karsten! openWrt version is OpenWrt 19.07.2, r10947-65030d81f3 After power on is sysfspath OK and I can access modem via mmcli. I reset modem by use the command mmcli -m--reset According to logread -e hotplug is USB connections removed which is OK. I expect the USB connections to be re-established after a while. But nothing is re-established according to the following commands: 1. logread -e hotplug 2. dmesg | grep -i usb 3. ls -l /dev 4. ls -l That's weird. Is ModemManager responsible for re-establish USB connection ? No, not at all. After a --reset, MM asks the modem to reset itself. The modem should re-appear in the USB bus by itself. Do anyone have a method to trig re-establish of USB connection ? Could it be that the RM500 requires a new power-up sequence via GPIO for some reason? It would be a bit weird to require that after a --reset operation, but who knows. This is a question to ask to Quectel I guess. If Habanero evaluation board is power up WITHOUT connection to Quectell RMU500 modem evaluation board there is of cause no USB connections. But I expect the connection to pop up at plug in the USB cable which connect the two boards. But the situation is exactly the same as after reset of modem. Who is responsible for continuously try to establish USB connection in case the connections are down. ? If I'm not mistaken, the USB device should present itself in the bus and then the USB host would take care of managing all the communication to enumerate and bring up the device. If you're using an external eval board for the module, it may very well be that the module requires some kind of initialization to be done in the board itself (e.g. manually pressing the reset button or something like that). I would definitely talk to Quectel about this and ask them what they think. Also, the eval board documentation should help w.r.t. module bootup sequence. Cheers! -- Aleksander
Re: Lenovo T99W175 / Foxconn SDX55 update on LVFS breaks FCC unlock
I sincerely hope you succeed. If I'll see any way I can help out, I'll try my best to do it. Enrico On Mon, 9 May 2022, Thilo-Alexander Ginkel wrote: Date: Mon, 9 May 2022 20:13:43 From: Thilo-Alexander Ginkel To: Bjørn Mork Cc: "ModemManager (development)" , Aleksander Morgado Subject: Re: Lenovo T99W175 / Foxconn SDX55 update on LVFS breaks FCC unlock Hi Bjørn, thanks for your reply! I don't think that the lenovo-wwan-dpr snap implements the OTP unlocking mechanism. Lenovo also just posted in their forum [1] that the new firmware deliberately broke the unlock used by ModemManager. So that was probably my last Lenovo laptop... With regards to reversing the OTP mechanism: I made some first attempts at decompiling / diffing the Windows driver using Ghidra, but have to admit that I am not very experienced doing so and am somewhat lost as to which driver file actually implements the unlocking. Thanks, Thilo [1] https://forums.lenovo.com/t5/Other-Linux-Discussions/Finally-X55-5G-modem-works-under-linux/m-p/5082236?page=11#5639046 On Sun, May 1, 2022 at 6:31 PM Bjørn Mork wrote: 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 decompiled. Sure it can be obfuscated to make that harder. We all love a challenge :-) And just let me prove that fact without even modifying one byte of the code: root@miraculix:/tmp# cat /sys/class/dmi/id/product_family ThinkPad X1 Carbon 4th root@miraculix:/tmp# echo ThinkEdge > /tmp/product_family root@miraculix:/tmp# mount --bind /tmp/product_family /sys/class/dmi/id/product_family root@miraculix:/tmp# cat /sys/class/dmi/id/product_family ThinkEdge And what do you think? There goes the machine check May 1 18:24:59 miraculix DPR_Fcc_unlock_service: main(): FCC unlock app started May 1 18:24:59 miraculix DPR_Fcc_unlock_service: get_product(): DT May 1 18:24:59 miraculix DPR_Fcc_unlock_service: MACHINE = [4] --- THINKEDGE_SE30 = [4] May 1 18:24:59 miraculix DPR_Fcc_unlock_service: main(): FCC unlock app exited This doesn't work for me of course, only having the original EM7455 modem. But I do note that the log output changed from -1 to 4, whatever that means. Previously: May 1 18:21:01 miraculix DPR_Fcc_unlock_service: MACHINE = [-1] --- THINKEDGE_SE30 = [4] Something to try out on your X1E4, maybe? Bjørn
Re: Extending OpenWRt ModemManager protocol handler
With this architecture it will be netifd itself that retries? Is already there a way that provides an indication for netifd to wait some time before retrying? Trying to bring a bearer back up immediately might not be so much productive. On Tue, 11 Jan 2022, Aleksander Morgado wrote: Date: Tue, 11 Jan 2022 11:17:11 From: Aleksander Morgado To: Enrico Mioso Cc: Peter Naulls , "ModemManager (development)" Subject: Re: Extending OpenWRt ModemManager protocol handler Hey, In other words, I think the current situation isn't going to change so soon. So I was wondering if we can provide a kind of short-cut, so the protocol handler examines all bearers it finds, skipping all the modem device management. This would allow the code to be re-usable. What do you think? Would this solution be acceptable to you? I don't think the protocol handler should be implemented in a way that touches all bearers it finds; the handler has very specific entry points (setup, teardown) that receive as input argument the name of the interface it applies to. Then, we match one by one that name of the interface to one very specific modem based on the sysfs path configured in the interface, and then we know which are the bearer objects we need to look at (the ones in that specific modem). Another limitation of the protocol handler is that it assumes there's only one bearer connected, but that's a different story. If the protocol handler were a process that is running forever, we could attempt to do that monitoring in all bearers, but given that we have the very explicit per interface setup/teardown entry points, we're a bit limited. Ideally, MM and netifd would be in sync without any other additional process. If we had a way to tell netifd the underlying network device is really disconnected (is there any way to do that?), then we could even setup some hotplug scripts in MM itself or something like that. Talked to jow in #openwrt-devel about this, and I think I have a clean way to solve this issue. Any process can notify netifd that the underlying network is really disconnected, basically like this: . /lib/netifd/netifd-proto.sh proto_init_update $ifname 0; proto_send_update ifname there is the name of the netifd interface. What we could do is setup event scripts in ModemManager to be executed upon some specific events; e.g. on bearer connection and on bearer disconnection. ModemManager would call those scripts as appropriate, e.g. providing additional info as input arguments to the script. So, when a bearer gets disconnected, MM could call every script in /etc/ModemManager/bearer-disconnect.d/ passing as arguments the modem dbus path and the bearer dbus path. The openwrt package could provide a custom script in bearer-disconnect.d that would: * find the ifname applicable to the modem object * run the proto update sequence as above What do you think of having something like that? We already support custom scripts for when FCC unlock is needed, having event scripts for bearer connection/disconnection events would probably be fine also. They could also be used e.g. to setup/cleanup iptables rules on the specific connected interface and such, something that is currently not really possible because the user may not know which is the exact net interface of the modem being connected (even less when using multiplexing as net interfaces are created on the fly). -- Aleksander https://aleksander.es
Re: Extending OpenWRt ModemManager protocol handler
I am totally in agreement here. It would be VERY nice. :) Thanks!! On Tue, 11 Jan 2022, Aleksander Morgado wrote: Date: Tue, 11 Jan 2022 11:17:11 From: Aleksander Morgado To: Enrico Mioso Cc: Peter Naulls , "ModemManager (development)" Subject: Re: Extending OpenWRt ModemManager protocol handler Hey, In other words, I think the current situation isn't going to change so soon. So I was wondering if we can provide a kind of short-cut, so the protocol handler examines all bearers it finds, skipping all the modem device management. This would allow the code to be re-usable. What do you think? Would this solution be acceptable to you? I don't think the protocol handler should be implemented in a way that touches all bearers it finds; the handler has very specific entry points (setup, teardown) that receive as input argument the name of the interface it applies to. Then, we match one by one that name of the interface to one very specific modem based on the sysfs path configured in the interface, and then we know which are the bearer objects we need to look at (the ones in that specific modem). Another limitation of the protocol handler is that it assumes there's only one bearer connected, but that's a different story. If the protocol handler were a process that is running forever, we could attempt to do that monitoring in all bearers, but given that we have the very explicit per interface setup/teardown entry points, we're a bit limited. Ideally, MM and netifd would be in sync without any other additional process. If we had a way to tell netifd the underlying network device is really disconnected (is there any way to do that?), then we could even setup some hotplug scripts in MM itself or something like that. Talked to jow in #openwrt-devel about this, and I think I have a clean way to solve this issue. Any process can notify netifd that the underlying network is really disconnected, basically like this: . /lib/netifd/netifd-proto.sh proto_init_update $ifname 0; proto_send_update ifname there is the name of the netifd interface. What we could do is setup event scripts in ModemManager to be executed upon some specific events; e.g. on bearer connection and on bearer disconnection. ModemManager would call those scripts as appropriate, e.g. providing additional info as input arguments to the script. So, when a bearer gets disconnected, MM could call every script in /etc/ModemManager/bearer-disconnect.d/ passing as arguments the modem dbus path and the bearer dbus path. The openwrt package could provide a custom script in bearer-disconnect.d that would: * find the ifname applicable to the modem object * run the proto update sequence as above What do you think of having something like that? We already support custom scripts for when FCC unlock is needed, having event scripts for bearer connection/disconnection events would probably be fine also. They could also be used e.g. to setup/cleanup iptables rules on the specific connected interface and such, something that is currently not really possible because the user may not know which is the exact net interface of the modem being connected (even less when using multiplexing as net interfaces are created on the fly). -- Aleksander https://aleksander.es
Re: Extending OpenWRt ModemManager protocol handler
In other words, I think the current situation isn't going to change so soon. So I was wondering if we can provide a kind of short-cut, so the protocol handler examines all bearers it finds, skipping all the modem device management. This would allow the code to be re-usable. What do you think? Would this solution be acceptable to you? On Mon, 10 Jan 2022, Aleksander Morgado wrote: Date: Mon, 10 Jan 2022 15:44:09 From: Aleksander Morgado To: Peter Naulls Cc: "ModemManager (development)" Subject: Re: Extending OpenWRt ModemManager protocol handler Hey Peter, That's not really true, because that timeout is bound to the max time required by ModemManager to probe the AT/QMI/MBIM ports, which I believe is close to those 45s max per port (in parallel). Having an infinite loop there doesn't help, as that max time required by MM is not arbitrary, that's why I suggested incresing the timeout value; maybe some of the ports take up to 45s to probe and we just need a longer timeout when detecting the modem in DBus. Honestly, I'm a bit tired of these around and around debates with you. I think you like to argue a bit too much, and it's off-putting in trying to contribute. Oh, that is completely not my intention, and if you felt it that way, I'm __extremely__ sorry. Please, keep on sending emails, and please bear with my replies, and please never assume I'm trying to argue just for the sake of it, not my intention at all. Let's be very clear here - there are situations that ModemManager/netifd will simply timeout and then no longer attempt any connection. There are **a lot** of such scenarios, I totally acknowledge that, and from my point of view most (all?) those scenarios are due to the lack of sync between netifd and MM, as per https://bugs.openwrt.org/index.php?do=details_id=3499. I'm not trying to open any debate here, I totally acknowledge that lack of sync will break connectivity easily; e.g. netifd thinking the interface is connected while MM knows the interface is not connected (and with no way to report that back to netifd). Until that is fixed in netifd, we'll need additional programs to monitor the modem connection and trigger netifd interface updates accordingly (e.g. if we see the bearer disconnected in MM but the interface up in netifd, bring the interface down and reconnect). This was a serious problem for us that it took a long time to find. This is the fix I came up with which resolves that. I reported this early last year and it was dismissed. Was that patch sent against the ModemManager package in openwrt-packages (https://github.com/openwrt/packages/issues)? Or just in this mailing list? If you want to argue the mechanism, or do a better fix, then fine. But this is a very real problem. I'm sure that was a very real problem, I don't argue, but I'm just suggesting a different way to fix it because of how the port probing timing works in ModemManager, which isn't arbitrary and isn't infinite. MM stops probing the ports at some point, and by the time the last port probing has finished, the modem either gets exposed on DBus (so the wait succeeds) or not (so the wait must fail). Unfortunately we don't expose in DBus an event saying "we were probing modem at sysfs path XXX but the port probing failed and no modem is exposed in DBus"; if we had that event we could completely remove the timeout in mm_wait_for_modem(), but as we don't have the event, we configure a timeout slightly longer than the max probing time. Adding an infinite loop in mm_wait_for_modem could render that process waiting forever :/ If I'm suggesting a different way to handle the issue you tried to fix is because the way I'm suggesting may be simpler, and simpler to integrate in the openwrt package (which, BTW, I don't really maintain myself, Nick is doing that). -- Aleksander https://aleksander.es
Re: Extending OpenWRt ModemManager protocol handler
thanks a lot Aleksander for the help and assistance. On Mon, 10 Jan 2022, Peter Naulls wrote: Date: Mon, 10 Jan 2022 15:04:51 From: Peter Naulls To: Aleksander Morgado Cc: "ModemManager (development)" Subject: Re: Extending OpenWRt ModemManager protocol handler On 1/10/22 9:00 AM, Aleksander Morgado wrote: Hey, That's not really true, because that timeout is bound to the max time required by ModemManager to probe the AT/QMI/MBIM ports, which I believe is close to those 45s max per port (in parallel). Having an infinite loop there doesn't help, as that max time required by MM is not arbitrary, that's why I suggested incresing the timeout value; maybe some of the ports take up to 45s to probe and we just need a longer timeout when detecting the modem in DBus. Honestly, I'm a bit tired of these around and around debates with you. I think you like to argue a bit too much, and it's off-putting in trying to contribute. Let's be very clear here - there are situations that ModemManager/netifd will simply timeout and then no longer attempt any connection. This was a serious problem for us that it took a long time to find. This is the fix I came up with which resolves that. I reported this early last year and it was dismissed. If you want to argue the mechanism, or do a better fix, then fine. But this is a very real problem. I think we are talking about two unrelated thing: I was trying to keep the system persistently connected, so I am assuming detection worker properly. That said, thanks Aleksander for the pointer and hint. However, it would be nice if we could have some way to let it work right now: I would need the protocol handler to just examine connected bearer(s) and configure them. I would "refresh" it via the helper script invoking ifup somehow.
Extending OpenWRt ModemManager protocol handler
Hello!! So here I am at my second attempt to build a solution to enable multi-modems and multi-bearers usage in OpenWRt, with re-connection handling for persistent connectivity. This time I wrote a simpler application which only monitors existing bearers, and tries to keep them connected. An helper script is invoked whenever a bearer is added, connected, disconnected or removed. Was wondering for what could be the best path forward for reusing existing modemmanager protocol handler in this scenario. I plan to post the app to some git hosting site once it's in a more mature form. Thanks for the help and feedback! Enrico
AJ OpenWRt connection manager
Hello all!! This is AJ, my second attept at building a program that may help connecting and keeping consistently connected an OpenWRt device, or any Linux device running ModemManager. The idea is to keep all modems in the system connected as they where configured. The software shouldn't do many things, but do them consistently. Bearer creation and deletion is not handled in the software, even tough it won't be complete until an OpenWRt helper script / protocol handler are available. In OpenWRt, AJ may run as a procd instance. Testing hasn't been yet performed. The objective is for AJ to become ujail-enabled. What it does: For each modem exposed by ModemManager, this software: 1 - Connects all present bearers, and keeps them connected. 2 - Invokes an helper program (i.e.: currently a script) to perform required openwrt setup. I would like to know your opinion on whether this software is useful, and would appreciate very much your comments. This should be considered in early development stage, so there are surely various things to improve. The codebase is still small. Enrico P.S.: AJ stands for AirJoin. :) I named it inspiring myself to ZTE Join Air, it made me smile and remember the times where I played with my first GSM/UMTS dongles. aj.tar.lz Description: Binary data
Re: GSignals for bearers addition/removal
Hi!! Well, it's surely doable, no problem. the fact is - I tought there was a simpler solution. I will have to implement e mechanism to keep track of the bearers no longer present, so I was thiking to: - mark all the bearer objects I keep as non-visited - compare the bearer returned with the ones I have, marking any match as "visited" - in the end, all the non-visisted bearers are no longer present and will be removed Yeah, I'm going to use paths for comparison. Enrico On Mon, 4 Oct 2021, Aleksander Morgado wrote: Date: Mon, 4 Oct 2021 15:11:58 From: Aleksander Morgado To: Enrico Mioso Cc: "ModemManager (development)" Subject: Re: GSignals for bearers addition/removal Hey, On Mon, Oct 4, 2021 at 3:01 PM Enrico Mioso wrote: Ok. My idea was to connect to the ::connected signals of each bearer to monitor their state. To do so, I'm going to keep a list of bearers I am managing, and in my case i would like them to be ideally all of the bearers of a modem. To keep GSignals connected, I need to keep an object reference infact. But this way I will need to scan the entire list everytime. Am I missing something big? What you can do is; run the list operation once and get the initial bearer object list. Then, whenever the "bearers" property is updated you'll get notified, and you can compare the list of bearer object references you're keeping, with the new list (e.g. comparing the object DBus paths for example). If new bearers are reported in the new list, you take a reference to the object and add them to the list you're keeping. If a bearer that you had is no longer in the new list, you remove it from your list. It's a bit tricky, because the mm_modem_list_bearers_sync() operation is creating new bearer objects each time it's called, so the objects in the new list and the objects you're keeping in your own list are really different objects, even if they point to the same remote DBus object. -- Aleksander https://aleksander.es
Re: GSignals for bearers addition/removal
Ok. My idea was to connect to the ::connected signals of each bearer to monitor
their state.
To do so, I'm going to keep a list of bearers I am managing, and in my case i
would like them to be ideally all of the bearers of a modem.
To keep GSignals connected, I need to keep an object reference infact.
But this way I will need to scan the entire list everytime.
Am I missing something big?
On Mon, 4 Oct 2021, Aleksander Morgado wrote:
Date: Mon, 4 Oct 2021 12:57:07
From: Aleksander Morgado
To: Enrico Mioso
Cc: "ModemManager (development)"
Subject: Re: GSignals for bearers addition/removal
Hey!
Thanks a lot for your (as always) kind answer. I am using libmm-glib! :)
I am putting some code togeter but I haven't found the "proper" way to do so,
at least not so far.
static void
bearers_updated (MMModem *modem,
GParamSpec *pspec,
gpointer user_data)
{
GList *list;
// When this callback is called, the property in the MMModem
already has the latest value
list = mm_modem_list_bearers_sync (...)
}
g_signal_connect (modem, "notify::bearers", G_CALLBACK
(bearers_updated), some_user_data);
--
Aleksander
https://aleksander.es
Re: GSignals for bearers addition/removal
Thanks a lot!
Really grateful...
I'll do this way ! :)
On Mon, 4 Oct 2021, Aleksander Morgado wrote:
Date: Mon, 4 Oct 2021 12:57:07
From: Aleksander Morgado
To: Enrico Mioso
Cc: "ModemManager (development)"
Subject: Re: GSignals for bearers addition/removal
Hey!
Thanks a lot for your (as always) kind answer. I am using libmm-glib! :)
I am putting some code togeter but I haven't found the "proper" way to do so,
at least not so far.
static void
bearers_updated (MMModem *modem,
GParamSpec *pspec,
gpointer user_data)
{
GList *list;
// When this callback is called, the property in the MMModem
already has the latest value
list = mm_modem_list_bearers_sync (...)
}
g_signal_connect (modem, "notify::bearers", G_CALLBACK
(bearers_updated), some_user_data);
--
Aleksander
https://aleksander.es
Re: GSignals for bearers addition/removal
I mean - when I needed to do something like this in the past, what I did was
something like:
sig_id = g_signal_connect(modem, "g-properties-changed",
G_CALLBACK(my_mm_showchanges_on_modem_signal), NULL);
And then my handler was something like:
static void my_mm_showchanges_on_modem_signal(MMModem *modem, GVariant
*changed_props, GStrv inv_props, gpointer user_data) {
...
}
Is this the proper way to go? and what might I do now? Fetch the list from my
MMModem or can I use the GVariant data somehow?
Thanks a lot!
On Mon, 4 Oct 2021, Aleksander Morgado wrote:
Date: Mon, 4 Oct 2021 12:31:14
From: Aleksander Morgado
To: Enrico Mioso
Cc: "ModemManager (development)"
Subject: Re: GSignals for bearers addition/removal
Hey!
I see there is no documented GSignals for bearers addition/removal.
I understand I probably should get the bearers list and connect
object-{added,removed} GSignals to it. But I would like to see some code
snippets, to know the proper prototypes for the handlers.
We have the "Bearers" property in the Modem interface:
https://www.freedesktop.org/software/ModemManager/doc/latest/ModemManager/gdbus-org.freedesktop.ModemManager1.Modem.html#gdbus-property-org-freedesktop-ModemManager1-Modem.Bearers
If you're using raw processing of DBus, you'll need to listen for
org.freedesktop.DBus.Properties.PropertiesChanged signals emitted, and
monitor for the "Bearers" property being updated:
org.freedesktop.DBus.Properties.PropertiesChanged
(STRING interface_name,
DICT changed_properties,
ARRAY invalidated_properties);
But doing all this manually is a lot of work really; libmm-glib
abstracts all this nicely and is much easier to use...
--
Aleksander
https://aleksander.es
Re: GSignals for bearers addition/removal
Hi!!
Thanks a lot for your (as always) kind answer. I am using libmm-glib! :)
I am putting some code togeter but I haven't found the "proper" way to do so,
at least not so far.
thanks.
Enrico
On Mon, 4 Oct 2021, Aleksander Morgado wrote:
Date: Mon, 4 Oct 2021 12:31:14
From: Aleksander Morgado
To: Enrico Mioso
Cc: "ModemManager (development)"
Subject: Re: GSignals for bearers addition/removal
Hey!
I see there is no documented GSignals for bearers addition/removal.
I understand I probably should get the bearers list and connect
object-{added,removed} GSignals to it. But I would like to see some code
snippets, to know the proper prototypes for the handlers.
We have the "Bearers" property in the Modem interface:
https://www.freedesktop.org/software/ModemManager/doc/latest/ModemManager/gdbus-org.freedesktop.ModemManager1.Modem.html#gdbus-property-org-freedesktop-ModemManager1-Modem.Bearers
If you're using raw processing of DBus, you'll need to listen for
org.freedesktop.DBus.Properties.PropertiesChanged signals emitted, and
monitor for the "Bearers" property being updated:
org.freedesktop.DBus.Properties.PropertiesChanged
(STRING interface_name,
DICT changed_properties,
ARRAY invalidated_properties);
But doing all this manually is a lot of work really; libmm-glib
abstracts all this nicely and is much easier to use...
--
Aleksander
https://aleksander.es
GSignals for bearers addition/removal
Hello!
I see there is no documented GSignals for bearers addition/removal.
I understand I probably should get the bearers list and connect
object-{added,removed} GSignals to it. But I would like to see some code
snippets, to know the proper prototypes for the handlers.
Thanks!
Re: Modem connected but no internet
Some modems offer a DHCP emulation in their firmware. Others don't. And this information should be seen when you look at the bearer that gets created when you connect the modem. mmcli -m # should list bearers mmcli -b # should tell you the config method Maybe the modem corresponding to wwan1 has a "static" configuration method, assuming wwan1 doesn't pertain to the same modem exposing wwan0. If the configuration method is "static", you should somehow configure the modem, with the ip command or whatever fits. Maybe NetworkManager could be a solution for your use-case? I don't know, just proposing here. Enrico On Sat, 2 Oct 2021, Lucas Pelegrino wrote: Date: Sat, 2 Oct 2021 23:21:22 From: Lucas Pelegrino To: Yegor Yefremov Cc: "ModemManager (development)" Subject: Re: Modem connected but no internet Just to give some more information. When I do `dhclient wwan0` I can see a new route being added and wwan0 works: $ ip route show default via 100.72.135.138 dev wwan0 default via 192.168.0.1 dev wlan0 metric 1 default via 192.168.0.1 dev wlan0 proto dhcp metric 600 100.72.135.136/30 dev wwan0 proto kernel scope link src 100.72.135.137 100.73.179.140/30 dev wwan1 proto kernel scope link src 100.73.179.142 metric 700 192.168.0.0/24 dev wlan0 proto kernel scope link src 192.168.0.16 But if I do `dhclient wwan1` nothing changes on the `ip route show`. I don't understand much about networks, but I guess I can only have one route set? I think `dhclient` might not be the issue. Any information is appreciated. Em sáb., 2 de out. de 2021 às 12:03, Lucas Pelegrino escreveu: I tried running `sudo dhclient wwan0`, it seems it got one of the modems to work, but I have two modems and `wwan1` remains with the same problem and `sudo dhclient wwan1` didn't seem to work on it. 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 2: eth0: mtu 1500 qdisc fq_codel state DOWN group default qlen 1000 link/ether b8:27:eb:87:22:8e brd ff:ff:ff:ff:ff:ff 3: wlan0: mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether b8:27:eb:d2:77:db brd ff:ff:ff:ff:ff:ff inet 192.168.0.16/24 brd 192.168.0.255 scope global dynamic noprefixroute wlan0 valid_lft 8sec preferred_lft 8sec inet6 2804:14c:7582:46bf::1007/128 scope global dynamic noprefixroute valid_lft 85557sec preferred_lft 85557sec inet6 2804:14c:7582:46bf:cfbe:7945:f701:da92/64 scope global dynamic noprefixroute valid_lft 86372sec preferred_lft 71972sec inet6 fe80::5139:cd08:a2a9:9a4e/64 scope link noprefixroute valid_lft forever preferred_lft forever 4: wwan0: mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000 link/ether 0c:5b:8f:27:9a:64 brd ff:ff:ff:ff:ff:ff inet 100.70.243.89/30 brd 100.70.243.91 scope global noprefixroute wwan0 valid_lft forever preferred_lft forever 6: wwan1: mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000 link/ether 0c:5b:8f:27:9a:64 brd ff:ff:ff:ff:ff:ff inet 100.71.207.216/28 brd 100.71.207.223 scope global dynamic wwan1 valid_lft 518326sec preferred_lft 518326sec Em sáb., 2 de out. de 2021 às 11:36, Yegor Yefremov escreveu: Hi Lucas, On Sat, Oct 2, 2021 at 4:26 PM Lucas Pelegrino wrote: > > Hello there. > > I have this behavior in my raspberry PI where a modem shows connected, but I still can't connect to the internet: > > General | path: /org/freedesktop/ModemManager1/Modem/4 > | device id: ab1573a4186ee4930c3dbe7ee14e2dddcd10b4c2 > > Hardware | manufacturer: huawei > | model: E3276 > | firmware revision: 21.260.05.01.150 > | supported: gsm-umts > | current: gsm-umts > | equipment id: 866519011156587 > > System | device: /sys/devices/platform/soc/3f98.usb/usb1/1-1/1-1.2/1-1.2.2 > | drivers: huawei_cdc_ncm, option > | plugin: huawei > | primary port: cdc-wdm0 > | ports: cdc-wdm0 (at), ttyUSB0 (at), ttyUSB1 (at), wwan0 (net) > > Numbers | own: + > > Status | unlock retries: sim-pin (3), sim-puk (10), sim-pin2 (3), sim-puk2 (10) > | state: connected > | power state: on > | access tech: umts > | signal quality: 41% (recent) > > Modes | supported: allowed: 2g; preferred: none > | allowed: 3g; preferred: none > | allowed: 4g; preferred: none > | allowed: 2g, 3g, 4g; preferred: none > | current: allowed: 2g, 3g, 4g; preferred: none > > IP | supported: ipv4, ipv6, ipv4v6 > > 3GPP | imei: 866519011156587 > | operator
Re: ANN: ModemManager 1.18 released
+1 ! Thanks a lot Aleksander. Your patience and kidness helped me a lot and made it a pleasure to be a part of MM community! Enrico On Thu, 9 Sep 2021, Loic Poulain wrote: Date: Thu, 9 Sep 2021 17:41:50 From: Loic Poulain To: Aleksander Morgado Cc: "ModemManager (development)" Subject: Re: ANN: ModemManager 1.18 released On Thu, 9 Sept 2021 at 11:28, Aleksander Morgado wrote: Hey hey, This is a new major release of ModemManager, which will be the base for the 1.18.x stable series (the new "mm-1-18" branch in git). The release has been tagged as "1.18.0". A big one, thanks for your great work with MM! Regards, Loic
Re: Static vs DHCP setups from ModemManager in OpenWrt
Hello!! This is modem firmware-dependent: the modem decides how to present the configuration to you. This is what I understood at least. On Mon, 12 Jul 2021, Peter Naulls wrote: Date: Mon, 12 Jul 2021 14:19:04 From: Peter Naulls To: modemmanager-devel@lists.freedesktop.org Subject: Static vs DHCP setups from ModemManager in OpenWrt Hello all. I'm using ModemManger 1.16.6 on OpenWrt along with its scripts (and slight modifications so it doesn't just give up in the end). After a lot of testing and loss of connectivity, it seems that although our provider is offering DHCP, the connection via ModemManager is configured statically. This leads to loss of connection after several hours unless intervention is taken such as manual DHCP or re-configuring the interface. We can see here: # mmcli --modem 0 --bearer=1 --output-keyvalue | grep ipv4 bearer.properties.ip-type : ipv4v6 bearer.ipv4-config.method : static bearer.ipv4-config.address : 10.246.110.163 bearer.ipv4-config.prefix : 29 bearer.ipv4-config.gateway : 10.246.110.164 bearer.ipv4-config.dns.length : 1 bearer.ipv4-config.dns.value[1] : 107.112.229.135 bearer.ipv4-config.mtu : 1430 So the question is, is this a ModemManager bug? Or is it misreporting from the carrier, or something else? What can I do to debug this? Thanks! ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Quectel and Telit issues
Hello Marc! In my opinion, this is more of a musb-related issue than a Modemmanager related one. Or, in other words, I guess the problem stands in the path between your embedded board and the modem itself (USB related things). So, there is not much MM can do to help out. Do you have the possibility of trying a newer kernel? Enrico On Mon, 5 Jul 2021, Marc Murphy wrote: Date: Mon, 5 Jul 2021 15:03:08 From: Marc Murphy To: "modemmanager-devel@lists.freedesktop.org" Subject: Quectel and Telit issues Hello All Been looking at an issue on my embedded device. Have previously been using SierraWireless MC7430 and Huawei module without issues. I have recently changed to try a Telit 910 and a Quectel EG21-G and get : [ 47.020239] CPU: 0 PID: 427 Comm: ModemManager Not tainted 4.19.94 [ 47.020285] [] (unwind_backtrace) from [] (show_stack+0x20/0x24) [ 47.020309] [] (show_stack) from [] (dump_stack+0x8c/0xa0) [ 47.020328] [] (dump_stack) from [] (__warn.part.3+0xcc/0xe8) [ 47.020340] [] (__warn.part.3) from [] (warn_slowpath_fmt+0x78/0x94) [ 47.020355] [] (warn_slowpath_fmt) from [] (musb_h_tx_flush_fifo+0x148/0x14c) [ 47.020370] [] (musb_h_tx_flush_fifo) from [] (musb_cleanup_urb+0x88/0xf0) [ 47.020383] [] (musb_cleanup_urb) from [] (musb_urb_dequeue+0x1b0/0x1f0) [ 47.020401] [] (musb_urb_dequeue) from [] (unlink1+0x3c/0x11c) [ 47.020415] [] (unlink1) from [] (usb_hcd_unlink_urb+0x80/0xd8) [ 47.020429] [] (usb_hcd_unlink_urb) from [] (usb_kill_urb.part.4+0x50/0xdc) [ 47.020441] [] (usb_kill_urb.part.4) from [] (usb_kill_urb+0x38/0x3c) [ 47.020477] [] (usb_kill_urb) from [] (usb_wwan_close+0xcc/0xfc [usb_wwan]) [ 47.020577] [] (usb_wwan_close [usb_wwan]) from [] (serial_port_shutdown+0x30/0x34 [usbserial]) [ 47.020619] [] (serial_port_shutdown [usbserial]) from [] (tty_port_shutdown+0xa0/0xa4) [ 47.020634] [] (tty_port_shutdown) from [] (tty_port_close+0x4c/0x84) [ 47.020662] [] (tty_port_close) from [] (serial_close+0x34/0x5c [usbserial]) [ 47.020702] [] (serial_close [usbserial]) from [] (tty_release+0x100/0x60c) [ 47.020723] [] (tty_release) from [] (__fput+0x98/0x1e0) [ 47.020737] [] (__fput) from [] (fput+0x18/0x1c) [ 47.020758] [] (fput) from [] (task_work_run+0xa4/0xc0) [ 47.020773] [] (task_work_run) from [] (do_work_pending+0xfc/0x100) [ 47.020785] [] (do_work_pending) from [] (slow_work_pending+0xc/0x20) [ 47.020793] Exception stack(0xec821fb0 to 0xec821ff8) [ 47.020803] 1fa0: 0002 [ 47.020814] 1fc0: 000a 004d4298 0060fa88 0006 b6fee968 006348e0 [ 47.020824] 1fe0: 0006 bef63a20 b6a1d461 b6a1f526 80010030 000a [ 47.020832] ---[ end trace 18e5006eee0b2754 ]--- It seems to happen when ModemManager is scanning the modems. Could it be something to do with USB3 interface on the modem and timings ? The embedded platform is only USB2. Any update/info appreciated. Thanks in advance Marc ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Disabling radio interface on MBIM device
On Sun, 6 Dec 2020, Aleksander Morgado wrote: Date: Sun, 6 Dec 2020 08:51:55 From: Aleksander Morgado To: Enrico Mioso Cc: "ModemManager (development)" Subject: Re: Disabling radio interface on MBIM device Hey, On Fri, Dec 4, 2020 at 11:47 PM Enrico Mioso wrote: Hello!! I wanted to disable the radio interface on a device reported as: Bus 002 Device 003: ID 413c:81b6 Dell Computer Corp. DW5811e Snapdragon™ X7 LTE I would have liked something equivalent to AT+CFUN=0 but no serial port. So I used something like mbimcli -d /dev/cdc-wdm0 --set-radio-state=off and now mbimcli -d /dev/cdc-wdm0 --query-radio-state says: [/dev/cdc-wdm0] Radio state retrieved: Hardware radio state: 'on' Software radio state: 'off' Was I able to do what I wanted? Yes you did :) thanks a lot :) Enrico___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Disabling radio interface on MBIM device
Hello!! I wanted to disable the radio interface on a device reported as: Bus 002 Device 003: ID 413c:81b6 Dell Computer Corp. DW5811e Snapdragon™ X7 LTE I would have liked something equivalent to AT+CFUN=0 but no serial port. So I used something like mbimcli -d /dev/cdc-wdm0 --set-radio-state=off and now mbimcli -d /dev/cdc-wdm0 --query-radio-state says: [/dev/cdc-wdm0] Radio state retrieved: Hardware radio state: 'on' Software radio state: 'off' Was I able to do what I wanted? What is software vs hardware radio? I guess hw radio refers to locks e.g.: rfkill or something. Software radio means - radio turned off on software request. Am I wrong? Thanks!! Enrico___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Restrict modem (EC21) one of 3G or 4G - ModemManager 1.10.0 (Debian Buster)
BTW, Quectel EC25, I am not able to set allowed modes to 2g,3g,4g and preferred mode to any. Any solution? :D On Wed, 21 Oct 2020, Brendan Simon (eTRIX) wrote: Date: Wed, 21 Oct 2020 06:59:28 From: "Brendan Simon (eTRIX)" To: Aleksander Morgado Cc: "ModemManager (development)" Subject: Re: Restrict modem (EC21) one of 3G or 4G - ModemManager 1.10.0 (Debian Buster) On 19/08/2020 2:13 am, Aleksander Morgado wrote: This may be a known issue with QMI modems where the internal network registration attempt is done with "QMI NAS Register In Network"; this command not only registers in network, it also makes the access tech preference fallback to "any", and MM doesn't consider that in its API. There is a recent patch to avoid this, by avoiding the use of "NAS Register in Network" and use "NAS Set System Selection Preference" instead: https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/comm it/c70b3557184fdf1472ff0cb36e9fd937cc7f9024 That patch is not yet in any release, though, not even in 1.14.0. I'll backport it to the 1.14.x branch so that it gets into 1.14.2. So the 64 million dollar question is when is 1.14.2 likely to be released ? Sometime in the next few weeks I'd say. So it's been a while, but I now have MM 1.14.2 installed on my embedded system via Debian Buster Backports repo. I can successfully set the allowed mode to "3G" and get a UMTS connection. mmcli -m 0 --set-allowed-modes="3G" However, if I try to lock to 4G the connection never succeeds. mmcli -m 0 --set-allowed-modes="4G" The only way I can get an LTE connection is with the following. mmcli -m 0 --set-allowed-modes="3G|4G" --set-preferred-mode=4G I presume this is a bug? But maybe there is something else going on? Any ideas or suggestions to get an LTE connection with setting 4G as the only allowed mode? Also, I've just noticed that 1.14.6 has just hit the Buster Backport repo. I'm not sure if that will help or not, but I don't see anything in the NEWS file that would suggest a change in this area. https://github.com/freedesktop/ModemManager/blob/mm-1-14/NEWS Thanks, Brendan. ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Rejected Send Message when starting with paranoid as argument
Hello!! I don't know how to help you out, but I would suggest you to try out a more recent version of MM (e.g.: 1.12 or 1.14 ? ). Enrico ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: ModemManager crash with more than one call with Huawei E3131 Modem
Thank you very very much for your great work, as always Aleksander. BTW- maybe something interesting is happening here: [mrkiko@mStation ~]$ mmcli -o 44 --start error: couldn't start the call: 'GDBus.Error:org.freedesktop.ModemManager1.Error.Core.Failed: Couldn't start the call: Unhandled response '^CCALLSTATE: 1,4'' but in reality call started anyway, without MM knowing it. Thank you for all Aleksander. enrico On Thu, 21 May 2020, Aleksander Morgado wrote: Date: Thu, 21 May 2020 15:12:57 From: Aleksander Morgado To: Enrico Mioso Cc: "ModemManager (development)" , marco.perini1...@gmail.com Subject: Re: ModemManager crash with more than one call with Huawei E3131 Modem Hey Enrico, I am experiencing a crash in Modemmanager, triggered by the following scenario: 1 - Start a voice call from mmcli to my mobile phone. 2 - Answer the call there. 3 - From the mobile phone, call back my Huawei E3131 device. This results in the following crash: let me know if I can help out more. While I could write a quick fix for this issue, just replacing a g_assert() by a if() check, I do need to understand fully how the situation happened, because I did really expect the g_assert() to always succeed. Will let you know. I've understood how it happened, and the fix is indeed just to change the assert with an if(), because it really is an expected usecase. The problem happened because in load_call_list_ready() we call mm_iface_modem_voice_report_all_calls() before the assert() was checked, and in that report_all_calls() method we may be detecting new incoming calls that would trigger setting the call polling timeout as well. I've pushed a new fix for this already that will get to git master soon and then I'll backport it to the 1.12.x branch: https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/284 These are the relevant commits from your log: ModemManager[417212]: [1589977056.106485] 1 calls being established: call list polling required ctx->polling_ongoing = TRUE; load_call_list() load_call_list_ready() ctx->polling_ongoing = FALSE; ModemManager[417212]: [1589977056.106550] (ttyUSB2) device open count is 3 (open) ModemManager[417212]: [1589977056.106624] (ttyUSB2): --> 'AT+CLCC' ModemManager[417212]: [1589977056.116273] (ttyUSB2): <-- '+CLCC: 1,0,0,0,0,"39",145,"",+CLCC: 2,1,5,0,0,"39",145,"",OK' mm_iface_modem_voice_report_all_calls() New call added, setup_call_list_polling() is executed, which ends up setting up the call_list_poll() timeout. ModemManager[417212]: [1589977056.116495] Reported 2 ongoing calls ModemManager[417212]: [1589977056.116516] call at index 1: direction outgoing, state active, number 39 ModemManager[417212]: [1589977056.116525] call at index 2: direction incoming, state waiting, number 39 ModemManager[417212]: [1589977056.116550] call info matched (matched direction/state no, matched number yes, matched index no, matched terminated no) with call at '/org/freedesktop/ModemManager1/Call/1' ModemManager[417212]: [1589977056.116566] index set: 1 ModemManager[417212]: [1589977056.116578] state updated: active ModemManager[417212]: [1589977056.116590] Call state changed: waiting -> active (unknown) ModemManager[417212]: [1589977056.116727] incoming refreshed ModemManager[417212]: [1589977056.116750] Call '/org/freedesktop/ModemManager1/Call/0' with direction outgoing, state active, number '+39', index 1 not found in list, terminating ModemManager[417212]: [1589977056.116767] Call state changed: active -> terminated (unknown) ModemManager[417212]: [1589977056.116868] Creating new incoming call... ModemManager[417212]: [1589977056.116972] Call state changed: unknown -> waiting (incoming-new) ModemManager[417212]: [1589977056.117054] Added call at '/org/freedesktop/ModemManager1/Call/2' ** ERROR:mm-iface-modem-voice.c:2376:load_call_list_ready: assertion failed: (!ctx->polling_id) Bail out! ERROR:mm-iface-modem-voice.c:2376:load_call_list_ready: assertion failed: (!ctx->polling_id) -- Aleksander https://aleksander.es ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: ModemManager crash with more than one call with Huawei E3131 Modem
This is the debug session with the failed assert. ModemManager[417212]: [1589976952.411557] ModemManager (version 1.12.10) starting in system bus... ModemManager[417212]: [1589976952.412074] create MMSleepMonitor singleton (0x557e57d47750) ModemManager[417212]: [1589976952.413120] Bus acquired, creating manager... ModemManager[417212]: [1589976952.414553] [filter] created ModemManager[417212]: [1589976952.414570] [filter] explicit whitelist: yes ModemManager[417212]: [1589976952.414576] [filter] explicit blacklist: yes ModemManager[417212]: [1589976952.414580] [filter] plugin whitelist: yes ModemManager[417212]: [1589976952.414587] [filter] virtual devices forbidden: yes ModemManager[417212]: [1589976952.414594] [filter] net devices allowed:yes ModemManager[417212]: [1589976952.414600] [filter] cdc-wdm devices allowed:yes ModemManager[417212]: [1589976952.414608] [filter] tty devices: ModemManager[417212]: [1589976952.414615] [filter] blacklist applied:no ModemManager[417212]: [1589976952.414623] [filter] manual scan only applied: no ModemManager[417212]: [1589976952.414632] [filter] platform driver check:yes ModemManager[417212]: [1589976952.414639] [filter] driver check: yes ModemManager[417212]: [1589976952.414646] [filter] cdc-acm interface check: yes ModemManager[417212]: [1589976952.414655] [filter] with net check: yes ModemManager[417212]: [1589976952.414663] [filter] default: forbidden ModemManager[417212]: [1589976952.414699] [plugin manager] looking for plugins in '/usr/lib/ModemManager' ModemManager[417212]: [1589976952.414917] [plugin manager] loaded shared 'Xmm' utils from '/usr/lib/ModemManager/libmm-shared-xmm.so' ModemManager[417212]: [1589976952.415052] [plugin manager] loaded shared 'Sierra' utils from '/usr/lib/ModemManager/libmm-shared-sierra.so' ModemManager[417212]: [1589976952.415184] [plugin manager] loaded shared 'Telit' utils from '/usr/lib/ModemManager/libmm-shared-telit.so' ModemManager[417212]: [1589976952.415252] [plugin manager] loaded shared 'Option' utils from '/usr/lib/ModemManager/libmm-shared-option.so' ModemManager[417212]: [1589976952.415372] [plugin manager] loaded shared 'Icera' utils from '/usr/lib/ModemManager/libmm-shared-icera.so' ModemManager[417212]: [1589976952.415446] [plugin manager] loaded shared 'Novatel' utils from '/usr/lib/ModemManager/libmm-shared-novatel.so' ModemManager[417212]: [1589976952.415606] [plugin manager] loaded plugin 'AnyDATA' from '/usr/lib/ModemManager/libmm-plugin-anydata.so' ModemManager[417212]: [1589976952.415716] [plugin manager] loaded plugin 'Linktop' from '/usr/lib/ModemManager/libmm-plugin-linktop.so' ModemManager[417212]: [1589976952.415800] [plugin manager] loaded plugin 'Quectel' from '/usr/lib/ModemManager/libmm-plugin-quectel.so' ModemManager[417212]: [1589976952.415934] [plugin manager] loaded plugin 'u-blox' from '/usr/lib/ModemManager/libmm-plugin-ublox.so' ModemManager[417212]: [1589976952.416090] [plugin manager] loaded plugin 'Huawei' from '/usr/lib/ModemManager/libmm-plugin-huawei.so' ModemManager[417212]: [1589976952.416208] [plugin manager] loaded plugin 'SimTech' from '/usr/lib/ModemManager/libmm-plugin-simtech.so' ModemManager[417212]: [1589976952.416271] [plugin manager] loaded plugin 'Option' from '/usr/lib/ModemManager/libmm-plugin-option.so' ModemManager[417212]: [1589976952.416340] [plugin manager] loaded plugin 'Nokia (Icera)' from '/usr/lib/ModemManager/libmm-plugin-nokia-icera.so' ModemManager[417212]: [1589976952.416445] [plugin manager] loaded plugin 'Altair LTE' from '/usr/lib/ModemManager/libmm-plugin-altair-lte.so' ModemManager[417212]: [1589976952.416455] [filter] registered plugin whitelist product id: 216f:0047 ModemManager[417212]: [1589976952.416532] [plugin manager] loaded plugin 'Wavecom' from '/usr/lib/ModemManager/libmm-plugin-wavecom.so' ModemManager[417212]: [1589976952.416591] [plugin manager] loaded plugin 'Haier' from '/usr/lib/ModemManager/libmm-plugin-haier.so' ModemManager[417212]: [1589976952.416661] [plugin manager] loaded plugin 'Via CBP7' from '/usr/lib/ModemManager/libmm-plugin-via.so' ModemManager[417212]: [1589976952.416727] [plugin manager] loaded plugin 'Novatel' from '/usr/lib/ModemManager/libmm-plugin-novatel.so' ModemManager[417212]: [1589976952.416801] [plugin manager] loaded plugin 'X22X' from '/usr/lib/ModemManager/libmm-plugin-x22x.so' ModemManager[417212]: [1589976952.416811] [filter] registered plugin whitelist tag: ID_MM_X22X_TAGGED ModemManager[417212]: [1589976952.416899] [plugin manager] loaded plugin 'Dell' from '/usr/lib/ModemManager/libmm-plugin-dell.so' ModemManager[417212]: [1589976952.416961] [plugin manager] loaded plugin 'Generic' from '/usr/lib/ModemManager/libmm-plugin-generic.so' ModemManager[417212]:
ModemManager crash with more than one call with Huawei E3131 Modem
Hello!! I am experiencing a crash in Modemmanager, triggered by the following scenario: 1 - Start a voice call from mmcli to my mobile phone. 2 - Answer the call there. 3 - From the mobile phone, call back my Huawei E3131 device. This results in the following crash: let me know if I can help out more. May 20 14:08:49 mStation ModemManager[417132]: Modem /org/freedesktop/ModemManager1/Modem/0: state changed (enabled -> registered) May 20 14:09:06 mStation ModemManager[417132]: user request to start call May 20 14:09:06 mStation ModemManager[417132]: Call state changed: unknown -> dialing (outgoing-started) May 20 14:09:06 mStation ModemManager[417132]: call is started May 20 14:09:07 mStation ModemManager[417132]: Call state changed: dialing -> ringing-out (unknown) May 20 14:09:16 mStation ModemManager[417132]: Call state changed: ringing-out -> active (unknown) May 20 14:09:47 mStation ModemManager[417132]: Call state changed: unknown -> waiting (incoming-new) May 20 14:09:50 mStation ModemManager[417132]: Call state changed: waiting -> active (unknown) May 20 14:09:50 mStation ModemManager[417132]: Call state changed: active -> terminated (unknown) May 20 14:09:50 mStation ModemManager[417132]: Call state changed: unknown -> waiting (incoming-new) May 20 14:09:50 mStation ModemManager[417132]: Bail out! ERROR:mm-iface-modem-voice.c:2376:load_call_list_ready: assertion failed: (!ctx->polling_id) May 20 14:09:50 mStation systemd[1]: Started Process Core Dump (PID 417153/UID 0). May 20 14:09:50 mStation systemd[417154]: systemd-coredump@14-417153-0.service: PrivateNetwork=yes is configured, but the kernel does not support network namespaces, ignoring. May 20 14:09:50 mStation systemd[417154]: systemd-coredump@14-417153-0.service: ProtectHostname=yes is configured, but the kernel does not support UTS namespaces, ignoring namespace setup. May 20 14:09:50 mStation systemd[1]: ModemManager.service: Main process exited, code=dumped, status=6/ABRT May 20 14:09:50 mStation systemd[1]: ModemManager.service: Failed with result 'core-dump'. May 20 14:09:50 mStation systemd-coredump[417154]: Process 417132 (ModemManager) of user 0 dumped core. Stack trace of thread 417132: #0 0x7f4a357ee2e5 raise (libc.so.6 + 0x3c2e5) #1 0x7f4a357d7853 abort (libc.so.6 + 0x25853) #2 0x7f4a359d9096 g_assertion_message (libglib-2.0.so.0 + 0x3e096) #3 0x7f4a359d931d g_assertion_message_expr (libglib-2.0.so.0 + 0x3e31d) #4 0x55f113cddfe1 load_call_list_ready (ModemManager + 0x79fe1) #5 0x7f4a35b8f395 g_task_return_now (libgio-2.0.so.0 + 0xa6395) #6 0x7f4a35b93a96 g_task_return (libgio-2.0.so.0 + 0xaaa96) #7 0x55f113ce52c6 clcc_ready (ModemManager + 0x812c6) #8 0x7f4a35ba6f37 g_simple_async_result_complete (libgio-2.0.so.0 + 0xbdf37) #9 0x55f113cb6ebf at_command_ready (ModemManager + 0x52ebf) #10 0x7f4a35ba6f37 g_simple_async_result_complete (libgio-2.0.so.0 + 0xbdf37) #11 0x55f113d317f3 serial_command_ready (ModemManager + 0xcd7f3) #12 0x7f4a35ba6f37 g_simple_async_result_complete (libgio-2.0.so.0 + 0xbdf37) #13 0x55f113d2e2fe command_context_complete_and_free (ModemManager + 0xca2fe) #14 0x55f113d2f03c port_serial_got_response (ModemManager + 0xcb03c) #15 0x55f113d30b90 parse_response_buffer (ModemManager + 0xccb90) #16 0x7f4a359f1640 g_main_dispatch (libglib-2.0.so.0 + 0x56640) #17 0x7f4a359f2d99 g_main_context_iterate (libglib-2.0.so.0 + 0x57d99) #18 0x7f4a359f3ca5 g_main_loop_run (libglib-2.0.so.0 + 0x58ca5) #19 0x55f113ca42ff main (ModemManager + 0x402ff) #20 0x7f4a357d9002 __libc_start_main (libc.so.6 + 0x27002) #21 0x55f113ca446e _start (ModemManager + 0x4046e) Stack
Re: Problem passing user_data in MMCall object state-changed signal
Oh, you're so much right!! :D
Thanks, sorry...
Enrico
On Wed, 20 May 2020, Aleksander Morgado wrote:
Date: Wed, 20 May 2020 13:31:51
From: Aleksander Morgado
To: Enrico Mioso
Cc: "ModemManager (development)" ,
marco.perini1...@gmail.com
Subject: Re: Problem passing user_data in MMCall object state-changed signal
Hey
I am experiencing a strange issue with state-changed GSignal of MMCall object.
In particular, my user-data is not passed, instead a pointer with an address
like 0x01, at least so it seems via GDB.
I connect my GSignal this way:
call_statechange_signal = g_signal_connect(c, "state-changed",
G_CALLBACK(av_mm_call_statechange), m);
where m is my AvModem object.
My callback looks like:
static void av_mm_call_statechange(MMCall *c, MMCallState oldstate, MMCallState
newstate, AvModem *m) {
...
}
Do you have any hints?
You're missing the "reason" parameter, see the docs:
https://www.freedesktop.org/software/ModemManager/libmm-glib/1.6.0/MmGdbusCall.html#MmGdbusCall-state-changed
--
Aleksander
https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Problem passing user_data in MMCall object state-changed signal
Hello!!
I am experiencing a strange issue with state-changed GSignal of MMCall object.
In particular, my user-data is not passed, instead a pointer with an address
like 0x01, at least so it seems via GDB.
I connect my GSignal this way:
call_statechange_signal = g_signal_connect(c, "state-changed",
G_CALLBACK(av_mm_call_statechange), m);
where m is my AvModem object.
My callback looks like:
static void av_mm_call_statechange(MMCall *c, MMCallState oldstate, MMCallState
newstate, AvModem *m) {
...
}
Do you have any hints?
Thank you !!
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Correct connection sequence to maximize chances of e.g.: getting connected :)
Oh, sorry. It makes sense due to the way C structs work, so i may use
struct _AvModem {
MMObject mmobject;
/* other members */
};
Still, if all is OK I should be able to do something like:
mm_object_get_modem(MM_OBJECT(m));
or am I mistaken?
currently, this fails...
thanks again,
Enrico
On Thu, 7 May 2020, Enrico Mioso wrote:
Date: Thu, 7 May 2020 15:59:44
From: Enrico Mioso
To: Aleksander Morgado
Cc: "ModemManager (development)" ,
marco.perini1...@gmail.com
Subject: Re: Correct connection sequence to maximize chances of e.g.: getting
connected :)
Ok, now things are a little bit clearer. However, when running my test code I
face the issue:
Creating object:
(process:45799): GLib-GObject-WARNING **: 15:52:57.565: specified instance
size for type 'AvModem' is smaller than the parent type's 'GObject' instance
size
(process:45799): GLib-CRITICAL **: 15:52:57.565: g_once_init_leave: assertion
'result != 0' failed
(process:45799): GLib-GObject-CRITICAL **: 15:52:57.565:
g_object_new_with_properties: assertion 'G_TYPE_IS_OBJECT (object_type)'
failed
(process:45799): GLib-GObject-CRITICAL **: 15:52:57.565: g_object_unref:
assertion 'G_IS_OBJECT (object)' failed
I guess I am missing some details about declaring MMObjectclass is my parent
class.
I can't understand them from the GObjects doc, even tough they seem pretty
well written, once you grasp the context.
With final type I was able to drop some code. Now my objecct skel looks as
follows:
/* header */
#ifndef __main_h__
#define __main_h__
#include
#include
G_BEGIN_DECLS
#define AV_TYPE_MODEM av_modem_get_type()
G_DECLARE_FINAL_TYPE(AvModem, av_modem, AV, MODEM, GObject)
AvModem *av_modem_new(void);
G_END_DECLS
#endif
/* source */
#include
#include
#include
struct _AvModem {
MMObject *mmobject;
/* other members */
};
G_DEFINE_TYPE(AvModem, av_modem, G_TYPE_OBJECT)
static void av_modem_init(AvModem *self) {
g_print("%s invoked\n",__FUNCTION__);
/* here we would g_object_new and things */
/* initialize all public and private members to reasonable default
values.
* They are all automatically initialized to 0 to begin with. */
}
static void av_modem_dispose(GObject *gobject) {
g_print("%s invoked\n",__FUNCTION__);
/* In dispose(), you are supposed to free all types referenced from
this
* object which might themselves hold a reference to self. Generally,
* the most simple solution is to unref all members on which you own
a
* reference.
*/
/* time to g_object_clear things */
G_OBJECT_CLASS (av_modem_parent_class)->dispose (gobject);
}
static void av_modem_finalize(GObject *gobject) {
g_print("%s invoked\n",__FUNCTION__);
/* e.g.: g_free for filename */
G_OBJECT_CLASS (av_modem_parent_class)->finalize (gobject);
}
static void av_modem_class_init(AvModemClass *klass) {
g_print("%s invoked\n",__FUNCTION__);
GObjectClass *object_class = G_OBJECT_CLASS (klass);
object_class->dispose = av_modem_dispose;
object_class->finalize = av_modem_finalize;
}
AvModem *av_modem_new(void) {
AvModem *m;
m = g_object_new(AV_TYPE_MODEM, NULL);
return m;
}
gint main(void) {
AvModem *m;
g_print("Creating object:\n");
m = av_modem_new();
g_object_unref(m);
return 0;
}
It works if I use
MMObject m;
instead of *m as my _AvModem struct member, which is not the right solution I
know...
Second, the final objective is to have
AvModem *av_modem_new(MMObject *m);
And I guess inside the function I can use a simple assignment due to the fact
the compiler still knows the structure in the C file.
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Bearer MTU not recognised by NetworkManager
Hi!! The relevant code is in NetworkManager/src/devices/wwan . In my impression NM doesn't ask MM for the MTU, using it's own (default) values for that. Note that it's only my impression from a superficial look. Hence, assuming I am right, I guess this isn't a MM related issue. Enrico On Thu, 7 May 2020, Sven Schwermer wrote: Date: Thu, 7 May 2020 15:43:51 From: Sven Schwermer To: "ModemManager (development)" Subject: Bearer MTU not recognised by NetworkManager Hi, I’m observing that NetworkManager (v1.20.2) does not recognise the MTU (=1360) exposed by the ModemManager’s (v1.10.6) bearer object and instead uses some default value (=1500). This seems to lead to issues which are fixed when manually setting the MTU to a lower value. When checking the NetworkManager’s connection settings, gsm.mtu is set to “auto". I’m observing this on a Quectel BG96 hooked up via QMI. My kernel version is 4.19.87. Is this a known issue? Is anyone aware whether this is fixed upstream? Thanks, Sven ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Correct connection sequence to maximize chances of e.g.: getting connected :)
Ok, now things are a little bit clearer. However, when running my test code I
face the issue:
Creating object:
(process:45799): GLib-GObject-WARNING **: 15:52:57.565: specified instance size
for type 'AvModem' is smaller than the parent type's 'GObject' instance size
(process:45799): GLib-CRITICAL **: 15:52:57.565: g_once_init_leave: assertion
'result != 0' failed
(process:45799): GLib-GObject-CRITICAL **: 15:52:57.565:
g_object_new_with_properties: assertion 'G_TYPE_IS_OBJECT (object_type)' failed
(process:45799): GLib-GObject-CRITICAL **: 15:52:57.565: g_object_unref:
assertion 'G_IS_OBJECT (object)' failed
I guess I am missing some details about declaring MMObjectclass is my parent
class.
I can't understand them from the GObjects doc, even tough they seem pretty well
written, once you grasp the context.
With final type I was able to drop some code. Now my objecct skel looks as
follows:
/* header */
#ifndef __main_h__
#define __main_h__
#include
#include
G_BEGIN_DECLS
#define AV_TYPE_MODEM av_modem_get_type()
G_DECLARE_FINAL_TYPE(AvModem, av_modem, AV, MODEM, GObject)
AvModem *av_modem_new(void);
G_END_DECLS
#endif
/* source */
#include
#include
#include
struct _AvModem {
MMObject *mmobject;
/* other members */
};
G_DEFINE_TYPE(AvModem, av_modem, G_TYPE_OBJECT)
static void av_modem_init(AvModem *self) {
g_print("%s invoked\n",__FUNCTION__);
/* here we would g_object_new and things */
/* initialize all public and private members to reasonable default
values.
* They are all automatically initialized to 0 to begin with. */
}
static void av_modem_dispose(GObject *gobject) {
g_print("%s invoked\n",__FUNCTION__);
/* In dispose(), you are supposed to free all types referenced from this
* object which might themselves hold a reference to self. Generally,
* the most simple solution is to unref all members on which you own a
* reference.
*/
/* time to g_object_clear things */
G_OBJECT_CLASS (av_modem_parent_class)->dispose (gobject);
}
static void av_modem_finalize(GObject *gobject) {
g_print("%s invoked\n",__FUNCTION__);
/* e.g.: g_free for filename */
G_OBJECT_CLASS (av_modem_parent_class)->finalize (gobject);
}
static void av_modem_class_init(AvModemClass *klass) {
g_print("%s invoked\n",__FUNCTION__);
GObjectClass *object_class = G_OBJECT_CLASS (klass);
object_class->dispose = av_modem_dispose;
object_class->finalize = av_modem_finalize;
}
AvModem *av_modem_new(void) {
AvModem *m;
m = g_object_new(AV_TYPE_MODEM, NULL);
return m;
}
gint main(void) {
AvModem *m;
g_print("Creating object:\n");
m = av_modem_new();
g_object_unref(m);
return 0;
}
It works if I use
MMObject m;
instead of *m as my _AvModem struct member, which is not the right solution I
know...
Second, the final objective is to have
AvModem *av_modem_new(MMObject *m);
And I guess inside the function I can use a simple assignment due to the fact
the compiler still knows the structure in the C file.
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Correct connection sequence to maximize chances of e.g.: getting connected :)
thank you very very much!! Really.
Enrico
On Thu, 7 May 2020, Aleksander Morgado wrote:
Date: Thu, 7 May 2020 09:34:46
From: Aleksander Morgado
To: Enrico Mioso
Cc: "ModemManager (development)" ,
marco.perini1...@gmail.com
Subject: Re: Correct connection sequence to maximize chances of e.g.: getting
connected :)
Hey!
Sorry for deleting the quoted text every time, but without doing so, answers
may result complicated to read confortably for me.
So, in the end I came to the conclusion that using GObjects is probably the
best course of cation :)
So I am studying the GLib GObjects page for details, and started writing some
code to try to understand things better.
Goal: implement a GObject who can act as a container for:
- MMObjects, MMModem objects, MMModemVoice objects
- (long) integers for GSignals handlers and other data.
I managed to get my code to compile, but would like some hints /
recommendations on how I may proceed.
Ok.
My header:
#ifndef __main_h__
#define __main_h__
#include
#include
G_BEGIN_DECLS
#define AV_TYPE_MODEM av_modem_get_type()
G_DECLARE_DERIVABLE_TYPE(AvModem, av_modem, AV, MODEM, GObject)
In your case, you're probably not going to create subclasses of the
AvModem object, so you can easier use G_DECLARE_FINAL_TYPE and
completely avoid the need of having a "private" struct. With final
types, you can have all your internal data in the AvModem struct
itself.
struct _AvModemClass {
MMObjectClass parent_class;
/* functions ... */
The functions in the class are only needed if you're going to subclass
the class, which you're not going to.
/* padding with things like
gpointer padding[12];
*/
And padding is only required if you're making this class "public", in
order to leave some safe space to grow the class in the future. You
can also ignore this.
};
AvModem *av_modem_new(void);
G_END_DECLS
#endif
Source:
#include
#include
#include
typedef struct {
gchar *filename;
} AvModemPrivate;
As said, if you use a final type you could add the filename variable
in the AvModem struct itself in the header. The ModemManager sources
don't do this because these macros were introduced in newer GLib
versions; we could probably do some porting now that we require newer
releases as well.
G_DEFINE_TYPE_WITH_PRIVATE (AvModem, av_modem, G_TYPE_OBJECT)
static void av_modem_init(AvModem *self) {
g_print("__FUNCTION__ invoked\n");
AvModemPrivate *priv = av_modem_get_instance_private(self);
/* here we would g_object_new and things */
/* initialize all public and private members to reasonable default
values.
* They are all automatically initialized to 0 to begin with. */
}
static void av_modem_dispose(GObject *gobject) {
g_print("__FUNCTION__ invoked\n");
AvModemPrivate *priv = av_modem_get_instance_private(AV_MODEM(gobject));
/* In dispose(), you are supposed to free all types referenced from this
* object which might themselves hold a reference to self. Generally,
* the most simple solution is to unref all members on which you own a
* reference.
*/
/* time to g_object_clear things */
Yes. It's very important that pointers in dispose() are re-set to NULL
after freeing. E.g. use g_clear_object(), g_clear_pointer() and such.
This is because dispose may be called multiple times.
G_OBJECT_CLASS (av_modem_parent_class)->dispose (gobject);
}
static void av_modem_finalize(GObject *gobject) {
g_print("__FUNCTION__ invoked\n");
AvModemPrivate *priv = av_modem_get_instance_private(AV_MODEM(gobject));
/* e.g.: g_free for filename */
Finalize is only called once, so no need to re-set pointers to NULL
after freeing.
G_OBJECT_CLASS (av_modem_parent_class)->finalize (gobject);
}
static void av_modem_class_init(AvModemClass *klass) {
g_print("__FUNCTION__ invoked\n");
GObjectClass *object_class = G_OBJECT_CLASS (klass);
object_class->dispose = av_modem_dispose;
object_class->finalize = av_modem_finalize;
}
gint main(void) {
return 0;
}
I see you use various convenience macros in libmm-glib headers, but I am trying
to do things step by step to understand them.
The convenience macros are probably older GLib macros. The new macros
require less amount of them.
I may have used GBoxed to wrap my own structs instead, but I am trying to do
what's better.
You only need GBoxed for your own structs if they're going to be set
as object properties.
I absoulutely need refcounting in this scenario. :)
Yes! (which is good)
--
Aleksander
https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Correct connection sequence to maximize chances of e.g.: getting connected :)
Hello Aleksander!! Thank you again for your amazing ModemManager work!! I would like to ask some advice for Voice calls handling. I will at some point get a MMModemVoice to which I'll connect some GSignals to keep track of when new call objects are added and removed (e.g.: via mmcli). My callbacks will be invoked with the MMModemVoice object as argument, and the const gchar path of the object itself. Should I implement a search function where I get the calls list and search for the call with that path as object, like it's done for SMS here: https://source.puri.sm:443/Librem5/purple-mm-sms or is there another way to get a MMCall object directly? I remembered trying to get such an object various ways but didn't find the correct solution. Second, I guess that the "marshallers" for these GSignals, like the ones for SMS messages, don't provide for a way to pass user_data around. am I wrong? Should I recur to static variables in the C file ? Or is there a different possible solution? Thank you very very much for your work, nd patience again. Enrico ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Correct connection sequence to maximize chances of e.g.: getting connected :)
Hey all!! Sorry, last time I bother you I hope. :) Gegarding audio ports- in udev I can't find any hint about the device I am currently using for testing, a Huawei E3131 dongle. Should I tag the audio port myself like I see in other cases? And, how will I be able to access that information from within my program? should I use libgudev or something like that? thank you very very much again, and sorry for those questions. Enrico ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Correct connection sequence to maximize chances of e.g.: getting connected :)
On Thu, 30 Apr 2020, Aleksander Morgado wrote: ... My question is, why do you really want to make sure all async operations are finished when the program quits. Do you truly need that? If you do need that, then once the program is told to quit, you should launch the "program cancellation logic" which would cancel the program-wide cancellable, and then wait until all async operations are finished. You may for example keep a counter of the async operations you're running concurrently, and once it reaches 0 (meaning all async operations finished) then you would be able to cleanly stop the mainloop at that point. Don't know, something like that. ... If the async operation doesn't support GCancellable, you cannot do anything. If the async operation supports GCancellable, it is (usually) guaranteed that the async operation will finish with a G_IO_ERROR_CANCELLED error. But, there is no guarantee that cancelling a cancellable will make the async operation actually get cancelled earlier! Some operations allow that (e.g. a network scan) but some others will just wait for the operation to finish normally but then returning a cancelled error instead of whatever the result of the async operation was. Thank you very very much Aleksander. Well, in my previous codebase I needed that to ensure no already freed memory was accessed. But if I only operate on GObjects I should be fine, I guess. because any async operation in libmm-glib will have to take it's own object reference, so I can unref mine and all should be fine in the end, most of the times. Thanks again, and sorry for the multitude of questions. ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Correct connection sequence to maximize chances of e.g.: getting connected :)
Hello Aleksander!! thank you again! So - i was considering using a GList of my own structs to track down objects and maintain it when observing state transitions. Now I was wondering how to manage: - async operation concurrency: am I guaranteed only a single async operation runs? Or should I lock somehow the list? - software shutdown: - I will have to unref all my objects somehow - mainloop exiting should be the last thing I do but I should be sure all async operations are complete when I quit my program, and I know the answer: GCAncellable. :) :) But at the moment it's not clear to me how I might use that to make sure that when the program quits, all async operations are cancelled, and no other are pending. I did have a look at mmcli use of GCancellables, but it's not clear to me how I might use them when I only use, and not implement, async ops, amongst other things. Thanks!! Enrico ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Correct connection sequence to maximize chances of e.g.: getting connected :)
thank you very very much for your reply! What do you mean by a "signel GObject"? A list ? Or building a new GObject type on my own? And, secondly, is there a way to obtain the audio port from MM? In my setup, ttyUSB0 and ttyUSB2 are marked as AT port, audio is ttyUSB1. thank you very very much Aleksander for your precious work, and patience. Enrico ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Correct connection sequence to maximize chances of e.g.: getting connected :)
Hello!! So, due to some issues I will have to rewrite my code from scratch anyway. And so this time I am doing it with a different use-case in mind. I should monitor incoming and outgoing voice calls for a modem. How may I manage objects lifetime, assuming ModemManager and the modem may disappear from underneath at any time? Answer I found: GTasks: I may use them to construct piece by piece the needed context and proceed chaining async operations. So, when I see MM appear in the bus I may start a GTask to construct all the needed context to start monitoring calls. but I want to do it for every modem in the system, maybe more than one. Or, better, I would do it in general fashion. How do I track MMModems and MMVoice objects in this case, since I need to keep them around to receive their GSignals? GTasks should help me manage the destruction of objects I am using temporarily, but how about objects I need to keep until a given modem physically disconnects and/or MM is closed for some reason? Thank you very very much, enrico ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: OpenWrt: unexpected disconnect requiring manual restart of ModemManager
sorry for the intrustion and for going over this again but... You mentioned the Librem5 and it's use of MM. I was wondering if I could use one of my QMI modems to do phone calls. I seen the voice interfaces, but audio routing remains a mistery to me even today. :) E see there are projects like: https://source.puri.sm/Librem5/wys ... but, it seems it relies on the fact the SIMCOM modems exposes an ALSA-compatible PCM interface, right? but, is there a way to use a QMI modem as a phone? What about audio routing specifically? Or is this modem-specific and, does it in general require particular firmware or some hardware connected to the module for audio? thanks! And sorry again for the intrusion ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Correct connection sequence to maximize chances of e.g.: getting connected :)
Hello all!! So, I was following this ML lately, to notice I am not the only one having the issue of modem not being able to establish a connection sometimes, with errors like "Call failed". I seen that error many times. I will for sure need to dig deeper into this, but my question was more generic, like: what's the proper sequence one has to follow to maximize chances of "resetting" the modemstate so that it can get connected with a given configuration? My following flow of actions looks as follows: (-> = modem transitions from "lower" to "higher" state, >- = modem transitions from "higher" to "lower" state, - = action being taken, * = initial state) * the modem is in "locked" state: - try to unlock it -> modem is in disabled state - if software isn't exiting, then: - delete all of the bearers pertaining to this modem - enable modem -> modem enabled - here one may wait for the modem to get registered, as it happens normally; however, sometimes, explicitly asking the modem to register seems to be needed - if no bearers exist at this time, then create all configured bearers, and start a periodic checker that connects created bearers - modem enabled - here one may wait for the modem to get registered, as it happens normally; however, sometimes, explicitly asking the modem to register seems to be needed -> modem connected - we are happy I added the bearer checker because I found no way to be able to unref objects in cases where the modem may be removed in some cases. What I can observe is that, even for the same model of modem module, in some cases all goes as expected and connection comes up in the first attempt, or in one of the first 2 / 3 attempts. In some other cases, I get a storm of "CallFailed" errors, and simply can't bring up the connection unless: a - i reset the modem via mmcli b - just wait We went as far as getting QMI message timeouts in some cases, but that's another problem. What's the best strategy to connect a modem as per user configuration when we "get" one visible in ModemManager? My phone is able to do this all of the time, judging from it's speed, so why can't we? :) ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: (Polkit issue) allowing anyone, or a specific user, to perform actions on Modems
Thank you very very much It does work! :) As per Polkit, I don't apreciate it very much either, even tough I guess it's, effectively, because of your same reason. Thank you very very much, really. Enrico On Sun, 2 Feb 2020, Bjørn Mork wrote: Date: Sun, 2 Feb 2020 12:50:52 From: Bjørn Mork To: Enrico Mioso Cc: modemmanager-devel@lists.freedesktop.org Subject: Re: (Polkit issue) allowing anyone, or a specific user, to perform actions on Modems 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: 42-miraculix.pkla,v 1.5 2018/03/22 19:54:49 bjorn Exp $ # # Configuration file for the PolicyKit Local Authority. # # See the pklocalauthority(8) man page for more information # about configuring the Local Authority. # [Network Manager] Identity=unix-group:netdev Action=org.freedesktop.NetworkManager.* ResultAny=yes ResultInactive=yes ResultActive=yes [Modem Manager] Identity=unix-group:netdev Action=org.freedesktop.ModemManager1.* ResultAny=yes ResultInactive=yes ResultActive=yes Using 'Identity=unix-user:*' instead should allow any user. In theory. But who knows. To be honest, I hate the polkit complexity. Probably because I have never cared enough to spend the necessary time reading all the docs and default policy files etc. But I wonder: Who does that? Bjørn ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
(Polkit issue) allowing anyone, or a specific user, to perform actions on Modems
Hello ! the subjct says it all! Thanks guys!! :) Enrico ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: ModemManager and modems discovery in OpenWRt
With the maintained in-tree version of MM I wasn't able to break it again. Sorry... Anyway this patch seems good to me and hope openwrt guys can incorporate it ASAP. On Wed, 20 Nov 2019, Aleksander Morgado wrote: Date: Wed, 20 Nov 2019 13:16:06 From: Aleksander Morgado To: Enrico Mioso Cc: "ModemManager (development)" , Bjørn Mork Subject: Re: ModemManager and modems discovery in OpenWRt On Mon, Nov 18, 2019 at 2:37 PM Enrico Mioso wrote: Ok, I'll now will try to see if i can break it. Could this patch maybe fix the issue you were having with the protocol caches? https://github.com/openwrt/packages/pull/10597/commits/ec016ce20d0690193e26c3b558948c8ae49330f4 It's up for review in this PR: https://github.com/openwrt/packages/pull/10597 -- Aleksander https://aleksander.es ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: AW: Set allowed mode to 2G, 3G, 4G not working
On Tue, 19 Nov 2019, Daniele Palmas wrote:
Date: Tue, 19 Nov 2019 14:25:52
From: Daniele Palmas
To: Enrico Mioso
Cc: Stelling2 Carsten ,
"modemmanager-devel@lists.freedesktop.org"
Subject: Re: AW: Set allowed mode to 2G, 3G, 4G not working
Hi Enrico,
Il giorno mar 19 nov 2019 alle ore 10:52 Enrico Mioso
ha scritto:
I am experiencing similar issues when trying to set allowed mode to all modes, and
preferred to "none in particular" :) .
Simply doesn't work - even with a success message then settings remain so that
preferred mode looks to be 4G. Would like very much to solve this.
are you using LE910-EU1 as well?
Hi Daniele!
Sorry, hasn't been as specific as needed, that's bad. Sorry.
No, i experienced this with a Quectel EC25 modem... Didn't solve this even
after factory reset, but at this point I don't know what's going on. Thank you
very much.
Enrico
Regards,
Daniele
Enrico
On Tue, 19 Nov 2019, Stelling2 Carsten wrote:
Date: Tue, 19 Nov 2019 10:10:44
From: Stelling2 Carsten
To: "modemmanager-devel@lists.freedesktop.org"
,
"Daniele Palmas (dnl...@gmail.com)"
Subject: AW: Set allowed mode to 2G, 3G, 4G not working
Hi,
I've just updated MM from 1.10.0 to 1.12.0 with the result, that my application
fails when setting the mode ('2G|4G') for Telit LE910-EU1. It also fails when
using mmcli.
My version 1.10.0 contains Daniele's patches mentioned here
https://lists.freedesktop.org/archives/modemmanager-devel/2019-February/007044.html
and in following messages.
I assume, that Daniele's patches didn't go mainline.
Daniele, can you send a merge request, containing your patches for the master
branch?
I'll test them as soon as possible with Telit LE910-EU1 and give you feedback,
such that this feature can be released.
Thank you for your help.
Carsten
-Ursprüngliche Nachricht-
Von: ModemManager-devel
[mailto:modemmanager-devel-boun...@lists.freedesktop.org] Im Auftrag von
Stelling2 Carsten
Gesendet: Mittwoch, 27. Februar 2019 10:16
An: Daniele Palmas
Cc: modemmanager-devel@lists.freedesktop.org; Reinhard Speyerer; Aleksander
Morgado
Betreff: AW: Set allowed mode to 2G, 3G, 4G not working
Hi Daniele,
Thank you. Yes, I'll give it a try tomorrow.
Following patches from your commits should be applied to MM 1.10.0
4089726c1fbdc90ecec8737f9ea287784708ca7f
90cb911437538d5b6bd681aa1d7e1be2e1700227
Is this right?
Best regards,
Carsten
-Ursprüngliche Nachricht-
Von: Daniele Palmas [mailto:dnl...@gmail.com]
Gesendet: Dienstag, 26. Februar 2019 14:59
An: Stelling2 Carsten
Cc: Aleksander Morgado; Reinhard Speyerer;
modemmanager-devel@lists.freedesktop.org
Betreff: Re: Set allowed mode to 2G, 3G, 4G not working
Hi Carsten,
Il giorno ven 22 feb 2019 alle ore 12:12 Stelling2 Carsten
ha scritto:
Hi,
I must correct me, modem type is LE910-EU1 as Reinhard assumed. Sorry for this
confusion.
As a workaround for testing, we send AT+WS46 commands via D-Bus, but that seems
possible only, if MM runs in debug mode.
If we need this feature for production in the future, I understand that we can
add it to the Telit plugin.
at the following link
https://gitlab.freedesktop.org/dnlplm/ModemManager.git
you can find a fork with two additional commits that should implement
what needed.
Before sending to Aleksander a merge request would you like to give it a try?
Regards,
Daniele
I'd be very happy, if you can support me during implementation at a later point
in time.
Thank you Aleksander and Reinhard for your support.
Carsten
-Ursprüngliche Nachricht-
Von: Aleksander Morgado [mailto:aleksan...@aleksander.es]
Gesendet: Freitag, 22. Februar 2019 09:59
An: Reinhard Speyerer
Cc: modemmanager-devel@lists.freedesktop.org; Stelling2 Carsten
Betreff: Re: Set allowed mode to 2G, 3G, 4G not working
Within the debug output I found the following line
ModemManager[623]: [1550762368.321591] MBIM-powered Telit modem found...
which points out, that calling
if (mm_port_probe_list_is_xmm (probes))
did not find the XMM support.
It didn't find it, because the XACT=? check failed:
ModemManager[623]: [1550762359.960165] (ttyACM0): --> 'AT+XACT=?'
ModemManager[623]: [1550762360.882668] (ttyACM0): <--
'ERROR'
So I assume the XMM support that we have in the xmm plugin isn't ready
to handle this specific device.
The inability to switch modes in this device is not a bug, it's just
not implemented I'm afraid.
Hi Aleksander,
the Telit-preferred way seems to be to handle this with AT+WS46.
I haven't checked the code in detail but based on the AT+WS46
references in the Telit plugin I would have expected for
ModemManager to already use it.
If the modem is managed with MBIM, the generic MBIM implementation is
used for the Telit modem, so no AT+WS46 based mode switching will be
done. For this kind of cases, where we have MBIM for generic control
plus AT for other features, we would need to have a
"MMBr
Re: AW: Set allowed mode to 2G, 3G, 4G not working
I am experiencing similar issues when trying to set allowed mode to all modes, and
preferred to "none in particular" :) .
Simply doesn't work - even with a success message then settings remain so that
preferred mode looks to be 4G. Would like very much to solve this.
Enrico
On Tue, 19 Nov 2019, Stelling2 Carsten wrote:
Date: Tue, 19 Nov 2019 10:10:44
From: Stelling2 Carsten
To: "modemmanager-devel@lists.freedesktop.org"
,
"Daniele Palmas (dnl...@gmail.com)"
Subject: AW: Set allowed mode to 2G, 3G, 4G not working
Hi,
I've just updated MM from 1.10.0 to 1.12.0 with the result, that my application
fails when setting the mode ('2G|4G') for Telit LE910-EU1. It also fails when
using mmcli.
My version 1.10.0 contains Daniele's patches mentioned here
https://lists.freedesktop.org/archives/modemmanager-devel/2019-February/007044.html
and in following messages.
I assume, that Daniele's patches didn't go mainline.
Daniele, can you send a merge request, containing your patches for the master
branch?
I'll test them as soon as possible with Telit LE910-EU1 and give you feedback,
such that this feature can be released.
Thank you for your help.
Carsten
-Ursprüngliche Nachricht-
Von: ModemManager-devel
[mailto:modemmanager-devel-boun...@lists.freedesktop.org] Im Auftrag von
Stelling2 Carsten
Gesendet: Mittwoch, 27. Februar 2019 10:16
An: Daniele Palmas
Cc: modemmanager-devel@lists.freedesktop.org; Reinhard Speyerer; Aleksander
Morgado
Betreff: AW: Set allowed mode to 2G, 3G, 4G not working
Hi Daniele,
Thank you. Yes, I'll give it a try tomorrow.
Following patches from your commits should be applied to MM 1.10.0
4089726c1fbdc90ecec8737f9ea287784708ca7f
90cb911437538d5b6bd681aa1d7e1be2e1700227
Is this right?
Best regards,
Carsten
-Ursprüngliche Nachricht-
Von: Daniele Palmas [mailto:dnl...@gmail.com]
Gesendet: Dienstag, 26. Februar 2019 14:59
An: Stelling2 Carsten
Cc: Aleksander Morgado; Reinhard Speyerer;
modemmanager-devel@lists.freedesktop.org
Betreff: Re: Set allowed mode to 2G, 3G, 4G not working
Hi Carsten,
Il giorno ven 22 feb 2019 alle ore 12:12 Stelling2 Carsten
ha scritto:
Hi,
I must correct me, modem type is LE910-EU1 as Reinhard assumed. Sorry for this
confusion.
As a workaround for testing, we send AT+WS46 commands via D-Bus, but that seems
possible only, if MM runs in debug mode.
If we need this feature for production in the future, I understand that we can
add it to the Telit plugin.
at the following link
https://gitlab.freedesktop.org/dnlplm/ModemManager.git
you can find a fork with two additional commits that should implement
what needed.
Before sending to Aleksander a merge request would you like to give it a try?
Regards,
Daniele
I'd be very happy, if you can support me during implementation at a later point
in time.
Thank you Aleksander and Reinhard for your support.
Carsten
-Ursprüngliche Nachricht-
Von: Aleksander Morgado [mailto:aleksan...@aleksander.es]
Gesendet: Freitag, 22. Februar 2019 09:59
An: Reinhard Speyerer
Cc: modemmanager-devel@lists.freedesktop.org; Stelling2 Carsten
Betreff: Re: Set allowed mode to 2G, 3G, 4G not working
Within the debug output I found the following line
ModemManager[623]: [1550762368.321591] MBIM-powered Telit modem found...
which points out, that calling
if (mm_port_probe_list_is_xmm (probes))
did not find the XMM support.
It didn't find it, because the XACT=? check failed:
ModemManager[623]: [1550762359.960165] (ttyACM0): --> 'AT+XACT=?'
ModemManager[623]: [1550762360.882668] (ttyACM0): <--
'ERROR'
So I assume the XMM support that we have in the xmm plugin isn't ready
to handle this specific device.
The inability to switch modes in this device is not a bug, it's just
not implemented I'm afraid.
Hi Aleksander,
the Telit-preferred way seems to be to handle this with AT+WS46.
I haven't checked the code in detail but based on the AT+WS46
references in the Telit plugin I would have expected for
ModemManager to already use it.
If the modem is managed with MBIM, the generic MBIM implementation is
used for the Telit modem, so no AT+WS46 based mode switching will be
done. For this kind of cases, where we have MBIM for generic control
plus AT for other features, we would need to have a
"MMBroadbandModemMbimTelit" implementation that inherits from
MMBroadbandModemMbim but then shares features with the Telit-specific
AT modem object. So, it's totally possible to do this, but needs to be
done.
--
Aleksander
https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
___
ModemManager-devel mailing
Re: Is there support for modem with a single UART port ? (SIM5320A with usb disconnected)
Hello! Out of curiosity - how did it happen the USB port isn't wired? Plain curiosity. :) Enrico On Mon, 18 Nov 2019, Andrés Calderón wrote: Date: Mon, 18 Nov 2019 17:50:43 From: Andrés Calderón To: modemmanager-devel@lists.freedesktop.org Subject: Is there support for modem with a single UART port ? (SIM5320A with usb disconnected) Hi, I'm connected to a modem with a *single* serial port (Simcom SIM5320A with the USB port unwired) I can connect to Internet using the old way (writing my own chat scripts). But I couldn't do it using modemmanager. I have a lot of error messages from ModemManeger like that: "Couldn't refresh signal quality: 'No AT port available to run command'" Can ModemManager work with a single physical UART port? any guide here? Below I share more information about the issue Best regards, Andres Calderon = # udevadm info /dev/ttyAMA0 P: /devices/platform/soc/3f201000.serial/tty/ttyAMA0 N: ttyAMA0 L: 0 S: serial0 E: DEVPATH=/devices/platform/soc/3f201000.serial/tty/ttyAMA0 E: DEVNAME=/dev/ttyAMA0 E: MAJOR=204 E: MINOR=64 E: SUBSYSTEM=tty E: USEC_INITIALIZED=5122363 E: ID_MM_CANDIDATE=1 E: ID_MM_TTY_FLOW_CONTROL=none E: ID_MM_TTY_BAUDRATE=115200 E: ID_MM_DEVICE_PROCESS=1 E: ID_MM_PLATFORM_DRIVER_PROBE=1 E: DEVLINKS=/dev/serial0 E: TAGS=:systemd: = # mmcli -m 0 -- General | dbus path: /org/freedesktop/ModemManager1/Modem/0 | device id: 23b798cdd09c78be14e231127c48d70f5307a48e -- Hardware | manufacturer: SIMCOM INCORPORATED | model: SIMCOM_SIM5320A | revision: 1575B13SIM5320A | supported: gsm-umts | current: gsm-umts | equipment id: 012813008537617 -- System | device: /sys/devices/platform/soc | drivers: uart-pl011 | plugin: Generic | primary port: ttyAMA0 | ports: ttyAMA0 (at) -- Numbers | own: +573176760667 -- Status | unlock retries: sim-pin (3), sim-pin2 (3), sim-puk (10), sim-puk2 (10) | state: disabled | power state: on | signal quality: 0% (cached) -- Modes | supported: allowed: 2g, 3g; preferred: none | current: allowed: 2g, 3g; preferred: none -- IP | supported: ipv4, ipv6 -- 3GPP | imei: 012813008537617 -- Andrés Calderón MODEMMANAGER LOG ModemManager[1133]: [1574094017.402205] No specific IP family requested, defaulting to ipv4 ModemManager[1133]: [1574094017.402298] No specific IP family requested, defaulting to ipv4 ModemManager[1133]: [1574094017.402439] Looking for best CID... ModemManager[1133]: [1574094017.402551] (ttyAMA0) device open count is 6 (open) ModemManager[1133]: [1574094017.402722] (ttyAMA0) device open count is 5 (close) ModemManager[1133]: [1574094017.402865] (ttyAMA0): --> 'AT+COPS=3,0' ModemManager[1133]: [1574094017.420240] (ttyAMA0): <-- 'OK' ModemManager[1133]: [1574094017.420584] (ttyAMA0) device open count is 4 (close) ModemManager[1133]: [1574094017.420786] (ttyAMA0): --> 'AT+COPS?' ModemManager[1133]: [1574094017.435034] (ttyAMA0): <-- '+COPS:' ModemManager[1133]: [1574094017.435707] (ttyAMA0): <-- ' 0,0,"mo' ModemManager[1133]: [1574094017.436395] (ttyAMA0): <-- 'vistar",' ModemManager[1133]: [1574094017.437102] (ttyAMA0): <-- '2OK' ModemManager[1133]: [1574094017.437484] (ttyAMA0): <-- '' ModemManager[1133]: [1574094017.438034] loaded Operator Name: movistar ModemManager[1133]: [1574094017.438332] Modem /org/freedesktop/ModemManager1/Modem/0: 3GPP Registration state changed (registering -> home) ModemManager[1133]: [1574094017.438692] Will start keeping track of state for subsystem '3gpp' ModemManager[1133]: [1574094017.438854] (ttyAMA0) device open count is 3 (close) ModemManager[1133]: [1574094017.439624] (ttyAMA0): --> 'AT+CIND?' ModemManager[1133]: [1574094017.455505] (ttyAMA0): <-- '+CIND:' ModemManager[1133]: [1574094017.456197] (ttyAMA0): <-- ' 4,4,1,0' ModemManager[1133]: [1574094017.456876] (ttyAMA0): <-- ',0,1,1,0' ModemManager[1133]: [1574094017.457569] (ttyAMA0): <-- 'OK' ModemManager[1133]: [1574094017.458379] Modem /org/freedesktop/ModemManager1/Modem/0: signal quality updated (80) ModemManager[1133]: [1574094017.458750] (ttyAMA0) device open count is 2 (close) ModemManager[1133]: [1574094017.459450] Polling to refresh access technologies is unsupported ModemManager[1133]: [1574094017.459576] Periodic signal quality checks scheduled in 30s ModemManager[1133]: [1574094017.459730]
Re: ModemManager and modems discovery in OpenWRt
Ok, I'll now will try to see if i can break it. BTW - is there any plan to try backporting MM OpenWRt feeds to 19.07? A good number of feeds is being backported it seems, so it may still be possible. On Mon, 18 Nov 2019, Aleksander Morgado wrote: Date: Mon, 18 Nov 2019 12:25:39 From: Aleksander Morgado To: Enrico Mioso Cc: "ModemManager (development)" , Bjørn Mork Subject: Re: ModemManager and modems discovery in OpenWRt Hey! Aleksander and Bjørn, I am CC'ing you since this question came up reading your discussion about udev rules usage. So, modems discovery mechanism in ModemManager is implemented via --report-kernel-event. And we have --report-kernel-event-auto-scan as well. the current method of reporting even tough, is not as robust: and sometimes it may happen a modem is present but not detected. That would be a bug to analyze. Do you have details on how that happened? With all the respect, while --report-kernel-event seems to be a very good decision / design choice, I don't like as much the current hotplug--based method / scripts we use to report for modem events. The cache, and all that, they seem too fragile to me. What's your opinion on that? Well, as long as hotplug events happen when they should, the logic should be consistent IMO. There's one thing I don't like, though, and I may be wrong about how it works, but if for any reason there is another hotplug script taking too much time to run, the reporting of the events to MM may happen with a lot of time in between events, and the port probing mechanism may get delayed too much. I have a MR trying to mitigate that, please see: https://gitlab.freedesktop.org/mobile-broadband/ModemManager/merge_requests/207 I would be set out to replace that, maybe implementing some code to listen to netlink events and directly "inject" events in MM, or something like that. I would like to have your opinion on that, and directions on the best way to proceed. Not sure what to say :) IMO, if the hotplug scripts is the way openwrt has to report device events to userspace, we should stick to that. If that is not working well, we should fix it. -- Aleksander https://aleksander.es ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
ModemManager and modems discovery in OpenWRt
Hello guys! Aleksander and Bjørn, I am CC'ing you since this question came up reading your discussion about udev rules usage. So, modems discovery mechanism in ModemManager is implemented via --report-kernel-event. And we have --report-kernel-event-auto-scan as well. the current method of reporting even tough, is not as robust: and sometimes it may happen a modem is present but not detected. With all the respect, while --report-kernel-event seems to be a very good decision / design choice, I don't like as much the current hotplug--based method / scripts we use to report for modem events. The cache, and all that, they seem too fragile to me. What's your opinion on that? I would be set out to replace that, maybe implementing some code to listen to netlink events and directly "inject" events in MM, or something like that. I would like to have your opinion on that, and directions on the best way to proceed. Enrico___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: OpenWrt package and udev rules
Yeah. That mechanism may be useful for a built in package. OpenVPN uses that I think ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: OpenWrt package and udev rules
Or the keep.d directory... ? ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Could not grab port (usbmisc/cdc-wdm0): 'Cannot add port 'usbmisc/cdc-wdm0', unsupported' - debug output
Thanks! :) On Fri, 1 Nov 2019, Nick wrote: Date: Fri, 1 Nov 2019 03:14:12 From: Nick To: Enrico Mioso Cc: "ModemManager (development)" Subject: Re:Could not grab port (usbmisc/cdc-wdm0): 'Cannot add port 'usbmisc/cdc-wdm0', unsupported' - debug output Hey, That has already been merged in the latest OpenWrt master as of yesterday All the best, Nick On 1 Nov 2019, at 12:10, Enrico Mioso wrote: Sorry guys, overlooked the fact thati n the configuration libqmi and libmbim where disabled What do you think about enabling them by default? Sorry for the noise... Enrico ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Could not grab port (usbmisc/cdc-wdm0): 'Cannot add port 'usbmisc/cdc-wdm0', unsupported' - debug output
Sorry guys, overlooked the fact thati n the configuration libqmi and libmbim where disabled What do you think about enabling them by default? Sorry for the noise... Enrico ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Could not grab port (usbmisc/cdc-wdm0): 'Cannot add port 'usbmisc/cdc-wdm0', unsupported' - debug output
Here the debug output: the modem isn't recognized as QMi capable even if I am sure it is and infact qmicli works fine. :) [3588]: [1572511480.295083] ModemManager (version 1.10.6) starting in system bus... [3588]: [1572511480.310072] Bus acquired, creating manager... [3588]: [1572511480.312844] [filter] created [3588]: [1572511480.313100] [filter] explicit whitelist: yes [3588]: [1572511480.313271] [filter] explicit blacklist: yes [3588]: [1572511480.313440] [filter] plugin whitelist: no [3588]: [1572511480.313606] [filter] virtual devices forbidden: yes [3588]: [1572511480.313772] [filter] net devices allowed:yes [3588]: [1572511480.313939] [filter] cdc-wdm devices allowed:yes [3588]: [1572511480.314103] [filter] tty devices: [3588]: [1572511480.314264] [filter] blacklist applied:yes [3588]: [1572511480.314432] [filter] manual scan only applied: yes [3588]: [1572511480.314601] [filter] platform driver check:yes [3588]: [1572511480.314772] [filter] driver check: no [3588]: [1572511480.314939] [filter] cdc-acm interface check: no [3588]: [1572511480.315104] [filter] with net check: no [3588]: [1572511480.315270] [filter] default: allowed [3588]: [1572511480.315814] [plugin manager] looking for plugins in '/usr/lib/ModemManager' [3588]: [1572511480.319415] [plugin manager] loaded plugin 'Altair LTE' [3588]: [1572511480.321419] [plugin manager] loaded plugin 'AnyDATA' [3588]: [1572511480.323859] [plugin manager] loaded plugin 'Cinterion' [3588]: [1572511480.327181] [plugin manager] loaded plugin 'Dell' [3588]: [1572511480.329843] [plugin manager] loaded plugin 'Ericsson MBM' [3588]: [1572511480.332329] [plugin manager] loaded plugin 'Fibocom' [3588]: [1572511480.333821] [plugin manager] loaded plugin 'Generic' [3588]: [1572511480.335213] [plugin manager] loaded plugin 'Haier' [3588]: [1572511480.338305] [plugin manager] loaded plugin 'Huawei' [3588]: [1572511480.340429] [plugin manager] loaded plugin 'Iridium' [3588]: [1572511480.342224] [plugin manager] loaded plugin 'Linktop' [3588]: [1572511480.344091] [plugin manager] loaded plugin 'Longcheer' [3588]: [1572511480.345579] [plugin manager] loaded plugin 'Motorola' [3588]: [1572511480.347407] [plugin manager] loaded plugin 'MTK' [3588]: [1572511480.350288] [plugin manager] loaded plugin 'Nokia (Icera)' [3588]: [1572511480.352289] [plugin manager] loaded plugin 'Nokia' [3588]: [1572511480.354414] [plugin manager] loaded plugin 'Novatel LTE' [3588]: [1572511480.356645] [plugin manager] loaded plugin 'Novatel' [3588]: [1572511480.359206] [plugin manager] loaded plugin 'Option High-Speed' [3588]: [1572511480.361459] [plugin manager] loaded plugin 'Option' [3588]: [1572511480.363291] [plugin manager] loaded plugin 'Pantech' [3588]: [1572511480.364989] [plugin manager] loaded plugin 'Quectel' [3588]: [1572511480.367818] [plugin manager] loaded plugin 'Samsung' [3588]: [1572511480.371098] [plugin manager] loaded plugin 'Sierra (legacy)' [3588]: [1572511480.372724] [plugin manager] loaded plugin 'Sierra' [3588]: [1572511480.374566] [plugin manager] loaded plugin 'SimTech' [3588]: [1572511480.376992] [plugin manager] loaded plugin 'Telit' [3588]: [1572511480.378893] [plugin manager] loaded plugin 'Thuraya' [3588]: [1572511480.381637] [plugin manager] loaded plugin 'u-blox' [3588]: [1572511480.383545] [plugin manager] loaded plugin 'Via CBP7' [3588]: [1572511480.385528] [plugin manager] loaded plugin 'Wavecom' [3588]: [1572511480.387597] [plugin manager] loaded plugin 'X22X' [3588]: [1572511480.390570] [plugin manager] loaded plugin 'ZTE' [3588]: [1572511480.390989] [plugin manager] successfully loaded 33 plugins [3588]: [1572511480.395468] Service name 'org.freedesktop.ModemManager1' was acquired [3588]: [1572511508.936062] Kernel event reported: [3588]: [1572511508.936356] action:add [3588]: [1572511508.936484] subsystem: tty [3588]: [1572511508.936601] name: console [3588]: [1572511508.936737] uid: n/a [3588]: [1572511508.936895] [rules] rules directory set to '/lib/udev/rules.d'... [3588]: [1572511508.943848] [rules] loading rules from: /lib/udev/rules.d/77-mm-cinterion-port-types.rules [3588]: [1572511508.945719] [rules] loading rules from: /lib/udev/rules.d/77-mm-dell-port-types.rules [3588]: [1572511508.947272] [rules] loading rules from: /lib/udev/rules.d/77-mm-ericsson-mbm.rules [3588]: [1572511508.956797] [rules] loading rules from: /lib/udev/rules.d/77-mm-fibocom-port-types.rules [3588]: [1572511508.958013] [rules] loading rules from: /lib/udev/rules.d/77-mm-haier-port-types.rules [3588]: [1572511508.959171] [rules] loading rules from: /lib/udev/rules.d/77-mm-huawei-net-port-types.rules [3588]: [1572511508.961295] [rules] loading rules from: /lib/udev/rules.d/77-mm-longcheer-port-types.rules [3588]:
Re: Could not grab port (usbmisc/cdc-wdm0): 'Cannot add port 'usbmisc/cdc-wdm0', unsupported'
Is this missing libusb?? mhm... ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Could not grab port (usbmisc/cdc-wdm0): 'Cannot add port 'usbmisc/cdc-wdm0', unsupported'
BTW, you guys may be interested in this: https://stackoverflow.com/q/57675594 On Thu, 31 Oct 2019, Enrico Mioso wrote: Date: Thu, 31 Oct 2019 22:33:38 From: Enrico Mioso To: "ModemManager (development)" Cc: Nick Subject: Could not grab port (usbmisc/cdc-wdm0): 'Cannot add port 'usbmisc/cdc-wdm0', unsupported' Hello! I am experiencing an interesting issue with a Quectel EC25 modem in an OpenWRt-based system. Thu Oct 31 08:24:47 2019 daemon.warn [3133]: Could not grab port (usbmisc/cdc-wdm0): 'Cannot add port 'usbmisc/cdc-wdm0', unsupported' Thu Oct 31 08:24:52 2019 daemon.warn [3133]: Couldn't build device ids: 'Unsupported subsystem: /sys/bus' Where may I look for? thank you very very much guys, sorry for my absence during the merge phase. Enrico ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: IPv6 support in the openwrt protocol handler
Sorry for the intrusion guys...
BTW - how do I control modem MTU? Is it sufficient to change bearer's MTU?
In other words - how many different MTUs are there, and how can them be
controlled? I am asking this investigating performance issues.
Thank you guys.
Enrico
On Wed, 23 Oct 2019, Bjørn Mork wrote:
Date: Wed, 23 Oct 2019 10:35:01
From: Bjørn Mork
To: Aleksander Morgado
Cc: "ModemManager (development)" ,
Nick B
Subject: Re: IPv6 support in the openwrt protocol handler
Aleksander Morgado writes:
Hey Nick,
Before the openwrt packages were integrated in the official packages
repo, we received a merge request adding some IPv6 support to the
modemmanager protocol handler.
Please look at this patch in case you want to get that integrated:
https://gitlab.freedesktop.org/aleksm/mobile-broadband-openwrt/commit/9234ce19c00cf2067d7ea48844569ae2fd135033
Now I haven't tested this at all, so I might be missing
something But the patch has a
if [ "$iptype" = "ipv6" -o "$iptype" = "ipv4v6" ]; then
.. lotsofstuff
else
.. otherstuff
fi
This looks wrong, and like it might potentionally break IPv4 in the
"ipv4v6" case. Or is that still handled somehow?
There are also som minor nits like requiring "bearer.ipv6-config.method"
for IPv6 just for the
echo "connection setup required in interface ${beareriface}: ${bearermethod}"
when in fact only "static" is supported for IPv6. Which I guess is fine
by itself. "dhcp" doesn't make much sense. But I believe "ppp" at least
should spit out an "unsupported" warning or similar. OpenWrt users have
been known to try dual stack over PPP in the past :-)
Bjørn
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Announcing AGH 0.02
Hi! I am announcing AGH 0.02: a 3G/4G connection manager (via ModemManager) / XMPP control agent (via libstrophe), specifically designed for OpenWrt. Some of it's features: Documentation: AGH is documented enough to get you to a good start; Modem handling: - uses ModemManager, so your QMI/MBIM/cdc_ether based modem will be used at it's max performance - bearer profiles: one or more bearers can be configured; AGH will keep them connected - supports more than one modem at time: each modem has it's connection settings - supports matching predefined connection profiles based on operator id - supports configuring / setting modem preferred modes - very basic SMS messaging support for sending and receiving messages, or deleting them all :) XMPP: allows complete control of the system over XMPP - ubus: can perform ubus calls, listen for events - ubox logd: can intercept log messages connecting to a file descriptor as provided by logd System: AGH is designed to integrate seamslessly with the rest of the system. An init.d script is provided. AGH supports running in a jail via ujail. Basic OpenWrt packaging support is provided. License: it's free software, distributed under the GPL Version 2 or, at your option, any later version. Changes in version 0.02: all of the bugs found by the Coverity static analysis tools have been fixed. Great thanks to Marks for his help! I put all of my effort in making AGH a robust and useful software. Nevertheless, I am a beginner, so I need your help guys! :) I would like so much for AGH becoming truly robust, useful and excellent software. Any help is greatly welcome: with code scrutiny, patches, new functionalities, and project administration (e.g.: managing pull requests in GitHub and so on). Any ideas in how to shape the project is also welcome - so feel free to express yourself! Grab your AGH right now at: https://github.com/mrkiko/agh Thanks!! Enrico ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Resetting Bearer on OpenWRT
Hi! On Sun, 8 Sep 2019, Aleksander Morgado wrote: Absolutely no idea, because I don't know how netifd expects that to be reported or how it does connection monitoring. Any info on how that works would be appreciated. I admit I didn't follow the entire discussion from the beginning, so sorry for the noise in case what I am telling is useless. From my unerstanding, anyone please correct me if I am wrong, lots of relevant code is in OpenWRt's netifd-proto.sh. From my understanding, netifd expects to be informed by protocol handlers about when things change, especially because in this case the network interface wouldn't change it's state apparently. So, as righly pointed out by you, MM may directly emit ubus events simulating what a protocol handler does, or it may invoke a shell script carrying out that task, keeping the state consistent. This is what I did in AGH - I am not saying it's the best solution, but that's the route I choose. Enrico ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Announcing AGH 0.01
Dear Aleksander, thank you very very much!! BTW - MM documentation is great - and that's what allowed me to find my way when implementing, in practice, all the things. And the mmcli code-base has been a fundamental guidance! :) And you have been of course: before joining the ML I remember how many mails I sent! :) Yes, I know about the effort and - I think it's great! At the moment it may be complicated, but it would be great if we could join efforts and create a good support platform integrating with LUCI and so on. Thanks!! Enrico P.S.: deleting quoted text to make it easier to read this with screen readers... ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Announcing AGH 0.01
Hi! I am announcing AGH: a 3G/4G connection manager (via ModemManager) / XMPP control agent, specifically designed for OpenWrt. Some of it's features: Documentation: AGH is documented enough to get you to a good start; Modem handling: - uses ModemManager, so your QMI/MBIM/cdc_ether based modem will be used at it's max performance - bearer profiles: one or more bearers can be configured; AGH will keep them connected - supports more than one modem at time: each modem has it's connection settings - supports matching predefined connection profiles based on operator id - supports configuring / setting modem preferred modes - SMS messaging rudimentary support for sending and receiving messages, or deleting all of them XMPP: allows complete control of the system over XMPP - ubus: can perform ubus calls, listen for events - ubox logd: can intercept log messages connecting to a file descriptor as provided by logd System: AGH is designed to integrate seamslessly with the rest of the system. An init.d script is provided. AGH supports running in a jail via ujail. Basic OpenWrt packaging support is provided. License: it's free software, distributed under the GPL Version 2 or, at your option, any later version. I put all of my effort in making AGH a robust and useful software. Nevertheless, I am a beginner, so I need your help guys! :) I would like so much for AGH becoming truly robust, useful and excellent software. Any help is greatly welcome: with code scrutiny, patches, new functionalities, and project administration (e.g.: managing pull requests in github and so on). Any ideas in how to shape the project is also welcome - so feel free to express yourself! Grab your AGH right now at: https://github.com/mrkiko/agh Thanks!! ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: cannot find glib-2.0 when building in openwrt
Dear Belisko Marek, it seems the build system can not find other packages in the feeds/packages repository. Did you update / install those feeds first? ./scripts/feeds update -a ./scripts/feeds install -a Or maybe there is a better way? Enrico On Tue, 11 Jun 2019, Belisko Marek wrote: Date: Tue, 11 Jun 2019 08:36:49 From: Belisko Marek To: "ModemManager (development)" Subject: cannot find glib-2.0 when building in openwrt Hi, I'm following this README : https://gitlab.freedesktop.org/mobile-broadband/mobile-broadband-openwrt to have modemmanager to be build in openwrt. But while using this step: ./scripts/feeds install -p mobile_broadband -a I get: ./scripts/feeds install -p mobile_broadband -a WARNING: Makefile 'package/utils/busybox/Makefile' has a dependency on 'libpam', which does not exist WARNING: Makefile 'package/utils/busybox/Makefile' has a build dependency on 'libpam', which does not exist WARNING: Makefile 'package/network/utils/curl/Makefile' has a dependency on 'libgnutls', which does not exist WARNING: Makefile 'package/network/utils/curl/Makefile' has a dependency on 'libopenldap', which does not exist WARNING: Makefile 'package/network/utils/curl/Makefile' has a dependency on 'libidn2', which does not exist WARNING: Makefile 'package/network/utils/curl/Makefile' has a dependency on 'libssh2', which does not exist WARNING: Makefile 'package/boot/kexec-tools/Makefile' has a dependency on 'liblzma', which does not exist WARNING: Makefile 'package/feeds/mobile_broadband/libmbim/Makefile' has a dependency on 'glib2', which does not exist WARNING: Makefile 'package/feeds/mobile_broadband/libqmi/Makefile' has a dependency on 'glib2', which does not exist WARNING: Makefile 'package/network/services/lldpd/Makefile' has a dependency on 'libnetsnmp', which does not exist WARNING: Makefile 'package/feeds/mobile_broadband/modemmanager/Makefile' has a dependency on 'glib2', which does not exist WARNING: Makefile 'package/feeds/mobile_broadband/modemmanager/Makefile' has a dependency on 'dbus', which does not exist Installing all packages from feed mobile_broadband. and despite of that if I run build then libmbim fails with: checking pkg-config is at least version 0.9.0... yes checking for glib-2.0 >= 2.36... no configure: error: Package requirements (glib-2.0 >= 2.36) were not met: No package 'glib-2.0' found Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. Alternatively, you may set the environment variables MBIM_COMMON_CFLAGS and MBIM_COMMON_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details. Makefile:69: recipe for target '/home/marek/projects/cmoss_resin/compex-openwrt/build_dir/target-arm_cortex-a7+neon-vfpv4_musl_eabi/libmbim-1.18.2/.configured_a17fb5ef857664f03cd0ce37cc5ea591' failed make[3]: *** [/home/marek/projects/cmoss_resin/compex-openwrt/build_dir/target-arm_cortex-a7+neon-vfpv4_musl_eabi/libmbim-1.18.2/.configured_a17fb5ef857664f03cd0ce37cc5ea591] Error 1 make[3]: Leaving directory '/home/marek/projects/cmoss_resin/compex-openwrt/feeds/mobile_broadband/libmbim' Command exited with non-zero status 2 time: package/feeds/mobile_broadband/libmbim/compile#7.20#1.00#8.80 package/Makefile:107: recipe for target 'package/feeds/mobile_broadband/libmbim/compile' failed Ideas? I'm on actual 18.06 branch. Thanks. BR, marek -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Get the last SMS from mm_modem_messaging_list
Hello Andrea, hello all!! Andrea, can you explain me how you arrived to that code? I am curioust to learn!! And understand. So I would appreciate some explanations. I did the same this way: ... mmobject = agh_mm_get_mmobject(mstate, modem); ... messaging = mm_object_get_modem_messaging(mmobject); ... signal_id = g_signal_connect(messaging, "added", G_CALLBACK(agh_mm_modem_sms_added), mstate); ... but then I faced your same issue. BTW, due to the "marshaller" used in this case, I am not able to pass user data (e.g.: mstate). Is there a way around this? May we change the marshaller used in MM? thank you all!! Enrico ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: setting modes back to default on Quectel EC 25 modem won't work
Hello again! to update my question, I report here that: qmicli -p -d /dev/cdc-wdm0 --nas-get-system-selection-preference [/dev/cdc-wdm0] Successfully got system selection preference Emergency mode: 'no' Mode preference: 'gsm, umts, lte' Band preference: 'gsm-dcs-1800, gsm-900-extended, gsm-900-primary, wcdma-2100, wcdma-850-us, wcdma-900' LTE band preference: '1, 3, 5, 7, 8, 20, 38, 40, 41' TD-SCDMA band preference: '(NULL)' Roaming preference: 'any' Network selection preference: 'automatic' Service domain preference: 'cs-ps' GSM/WCDMA acquisition order preference: 'wcdma' Acquisition order preference: umts, lte, gsm, td-scdma, cdma-1x, cdma-1xevdo Is there something looking "peculiar"? thank you very much again to all, Enrico ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Requirements for u-blox LARA0-R2 (R280)
Dear Brendan Simon,
well, nmcli is coherent with MM, and MM is not able to find out a cdc-wdm
device:
| primary port: ttyACM0
I have no experience with u-blox device, so I am not able to give you a good
recommendation.
Still, maybe looking at the qmi-wwan.c driver in the current git kernel
repository might give you some ideas?
e.g.: commit 9306b38e42cb266f98bff6f6f4c1c652aa79ba45 ("NET: usb: qmi_wwan: add
support for ublox R410M PID 0x90b2").
Have a good day and hope you can solve your problem.
Enrico
On Fri, 26 Apr 2019, Brendan Simon (eTRIX) wrote:
Date: Fri, 26 Apr 2019 03:00:21
From: "Brendan Simon (eTRIX)"
To: modemmanager-devel@lists.freedesktop.org
Subject: Requirements for u-blox LARA0-R2 (R280)
I'm trying to get a u-blox LARA-R280 device working with my embedded linux
build -- using Linux kernel 4.4.0 (armhf) and
Debian Buster (testing).
* ModemManagerv 1.10.0
* NetworkManager 1.14.6
ModemManager discovers the device ok, but NetworkManger does not see a network
device (e.g. `cdc-wdm0` which is what I get
with a Quectel modem).
# mmcli -L
/org/freedesktop/ModemManager1/Modem/0 [u-blox] LARA-R280
# mmcli -m 0
General | dbus path: /org/freedesktop/ModemManager1/Modem/0
| device id: cefae5a09feceda70ab244f864cd3239d518b487
Hardware | manufacturer: u-blox
| model: LARA-R280
| revision: 30.43
| supported: gsm-umts, lte
| current: gsm-umts, lte
| equipment id: 357364080026759
System | device:
/sys/devices/soc0/amba/e0002000.usb/ci_hdrc.0/usb1/1-1
| drivers: cdc_acm
| plugin: u-blox
| ports: ttyACM3 (unknown), ttyACM4 (unknown),
ttyACM5 (unknown),
| ttyACM0 (at), ttyACM1 (at), ttyACM2 (at)
Status | unlock retries: sim-pin (3), sim-pin2 (3), sim-puk (10),
sim-puk2 (10)
| state: registered
| power state: on
| access tech: lte
| signal quality: 60% (recent)
# nmcli d
DEVICE TYPE STATE CONNECTION
eth0 ethernet connected wired-connection-1
ttyACM0 gsm disconnected --
sit0 iptunnel unmanaged --
tunl0 iptunnel unmanaged --
lo loopback unmanaged --
`nmcli` shows a `ttyACM0` serial device (instead of the network interface
device). I'm expecting something like
`cdc-wdm0`. Is that a correct assumption?
I hand to Monkey patch my kernel to work with the Quectel device (following
documents from Quetel), but I can't find any
information from u-blox about kernel driver requirements (other than the device
works with standard linux drivers).
Any ideas what drivers I need configured/enabled/patched to get the LARA-R2
module to enumerate as a network device?
Thanks,
Brendan.
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
setting modes back to default on Quectel EC 25 modem won't work
Dear all, first of all - thank you very very much for your help and work. I am meeting some difficulties in setting modes on a Quectel EC25 modem. while so far I was able to set modes to "any mode available, none preferred" in other modems, I am having some difficulties with this one. The command mmcli -m 1 --set-allowed-modes any --set-preferred-mode none Results in a message like: successfully set current modes in the modem but retrieving the state again shows still: current: allowed: 2g, 3g, 4g; preferred: 4g I am using a libqmi snapshot with latest commit (I saw the addition of the NAS system selection so I tought it would be useful to try this out just in case, thank you again Aleksander!). As a last resort, i tried also resetting modem to factory defaults: mmcli -m 0 --factory-reset=... obtaining the message successfully reseted the modem to factory state And then proceeding with mmcli -m 1 -r (I also did power cycle the modem via GPIO). I can attach the QMI log messages; to my eye they seem to confirm that all is well, but ... Thank again, Enrico ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Setting modes (again) and operation cancellation
Hello guys!! After some time, I am playing again with modes setting. Maybe it's absolutely normal, bt I am facing a situation where mode changes don't take effect apparently. Or, put another way: root@OpenWrt:~# mmcli -m 0 --set-allowed-modes="any" --set-preferred-mode="none" successfully set current modes in the modem root@OpenWrt:~# mmcli -m 0 |grep -i "current: allowed" | current: allowed: 2g, 3g, 4g; preferred: 4g root@OpenWrt:~# and mo matter, I am not able to set the preference to none. Is this due to modem firmware not supporting this? manufacturer: QUALCOMM INCORPORATED model: QUECTEL Mobile Broadband Module Firmware revision: EC25EFAR02A08M4G Carrier config: default h/w revision: 1 Modes list: supported: allowed: 2g; preferred: none allowed: 3g; preferred: none allowed: 4g; preferred: none allowed: 2g, 3g; preferred: 3g allowed: 2g, 3g; preferred: 2g allowed: 2g, 4g; preferred: 4g allowed: 2g, 4g; preferred: 2g allowed: 3g, 4g; preferred: 3g allowed: 3g, 4g; preferred: 4g allowed: 2g, 3g, 4g; preferred: 4g allowed: 2g, 3g, 4g; preferred: 3g allowed: 2g, 3g, 4g; preferred: 2g current: allowed: 2g, 3g, 4g; preferred: 4g Secondly: in our application we perform a fair amount of async calls. In exceptional cases where we care about order and operation completion, we do sync calls, but in most cases we use async operations. I am clearly facing the issue of the program segfaulting sometimes when some operations are still pending at exit. I imagine I should use a GCancellable for that. Could you give me any direction? Since I don't know at any given moments how many async operations are in progress. Thank you very very much to all of you reading this message. Enrico ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Setting modem modes back to default ("allowed: 2g, 3g, 4g; preferred: none")
Hello! Sorry for the disturbance guys. I am replying to myself to, maybe, help someone having the same question in future. The way to restore this default is: mmcli -m 1 --set-allowed-modes="any" thank you guys and sorry again for the noise Enrico ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Setting modem modes back to default ("allowed: 2g, 3g, 4g; preferred: none")
Hello to everybody!! I am facing a little issue with MM - in particular setting modem modes. My QMI-based modem was set to the following state at the beginning: current: allowed: 2g, 3g, 4g; preferred: none But now, I am not able to set it back to this state. In particular, MM doesn't list this combination amongst the supported ones, and so specifying a preference becomes mandatory whenever more than one mode is supplied. So: mmcli -m 1 --set-allowed-modes="2g" works, as does mmcli -m 1 --set-allowed-modes="3g" but once I add a second mode: mmcli -m 1 --set-allowed-modes="3g|4g" I get an error message: The given combination of allowed and preferred modes is not supported' I tried also using the "any" value, with no success so far. I guess I am doing something wrong or using the wrong keywords. Any help would be greatly apreciated. Enrico ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
