Modemmanager

[Salvatore Grijalva]

And in there, there are a bunch of reconnect scripts which you should check and see how to bring the modem up (for example in _PPP_Installer/blob/master/ppp_installer/reconnect_cellulariot they state that gpio 17 is to bring the modem out of reset and gpio 24 is to power on the modem). You would need to export from userspace for example and set the gpios they use there. But you should really have a schematics for this, otherwise parse the above and see which one do the job.

Hi Frans, based on your previous message, it sounded like the modem was working, if you used their install.sh script. What is not working, or, more precisely, what do you need to debug in modemmanager exactly? Any extra information you can provide would help us get you moving in the right direction. Thanks.

suggests that the port is being filtered by MM and it is not being probed.
The approach of flagging the platform TTY should work. I would also suggest trying a flag the serial platform device, with something like:

If so, then check that mmcli -L can see the modem.
As a side note, according to MM documentation at -overview-modem-filter.html, the ID_MM_PLATFORM_DRIVER_PROBE is kept for backward compatibility. The ID_MM_DEVICE_PROCESS flag replaces it.

I think at this point it is best to contact the ModemManager developers on their modemmanager-devel mailing list. They are quite friendly and will provide useful insights. At least we will know whether this is currently possible under ModemManager - hopefully this is something that could be resolved through configuration only.

It seems mmcli connect after disconnect is pretty much instantaneous and new IP details are reported in logread. But how to get those new details from modemmanager to netifd? Since otherwise 'ifstatus wan' shows bad details despite the proper reconnect.

The way to solve this, after briefly talking with @jow- about this in IRC would be to have the netifd protocol handler launch a "watcher" process which brings up the connection, and is kept alive and running for as long as the network interface is assumed connected. If MM detects a network-initiated disconnection, the dispatcher script called by MM should kill that watcher process. At that point, netifd (if configured to autoconnect) will then kill the netdev, restart that process and await proto updates.

Excellent call. That significantly reduces the reconnect time on my NR7101 from around five seconds to around three seconds. I wonder in what situations the temporally costly modem disable is actually needed?

My view of the protocol handlers is that they are designed to be simple - setup and teardown (+renew). When MM starts up (and before ifup), it puts the modem in initialized/disabled. state, so it makes sense for teardown to put it back in disabled state on ifdown.

A year later, in the latest openwrt 23.05 and main line tasks.
There is still no change in the Modemmanager, and I cannot reconnect myself after disconnecting the link.
You must manually click Reconnect on the network port interface to work properly.
Is anyone willing to think of a solution?

Well, it works with ModemManager only. ModemManager is quite big and thus unwelcome on smaller devices. When used with Huawei modems, it needlessly disables IPv6 (see my bug report from 5 years ago). Also, it is incompatible with luci-app-3ginfo-lite and luci-app-sms-tool-js from @IceG. So, it is not a universally acceptable solution, but, sadly, we don't have any other.

The problem I see with uqmi and most other tools is that they need exclusive access to cdc-wdm device and/or USB serial (AT command) port. So a centralized daemon to manage/serialize requests and monitor/notify on events is probably need. This is more or less exactly what MM already does - heavy as it is I find it well architected, with an API/library, modem drivers etc.

It'd be great if we could get some feedback from the OpenWRT gurus on what the ideal architecture to manage the modem (re)connections would be, as I believe ifdown/ifup may be too heavy (slow) for this task. Otherwise we'll be stuck in the world of scripts and hacks.

What would be the correct netifd way to skip the 'ifdown' and hence the teardown call in /lib/netifd/proto/modemmanager.sh, and simply call the setup, which I think in /lib/netifd/proto/modemmanager.sh is:

Looking at the way ppp protocol handler is implemented, it seems the teardown will receive exit code from the monitored protocol app. So I would suggest using return value from the mmcli tracking (from the new PR) to differentiate reconnect vs intentional ifdown, and then skip disable if the teardown is triggered by monitor process exiting.

actually calls ifdown twice - once for the proto_init_update/send_update and a second time because ifup includes an ipdown call. But I'm hazy because I'm struggling to untangle the netifd stuff and I'm not seeing any helpful documentation (including here).

