[RFC] TTY port locked problems when using PPP

Aleksander Morgado aleksander at aleksander.es
Thu Jun 27 08:20:10 UTC 2019

> wt., 18 cze 2019 o 14:43 Aleksander Morgado <aleksander at aleksander.es>
> napisaƂ(a):
> > My opinion is a bit open on this, I liked the first way because we
> > would try to be as robust as possible and totally avoid using the port
> > with wrong CLOCAL settings, but I don't think we can have that
> > robustness unless we're truly in sync with NM and pppd, and for that
> > we need either #2 or #3. And if we target to be in sync, then I don't
> > think #1 is needed, we should always try to enforce being in sync
> > instead. I'd vote to have #2 in MM 1.8 and MM 1.10 and #3 for the next
> > MM 1.12?
> >
> > Comments welcome!
> Maybe this is too bold, but did you consider starting pppd from
> ModemManager? It seems to me that the dance around the shared resource
> which is tty port in this case with NetworkManager will always be
> error prone. And with pppd being actually low-level detail related
> with certain modems it's kind of leaky abstraction that the NM has to
> start it for the network interface to appear (once MM will make the
> port ready). I don't think NM has to do anything similarly special
> around qmi or mbim modems.

Yeah, this approach is also open, and I briefly talked about this with
Alfonso last time. It could be done in a way that is backwards
compatible, e.g. with the client that requests the connection (e.g.
NetworkManager) specifying whether it supports that MM is the one
running pppd instead of the client. E.g. NetworkManager could pass a
new "allow-pppd" property set to "yes" when calling Simple.Connect()
or Bearer.Connect(), and if MM receives that property it will take
care of running pppd itself, instead of just connecting the port. This
way of working would allow us to have a newer ModemManager running
with e.g. older NetworkManager or other connection managers that don't
expect MM to run pppd itself.

The main issue with this approach is that ModemManager would do a lot
of tasks that were exclusively done by NetworkManager before, like IP
addressing setup or IP routing setup. I'm sure we can instruct NM to
play nicely with those being done by MM, but not sure how easy that
would be. @Dan Williams @Thomas Haller @Lubomir Rintel any
suggestion/comment on this?


More information about the ModemManager-devel mailing list