ANN: ModemManager 1.18.4 released

[Aleksander Morgado]

Hey,

> > 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 in ModemManager, and if
> > there are race conditions leading to falling back to PPP, the things
> > to fix would be those timeouts usually.
>
> Certainly. And that's precisely what I meant. There's various systems
> in play, with different timeouts and what not.
>
> > The issue we've seen here has been a bad interpretation of how the
> > udev rules are written, and on top of that, the fact that for openwrt
> > we have a custom rules parser that is far from perfect. A solution to
> > solve all this would be to fully avoid using udev rules, and provide
> > our own setup rules for both udev and non-udev systems. The own setup
> > could be equivalent to what we already do with the custom parser, just
> > specifying which are the very specific types of matches we support,
> > for example. If someone wants to work cleaning that up let me know :)
>
> Well yes. And I agree, an integrated udev solution is usually better,
> and avoids steps and extra processes and what not.  This is probably
> non-trivial though, given the system has to support non-udev usage too
> (default OpenWrt setups need a bunch of stuff turned on for udev to even
> work in my experience).

What I mean is, in OpenWRT we already have a "fake udev rules
processor" that reads the udev rules and applies them in runtime when
the port is detected. That's already working. My suggestion here is to
remove the "real udev rules support" so that we just rely on our
custom rules processor everywhere. If we have to make it work in
openwrt, there's no reason why it should not also work in the same way
for setups with real udev.

>
> 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 things: the kernel exposes all ports
(control and data) of a given single device in a certain amount of
time; plus, the modem makes those exposed ports functional in a
certain amount of time. If for any reason those things go wrong, the
MM probing will fail. The only thing we could do to avoid this is to
extend the timeouts, but by doing so, we're also imposing a penalty on
other devices for which we don't have port type hints and require full
port probing. In other words, we should not increase the timeouts to
extremely high values just to wait enough for the modem to reply or
for the kernel to expose the ports, as that will break other use
cases. We've seen the newer PCI based devices take up to 40s to reply
anything in the control ports since the ports are exposed, which is
really bad, and forces us to have long timeouts :/ So, yes, it's a
real problem. The setup cannot be fully reliable because we assume
behavior from other components that is also not reliable, we just try
to mitigate those behaviors in MM as much as possible. But hey, open
to suggestions on how to improve this, it's been an ongoing process in
the past 10 years. If you ask me, the current setup is very stable,
apart from unfortunate bugs like the one that did bite you :)

-- 
Aleksander
https://aleksander.es