I know slightly off topic but can the interface also reboot based on low bandwidth or as such as I have the issue of the system locking in 3g mode and not Jumping back.
I did do a post on the cake autorate thread but it might be more appropriate here.
CAKE w/ Adaptive Bandwidth - Community Builds, Projects & Packages - OpenWrt Forum

Just to check you have only the one script and not two in that connection.d folder? And did you add the wording about automatic reconnect? Also, interaction with mwan3 may lead to issues and should be checked over.

I am working on backporting luci-proto-modemmanager to 19.07, however ran into an issue and want to see if anyone else has the same. ModemManager is unable to find a modem when it is identified with /dev/cdc-wdm0 instead of the full sysfs path (using the real path is best practice anyway), so I am thinking we will need some logic to find the realpath in sysfs, just as it was in the original luci-proto-modemmanager linked at the top of this thread.

I am using my own compiled version of 19.07, and the luci-proto-modemmanager module is marked as broken by default.
I did some dirty patching, and copied the luci-proto-modemmanager, libmbim and libqmi sources over the 19.07 sources, and managed to compile the firmware, and upgrade to it.
On the Luci interface however there is a dropdown menu where normally one would be able to choose the modem device, but the list is empty and no commit is allowed with that selection being blank.

I use a D-Link 4G/LTE modem, which creates 4 /dev/ttyUSBx devices.
The ModemManager instance running on the firmware successfully picked up the modem, and listed the sysfs path for the device.
I then went ahead and edited the /etc/config/network uci config to add a device entry (equal to the sysfs path shown in the modemmanager logs) to the appropriate interface config, but my changes were not reflected on the Luci interface.

I don't know anything about the luci-proto-modemmanager plans, but am a bit worried about the limited exposure the features you propose would have. Features without users will eventually detoriate and become useless. in my experience.

There are a limited number of LTE/3G/5G users on OpenWrt. Very few of them are using ModemManager. And some of those aren't using Luci. The number of users are too few to ensure full feature testing coverage already here. Then let's say we add PUK entry. How many users are actually going to need that? You're "lucky" if there is one at all. And image selection? That's very modem specific. There might be a couple of users with an MC7455 or similar, but they probably already flashed and selected the image they want to use. It's not like it's something you do all the time for normal usage. And double SIM? There are very few users who have the hardware support for that. And most of those probably won't use it. It's not very useful for a stationary WAN link, which I assume is most common to OpenWrt users. It might be useful for those having a mobile OpenWrt installation. But that is probably a very limited number of users.

Hi,
I don't think "There is a limited number of LTE / 3G / 5G users on OpenWrt" is true.
I know many people who have turned to LTE internet connection due to the surprisingly poor cable connection. In fact, I am one of them.
I am a member of a community where all members use LTE / 4G home connection 24/7, and considering we are more than 1000 members limited to my country it makes me think there could be many uses for such features.

There are a lot of choices available of embedded systems that support m.2 or PCIe modems and people are really interested in finding open solutions because they are really cheaper and more featured than branded ones.
Unfortunately, the lack of ease of configuration and stability in managing protocols for 4G / LTE modems is a strong incentive to avoid the OpenWrt solution.

I don't think "There is a limited number of LTE / 3G / 5G users on OpenWrt" is true.
I know many people who have turned to LTE internet connection due to the surprisingly poor cable connection. In fact, I am one of them.

OK, I do not have any numbers to back up my statement, so my impression could definitely be wrong. And I definitely agree that the number of users is going to increase, with 5G fixed wireless access pretty much replacing DSL over the next few years.

And I do understand that modem firmware upgrade might be a required feature. The reason I consider the number of users limited wrt that is because it's a much more hardware specific feature than the rest of the modem management. MBIM and QMI hides most of the differences between modems, making an old D-Link 3G modem behave pretty much the same as a modern Quectel 5G modem. I believe this is one of our major success stories. Qualcomm always have pushed a new driver per modem with minor differences. It was Microsoft who forced them to accept MBIM. But we managed to make the same qmi_wwan driver support all of the Qualcomm modems. And that's not just across vendors, but also across chip generations with support for anything from the 1st generation Gobi1k of 2007 to the most powerful 5G modems of 2020.

c80f0f1006