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.
