Re: EM7565 failing if host reboots whithout power cycling the modem

On 3/20/23 11:11, Bjørn Mork wrote: Peter Naulls writes: On my setup, we have to both power cycle the modem and also cycle the USB hub to regain proper control. OK, thanks for the information. It should not be like that, but I'm not surprised. This latter step might be the key here

Re: EM7565 failing if host reboots whithout power cycling the modem

On 3/20/23 09:26, John Marrett wrote: Bjørn, You should either open a case with the modem manufacturer if you have some kind of support agreement. If you don't then you could ask about it on the sierra wireless forums ( https://forum.sierrawireless.com/

Re: initial bearer apn

On 3/16/23 11:53, Juan A. Rubio wrote: Thanks Peter. What mechanism did you use to set the initial bearer? I'm using a Network Manager connection profile in which I'm setting the APN (e.g. myapn), not Telstra.internet [gsm] apn=myapn password="" username="" Do you use mmcli or MM DBus API ins

Re: initial bearer apn

On 3/16/23 11:32, Juan A. Rubio wrote: Hi, I'm using ModemManager version 1.18.12. I'm also using Network Manager 1.22.16 I'm wondering what part of the system stores or configures the initial bearer apn, since I'm not explicitly setting this value? $ mmcli -m 0 | grep 'bearer apn'

Re: ModemManager and Quectel RM520N-GL

On 3/6/23 02:40, Patrick Kosiol wrote: Hi Peter, Thanks for the info. Actually, the lsusb output was incomplete. It looks like the one attached so the device is actually there. Yet, you are right, the /dev/ttyUSB device is not present. I checked the state of the usb device and it appears to

Re: ModemManager vs NetworkManager (and the overlap of functionality) : Best Practices

On 3/13/23 08:34, Robert Colvin wrote: but this leaves me with more questions than answers (after playing for a while) As I understood it, NM was responsible for managing the modem itself, whereas MM would handle tasks like automatically failing over a wireless network to a cellular connection

Re: ModemManager and Quectel RM520N-GL

On 3/2/23 14:21, Patrick Kosiol wrote: Hi, It appears my ModemManager cannot initialize the Quectel RM520N-GL modem with the messages [01775.270989] [modem0] couldn't start parent initialization: Couldn't open ports during modem initialization: Couldn't get primary port [01775.275716

Re: ANN: ModemManager 1.20.6 released

On 3/1/23 04:36, Aleksander Morgado wrote: Hey hey, This is the third bugfix release in the 1.20.x series, built from the mm-1-20 branch. Thanks Alex. I'm in the middle of some unrelated work, but will be rolling this in pretty soon. Some of the fixes are possible fixes for the crash I'm s

Re: Remove plugins - updated patch

On 2/14/23 18:16, Tom Isaacson wrote: I'm currently building ModemManager 1.18.12 in Yocto. Are there any suggestions as to how to use this patch? Probably not at all. MM already has all the options to disable plugins with its meson setup; this just drives the OpenWrt configuration. So, you n

Re: Detection failure with 1.20.4

On 2/7/23 06:18, Aleksander Morgado wrote: Hey, In this log, I've disabled PPP, and out of desperation, DHCP too, to limit the churn. This problem appears 100% of the time at start up, and is only resolved by a restart of ModemManager, or a cycling of the USB interfaces (which the top-level

Remove plugins - updated patch

There must be a better/cleaner way to set this up with OpenWrt/meson, but this is what I'm using to remove all the excess plugins in ModemManager with current OpenWrt development. Improvements welcome. --- a/modemmanager/Config.in +++ b/modemmanager/Config.in @@ -40,8 +40,203 @@ config MODEMM

patch - Remove PPP round 2

I revised my earlier removal of PPP from the ModemManager build to be more complete. I'd like to remove it from the enums, but these are generated by meson and it'll still pick up #ifdefed out items - I couldn't find a mechanism to make this work. Also a patch against the Makefile in OpenWrt

OpenWrt build failure with mbim disabled

If ModemManager's mbim support is disabled: install -d -m0755 /home/peter/awc/openwrt-master/build_dir/target-mipsel_24kc_musl/modemmanager-1.20.2/.pkgdir/modemmanager/usr/share/ModemManager install -m0644 /home/peter/awc/openwrt-master/build_dir/target-mipsel_24kc_musl/modemmanager-1.20.2/ip

