ModemManager : netifd integration does not work if pppd is not installed

[jonesmz]

Maintainer: @aleksander0m
Environment: ModeManager 1.12.2 from #10746

Description:

If the pppd program is not found at /usr/bin, then the modemmanager proto integration with netifd does not work, even for modems that do not require pppd.

The expected behavior is that pppd functionality is disabled, but that the ModemManager integration with netifd works otherwise.

[aleksander0m]

Maintainer @nickberry17 ;)

[aleksander0m]

I understand the reasoning, but from the ModemManager point of view, MM doesn't know whether a given modem will be managed by pppd until the modem is probed and support checked. E.g. a MC7455 will be used in QMI mode if the corresponding kernel drivers (cdc-wdm, qmi_wwan) are available; if they are not, MM will use pppd over the exposed TTY ports.

There is no way to completely disable the PPP based support from ModemManager, and so, from my point of view, requiring pppd for the MM protocol handler is the way to go.

Although, I guess we could also make the protocol handler detect whether pppd exists or not and fail the connection if MM asks to use PPP and pppd is not available. I really don't know what to suggest here. From my point of view pppd should be a dependency of the package, if it isn't already.

[jonesmz]

My modem does not require pppd, therefore I do not want to have pppd installed.

If ModemManager encounters a modem that it needs to manage with pppd, and pppd is not available, then it should error out.

But ModemManager should not simply refuse to operate at all, without any error output.

Right now, it doesn't even register with netifd at all.

Took me almost an hour to figure out what it was having trouble with.

[aleksander0m]

Your modem may require pppd if the proper system support for other connection methods is not available. Before the modem is probed by MM, we cannot know whether pppd or dhcp or static IP addressing is going to be used. In order to avoid issues like the one you have, the ModemManager package should depend on pppd, that is the clean solution to the most generic problem, and that would have prevented the runtime error with netifd not loading the MM protocol handler.

Now, if you specifically want to avoid having pppd installed at all, you may also need to update the protocol handler yourself to allow that. I don't think the generic MM protocol handler installed by the MM package should be in charge of doing that, but if you'd like to suggest a build option in the MM openwrt package in order to handle that possibility, please do so. E.g. we could depend on pppd by default unless disabled by a config option in the package, and if so, the protocol handler should error out if attempting to connect a modem that requires ppp.

Either way, a fix should be made right away in the MM packaging because it should depend on pppd as it may be a runtime dependency depending on the modem being used.

[jonesmz]

I don't think you understand, my modem works just fine without pppd, and I don't want pppd installed. Pppd is one out of 4 connection methods, and should not be installed by default.

The default behavior of packages should be opt-in, not opt-out. OpenWRT is installed on systems with extremely limited storage space, and very frequently hardware that is known and completely unchanging. If pppd is discovered to be needed at runtime, and is not found, throw an error. Don't require it by default.

[aleksander0m]

@jonesmz believe me, I do understand. I know that your modem works just fine without pppd (if the required additional kernel drivers are installed). I assume you have a QMI or MBIM capable modem, is that right? See, if you don't install the QMI or MBIM kernel drivers, your modem would be managed by ModemManager requesting to use PPP for data, and it is exactly the same hardware. I understand that you have a custom setup, and in your case you know what your modem will be and how it should be best managed. A lot of setups are like yours, custom setups where you know what your modem is, with a custom openwrt where you have decided you don't want to have pppd.

Now, from the ModemManager packaging point of view, pppd should not be an optional thing, because the current protocol handler may end up using it if required. There is absolutely no discussion on that, the protocol handler will fail, as you found out, if pppd is not installed. That, by itself, is a bug to fix.

What I'm suggesting is, if you're up to the task and the package maintainer wants to support it, please prepare a branch where pppd ends up being "optional" from the protocol handler point of view, and modify the protocol handler however it needs to be modified in order to cleanly error out if MM says that pppd must be used and there is no pppd installed. If that kind of logic is desirable in openwrt, please suggest a pull request with the changes. At the end, remember, it's MM own logic deciding what the IP connectivity method should be during runtime; and from my point of view, it's far better to solve that issue early (i.e. making sure that pppd is installed) than having tons of users coming afterwards saying that connection failed because pppd wasn't found (and the package maintainer would have to deal with that).

From my personal point of view, though, the easy and clean way forward is to have the MM package require pppd. I know this may not be the usual openwrt way, but hey, MM is not a usual openwrt package anyway, given the huge size of all its dependencies (where pppd would be just a bit more) :)

The target of MM is to support as many modems as possible with the same kind of user configuration required, leaving all the magic of what protocol to use or what IP setup to prepare to the actual MM daemon, without the user needing to know anything about all that. If you're worried about dependency sizes or you want to force using a specific protocol always like QMI or MBIM, you may prefer to use the much more suited uqmi or umbim based protocol handlers instead?

[mips171]

Hi @jonesmz, We already had a similar discussion here #10217 (comment), the consensus was that MM is already a larger package anyway and we should not break functionality to save some space. I checked the pppd binary and it seems to be approximately 200kb, bringing the total MM installation + deps to around 1.2MB. If size is a concern, there are already other far more lightweight alternatives in OpenWrt such as uqmi, umbim and comgt.

If it is possible to rewrite the netifd protocol handler to clearly indicate to the user that this runtime dependency is missing, and someone is willing to maintain it, then I think most of us would be open to having that in OpenWrt. In the case of MM, I think pppd it would need to be an "opt-out" as it is so integrated into MM. Patches welcome. In the meantime I agree with @aleksander0m, and think we should treat this as a bug by fixing the package so all runtime dependencies are available so as to prevent crashes.

[jonesmz]

Alright that's fine.

However, please know that uqmi is not a suitable replacement. It has numerous bugs that my team has spent considerable amounts of time trying to address (without success). I'm trying to get a series of actionable bug reports put together, but have been having difficulty creating minimal reproductions to demonstrate the problems.