ANN: ModemManager 1.18.4 released
peter at chocky.org
Fri Dec 3 00:01:38 UTC 2021
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 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).
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.
More information about the ModemManager-devel