Re: Error status monitoring / dbus

On 1/22/23 10:18, Aleksander Morgado wrote: All org.freedesktop.ModemManager1.XX and org.freedesktop.libmbim.Error.XX error codes are coming either from ModemManager or the libraries. DBus specific errors have a different error prefix (org.freedesktop.DBus maybe?) Right, sure. But is it possib

Re: MM doc: wwan device types and port detection

On 1/22/23 10:16, Aleksander Morgado wrote: Hey hey, A pair of new pages in the MM documentation in the website are now available, in case you're interested, see the new "WWAN device types" and "Port and device detection" sections in https://modemmanager.org/docs/modemmanager/ Regarding device

Re: Error status monitoring / dbus

On 1/18/23 04:58, Aleksander Morgado wrote: All org.freedesktop.ModemManager1.XX and org.freedesktop.libmbim.Error.XX error codes are coming either from ModemManager or the libraries. DBus specific errors have a different error prefix (org.freedesktop.DBus maybe?) Right, sure. But is it poss

Error status monitoring / dbus

Sorry, this is going to be a basic dbus question I think, but: Tue Jan 17 18:53:35 2023 daemon.notice netifd: wwan (5779): error: couldn't connect the modem: 'GDBus.Error:org.freedesktop.ModemManager1.Error.MobileEquipment.NetworkTimeout: Network timeout' Thu Jan 12 17:32:39 2023 daemon.n

Re: ModemManager 1.20.4 - invalid cast

On 1/9/23 06:11, Aleksander Morgado wrote: Hey Peter, (ModemManager:19419): GLib-GObject-WARNING **: 15:01:34.152: invalid cast from 'MMBroadbandModemQmiQuectel' to 'MMBroadbandModemMbim' ** ERROR:../src/mm-broadband-modem-mbim.c:284:mm_broadband_modem_mbim_peek_port_mbim: assertion failed: (M

Re: ModemManager 1.20.4 - invalid cast

On 1/9/23 06:11, Aleksander Morgado wrote: Hey Peter, (ModemManager:19419): GLib-GObject-WARNING **: 15:01:34.152: invalid cast from 'MMBroadbandModemQmiQuectel' to 'MMBroadbandModemMbim' ** ERROR:../src/mm-broadband-modem-mbim.c:284:mm_broadband_modem_mbim_peek_port_mbim: assertion failed: (M

ModemManager 1.20.4 - invalid cast

Background: I'm trying to implement a "bridge mode" with ModemManager. I have this working with a legacy vendor connection manager, which uses direct qmi library calls, and makes it impossible to use separate qmicli queries, as well as being unsophisticated versus MM, and the monitoring scri

Re: More on shutdown segmentation fault

On 12/6/22 09:22, Aleksander Morgado wrote: I was suggesting to enable dumping core files on SEGFAULT, so that they can be later on analyzed by gdb (without running MM under gdb) Problem is, there's nowhere for a core to go - overlay is being unmounted at this point, and the system reboots mo

Re: More on shutdown segmentation fault

On 12/6/22 08:07, Aleksander Morgado wrote: MM shouldn't write to any file, apart from the log file if you used --log-file=[PATH]. MM does read from several files in the filesystem, but that shouldn't be an issue unless your system is limiting access to certain paths only. Is this the case? T

More on shutdown segmentation fault

Sorry, misplaced the original, but this is what I'm seeing as a reminder: # reboot # [ 532.990424] br-lan: port 1(lan1) entered disabled state [ 533.003610] device lan1 left promiscuous mode [ 533.012515] device eth0 left promiscuous mode [ 533.021723] br-lan: port 1(lan1) entered disabled

Re: ModemManager and d-bus permissions in OpenWrt

On 11/22/22 15:13, Hugo Osvaldo Barrera wrote: On Tue, 22 Nov 2022, at 20:48, Peter Naulls wrote: This is really an OpenWrt question, but I wanted to understand the specifics with MM. We're undergoing a security review, and it's been pointed out that d-bus runs as non-root. I'v

ModemManager and d-bus permissions in OpenWrt

This is really an OpenWrt question, but I wanted to understand the specifics with MM. We're undergoing a security review, and it's been pointed out that d-bus runs as non-root. I've created a new "dbus" user and group like ubus has and have d-bus run under it as per its config file. Everythi

Re: OpenWrt shutdown ModemManager/libglib crash

On 11/8/22 15:12, Aleksander Morgado wrote: Hey If you could have it debugged a bit more, e.g. with gdb in order to get a backtrace, that would be great. Not sure how easy that is in your target device though. I tried briefly, but the problem is that gdb slows everything down, and this mes

Re: OpenWrt shutdown ModemManager/libglib crash

On 11/7/22 10:22, Aleksander Morgado wrote: Hey Peter! This is obviously an awkward point to debug anything, and it's perhaps not super important at this point, but it's pretty repeatable and has happened as long as I can remember. This is with MM 1.20.0, glib 2.70.4 and libqmi 1.32.0. Di

OpenWrt shutdown ModemManager/libglib crash

When rebooting in OpenWrt: [ 548.410590] mtk_soc_eth 1e10.ethernet eth0: Link is Down [ 548.425055] device eth0 left promiscuous mode [ 548.434058] br-lan: port 1(eth0) entered disabled state [ 550.455000] do_page_fault(): sending SIGSEGV to ModemManager for invalid read access from 00

Re: Host data interface IP configuration via DHCP vs via control channel.

On 10/25/22 09:25, Aleksander Morgado wrote: Hey Peter! Hey Alek! No, the DHCP server is running in the modem, to ease the configuration process on the host side. Qualcomm modems have it for sure, there are several other manufacturers that don't. There is no DHCP protocol used in between the

Re: Host data interface IP configuration via DHCP vs via control channel.

On 10/25/22 09:11, Aleksander Morgado wrote: Assuming a mobile connection via any of the available control protocols (QMI/AT/etc) has been initiated. The mobile modem firmware has established a bearer connection and via the (3GPP PCO -Protocol Control Options amongst others) an IPv4 addres

Re: Confirming APN in use

On 10/20/22 05:06, Aleksander Morgado wrote: Hey Peter, In 4G there are 2 different sets of APNs required for a successful data connection: first, the initial EPS bearer settings (a.k.a. attach APN), which is used during modem registration phase; and second the data connection settings (a.k.

Confirming APN in use

This is with ModemManager 1.18.6 and libqmi 1.30.4, but that I'm not necessarily tied to those, that's just what's in our stable code base. This is on OpenWrt 22.03. You'll also excuse the lack of detail in this; I don't think I need to report here the actual APNs we're using here. Now, whe

Re: Telit LN920 rules

On 9/7/22 10:44, Daniele Palmas wrote: Hello Peter, similar port hints were committed to main through https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/commit/53f6c309bfbf87fe2ccb28dc3b9a3775e4e20897 Ah, this is better, thank you. But this was 10 months ago - is there are reas

Telit LN920 rules

Based upon the similar models, this appears to be correct. This is against ModemManager 1.18.10: --- plugins/telit/77-mm-telit-port-types.rules.orig 2022-09-07 09:51:25.186228559 -0400 +++ plugins/telit/77-mm-telit-port-types.rules 2022-09-07 09:56:48.650231458 -0400 @@ -74,6 +74,13 @@ A

Re: OpenWRT 22.03-rc6 / ModemManager not on 1.18.8 Version with the Dispatcher support

On 8/11/22 08:25, Aleksander Morgado wrote: I was writing mostly the same response myself :) But wondering, are there any nightly builds from the master branch or similar for that specific architecture? Maybe there is already an existing .ipk for the MM version in master that could be installed

Re: OpenWRT 22.03-rc6 / ModemManager not on 1.18.8 Version with the Dispatcher support

On 8/11/22 06:29, Thomas Landgraf wrote: I wanted to test the new dispacher script for carrier network drop. I figured out in 22.03-rc6 the opkg package https://downloads.openwrt.org/releases/22.03.0-rc6/packages/arm_arm1176jzf-s_vfp/packages/modemmanager_1.18.6-1_arm_arm1176jzf-s_vfp.ipk

Re: openwrt netifd integration improvements with new dispatcher scripts

On 3/29/22 09:29, Aleksander Morgado wrote: Hey, The current openwrt integration suffered from a serious problem: network initiated disconnections were properly detected by MM but never reported to netifd. Due to this, the modem may end up in registered state while netifd thinks it is still conn

Tab in name output for JSON

This is a return to an issue I mentioned quite some time ago; there were some questionable characters in the model name output. https://gitlab.freedesktop.org/mobile-broadband/libqmi/-/merge_requests/159 This results in a tab character in the JSON output too: "model":"EM12-AW\t" Now, you c

LTE error codes / call rejections

I'm looking at these two errors: wwan (31502): error: couldn't connect the modem: 'GDBus.Error:org.freedesktop.ModemManager1.Error.MobileEquipment.Unknown: Call failed: cm error: lrrc-connection-establishment-failure-not-camped Tue Feb 8 15:16:38 2022 daemon.notice netifd: wwan (6885): err

Re: No PPP / limit plugins first draft patch

On 1/17/22 12:21 PM, Peter Naulls wrote: This removes PPP entirely from consideration in ModemManager. This has 2 patches - one for the OpenWrt build (against the 21.02 release(ish)) and MM itself (against 1.18.4). This is definitely incomplete. In particular, the MM scripts still reference

Re: ANN: ModemManager 1.18.4 released / Avoiding PPP

On 1/18/22 11:04 AM, Dan Williams wrote: What's your desired error state when detection fails? Just mark the whole modem as failed, and you'd have some custom logic to twiddle modem power and/or reboot the machine? I don't know the ins and outs of the error mechanism, so you tell me - but wha

Re: ANN: ModemManager 1.18.4 released / Avoiding PPP

On 1/17/22 2:06 PM, Dan Williams wrote: own problems, but maybe not the ones you're worried about. I haven't read the whole thread in detail, so forgive me if this was covered. Perhaps a way of tagging a modem/driver/whatever with "never use PPP" would be workable. Off by default of course. I

No PPP / limit plugins first draft patch

This removes PPP entirely from consideration in ModemManager. This has 2 patches - one for the OpenWrt build (against the 21.02 release(ish)) and MM itself (against 1.18.4). This is definitely incomplete. In particular, the MM scripts still reference pppd. And ppp (pppoe in particular) is s

Re: ANN: ModemManager 1.18.4 released / Avoiding PPP

On 1/14/22 10:09 AM, Aleksander Morgado wrote: logic is not going to change. If MM detects a single TTY port, it's going to default to use PPP. It's not a fallback to PPP, it's using whatever it has for data connection, if PPP is the only way forward, PPP will be. I don't want PPP, ever. I do

Re: ANN: ModemManager 1.18.4 released / Avoiding PPP

On 1/14/22 9:01 AM, Aleksander Morgado wrote: Hey, So removing the timing logic is not possible; but why not add an extremely longer value that will definitely be safe? E.g. why not set EXTRA_PROBING_TIME_MSECS to 6 to make it wait up to 1 minute in between port additions in the same dev

Re: ANN: ModemManager 1.18.4 released / Avoiding PPP

On 1/14/22 4:28 AM, Aleksander Morgado wrote: Hey Peter, For a quick workaround in your case, can you try modifying EXTRA_PROBING_TIME_MSECS in mm-plugin-manager.c and change it from 1500 to something bigger like e.g. 3000 or 4000? There's one thing clear though; the longer timeout should not

Re: ANN: ModemManager 1.18.4 released / Avoiding PPP

On 1/12/22 9:58 AM, Aleksander Morgado wrote: Hey, I'm not sure there's an easy way to do that; but in this case we may also be interested in the QMI messages really, because we also want to make sure the port probing is working as expected; i.e. if this issue happens not only upon MM start,

Re: ANN: ModemManager 1.18.4 released / Avoiding PPP

On 1/12/22 9:16 AM, Aleksander Morgado wrote: Hey, The list of available ports is decided during probing. If probing ends with only 2 TTY ports (as in the log you posted earlier), then QMI will be fully ignored and the net port will never be used. We really need to fix the probing phase so th

Re: ANN: ModemManager 1.18.4 released / Avoiding PPP

On 1/12/22 4:25 AM, Aleksander Morgado wrote: Hey Also, please note that if you fully disable the PPP usage (maybe making sure that data_at_primary is always NULL in mm_base_modem_organize_ports()), what you will achieve is that the modem ends up not usable ("Failed to find a data port in the m

Re: ANN: ModemManager 1.18.4 released / Avoiding PPP

On 1/12/22 4:25 AM, Aleksander Morgado wrote: In the openwrt git master branch (which I believe it's what you're using) that logic was updated to use a new wrapper script in /usr/sbin/ModemManager-wrapper, and this scripts introduces a bogus "sleep 2" in between the MM start and the call to mm_r

Re: Quectel GNSS errors addition

On 1/12/22 3:55 AM, Aleksander Morgado wrote: The main problem with these errors is that they're not standard 3GPP errors, they're vendor-specific, and at the moment there is no support for configuring and enabling vendor-specific error codes. It would be great to have that support somehow; e.g

Re: ANN: ModemManager 1.18.4 released / Avoiding PPP

Also, please note that if you fully disable the PPP usage (maybe making sure that data_at_primary is always NULL in mm_base_modem_organize_ports()), what you will achieve is that the modem ends up not usable ("Failed to find a data port in the modem"). You need to decide whether that's better t

CRSM parse/Emergency numbers

I'm seeing this. [16076]: [1641922135.360300] [modem0/sim0] couldn't load list of emergency numbers: Failed to parse CRSM query result '+CRSM: 148,8,""' Seems like the regex in mm_3gpp_parse_crsm_response needs some work. Here it is: r = g_regex_new ("\\+CRSM:\\s*(\\d+)\\s*,\\s*(\\d

Quectel GNSS errors addition

I'm looking at the errors returned by some of the GPS operations. e.g.: /usr/bin/mmcli -m 0 --command=AT+QGPSEND error: command failed: 'GDBus.Error:org.freedesktop.ModemManager1.Error.MobileEquipment.Unknown: Unknown mobile equipment error: 505' These are documented here: https://sixfab.

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 tha

Re: Extending OpenWRt ModemManager protocol handler

On 1/10/22 8:46 AM, Aleksander Morgado wrote: Hey Peter, 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 doesn't do anything about multiple modems, but here's my pat

Re: Extending OpenWRt ModemManager protocol handler

On 1/10/22 4:32 AM, Enrico Mioso wrote: 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 doesn't do anything about multiple modems, but here's my patch for

Re: ANN: ModemManager 1.18.4 released / Avoiding PPP

On 1/1/22 2:33 PM, Aleksander Morgado wrote: Hey Peter, I see. So the problem is that I have to keep port 02 open for mmcli commands, but if I do it'll try to use this for PPP still sometimes. Please note that the reason to use PPP is not that MM sometimes prefers it over QMI+NET. If PPP

Re: ANN: ModemManager 1.18.4 released / Avoiding PPP

On 12/30/21 8:28 AM, Aleksander Morgado wrote: Hey, # AWC EM12-AW # ttyUSB0 (if #0): QCDM/DIAG port # ttyUSB1 (if #1): GPS data port # ttyUSB2 (if #2): AT primary port # ttyUSB3 (if #3): AT secondary port ATTRS{idVendor}=="2c7c", ATTRS{idProduct}=="0512", ENV{.MM_USBIFNUM}=="00", SUBSYSTEM=

Re: Consultation about QMI CID Leaks

On 12/28/21 4:59 AM, Aleksander Morgado wrote: Hey, We have created the issue in Gitlab and uploaded all the logs that related. https://gitlab.freedesktop.org/mobile-broadband/libqmi/-/issues/81 Please contact us if there is still anything missing. Waiting for your kind reply. Thanks! You

Re: ANN: ModemManager 1.18.4 released / Avoiding PPP

On 12/3/21 9:52 AM, Aleksander Morgado wrote: Hey, And two, that we never, ever try to use PPP. To that end, I may need to fashion a patch to make this so - maybe just a runtime option to stop it being used. Actually removing it from the build is more work than I care to take on. You can a

Re: OpenWRT, ModemManager, Sierra EM7455, IP passthrough

On 12/4/21 1:31 PM, James Thomas wrote: Evening all, I’ve been racking my brains trying to figure out how I might, in OpenWRT, get modemmanager and netifd to ‘passthrough’ the IP assigned in the bearer when making an mbim connection to a client connecting to eth1. My aim, as I’m sure is appa

Re: ANN: ModemManager 1.18.4 released

On 12/3/21 3:48 AM, Aleksander Morgado wrote: Hey, However, and by all means convince me otherwise, I could still see the fall though case to PPP happening when things are not quite ready with the USB stack, QMI driver, etc. And that's a real problem for me. Here we're relying on two thin

Re: ANN: ModemManager 1.18.4 released

On 12/2/21 4:46 PM, Aleksander Morgado wrote: The udev rules themselves are robust. The problem may be the time required by the module to expose the ports in the system, and the time required by the module to actually reply anything in those ports. Those two last things are handled by timeouts

Re: ANN: ModemManager 1.18.4 released

On 12/2/21 10:24 AM, Aleksander Morgado wrote: Hey Could you please test the following single patch on top of 1.18.4? https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/700 I ran through a couple of test cases and this appear to be doing the right thing. Thanks.

Re: ANN: ModemManager 1.18.4 released

On 12/1/21 4:11 PM, Aleksander Morgado wrote: Could you please test the following single patch on top of 1.18.4? https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/700 I ran through a couple of test cases and this appear to be doing the right thing. Thanks.

Re: ANN: ModemManager 1.18.4 released

On 12/1/21 5:11 AM, Aleksander Morgado wrote: Hey Peter Wondering, would you be able to also test 1.18.4 but with these 2 changes reverted? The regex related fix was a big one, maybe it broke something else. 2beae71a6 kerneldevice,generic: simplify DEVPATH matching logic 1bd70df8a kerneldevi

Re: ANN: ModemManager 1.18.4 released

On 11/29/21 11:12 AM, Dan Williams wrote: Do you have debug logs from MM? At the very least MM has to find a netdevice for the modem, otherwise it would fall back to an available AT port for PPP. Does MM find one? Here are two logs to compare. In both cases the kernel is 4.14.256; the only d

Re: ANN: ModemManager 1.18.4 released

On 11/26/21 4:52 AM, Aleksander Morgado wrote: Hey hey, This is the second bugfix release in the 1.18.x series, built from the mm-1-18 branch. Thanks! I've been chasing, as I mentioned a while ago, where "sometimes" the modem connection will be brought up as PPP, not qmi. This kind of con

Re: Static vs DHCP setups from ModemManager in OpenWrt

On 7/15/21 5:49 PM, Nick wrote: Hey, What is your solution for MM not giving up in the end? Maybe we can merge it into OpenWrt. As per previous post: https://lists.freedesktop.org/archives/modemmanager-devel/2021-July/008741.html But no hurry; I'll probably making some improvements to tha

Re: Static vs DHCP setups from ModemManager in OpenWrt

On 7/15/21 3:54 PM, Aleksander Morgado wrote: After restart of ModemManager and then ifup wwan, reconnection is successful. Oh, is this AT+PPP based really? You should have started from there :) Being a Quectel chipset, is it by any chance Qualcomm based and you could use QMI instead of AT

Re: Static vs DHCP setups from ModemManager in OpenWrt

On 7/15/21 9:57 AM, Aleksander Morgado wrote: After restart of ModemManager and then ifup wwan, reconnection is successful. Strange. What modem is this? Sorry to add to the posts, but further testing shows another case where this recovery didn't help. I don't have a good log of this, but

Re: Static vs DHCP setups from ModemManager in OpenWrt

On 7/15/21 9:57 AM, Aleksander Morgado wrote: Hey, You should never need to do that really. If the setup works again after restarting MM, there may be some additional thing to fix somewhere in MM itself. No doubt; however, I require a short term solution that robustly reconnects, even if it

Re: Static vs DHCP setups from ModemManager in OpenWrt

On 7/12/21 4:50 PM, Aleksander Morgado wrote: you should ifdown & ifup the network interface configured in netifd in order to reconnect. No such luck: (sorry for the wrap) hu Jul 15 13:31:11 2021 daemon.notice netifd: Interface 'wwan' is setting up now root@AWC-EI:~# Thu Jul 15 13:31:11 2021

Retries in OpenWrt scripts

Here's a local modification I have to the modemmanager.common script in OpenWrt. Without it, the system will give up, if the readiness of the modem takes too long. This can happen with a number of cases, but in particular, this happens on first boot, when OpenWrt is preparing the flash, as n

Re: Static vs DHCP setups from ModemManager in OpenWrt

On 7/12/21 4:50 PM, Aleksander Morgado wrote: The type of IP setup is decided by ModemManager; for some plugins/protocols DHCP will be used, for some others static IP addressing. E.g. if you're running with a QMI modem and the network interface is configured in raw-ip, static IP addressing will

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 sta