[RFC] TTY port locked problems when using PPP

Aleksander Morgado aleksander at aleksander.es
Thu Jun 20 05:18:45 UTC 2019

> Have you seen the following commit from NetworkManager for pppd?  It has helped solve many of the issues of being in sync with pppd and MM that I have seen:
> https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=a251712a729f676c9c2d38e469e4f88e250229ba
> Even with that patch, there was still an occasional instance when the forced closed issue would occur, but it was much less often.

Yeah, that patch should mitigate the race condition, but there's still
one because MM and NM are not in sync.

> I have been adding work arounds of my own to get around this issue since MM 1.8.0.  I think what you laid out using #2 for the existing versions of MM (1.8.X and 1.10.X) works for those versions since it doesn't make breaking changes.
> For the next version of MM, #3 will work, but I would suggest falling back to #2 if the version of NetworkManager is before the version that added the usage of the Disconnect().  Without a check on the version or checking if the Disconnect() support is implemented in NetworkManager, then MM might make things worse in a configuration with a new MM and older NM.  In this case the serial port would never recover from a data session since there is nothing to call Disconnect().
> If you could implement #3 with detection of if Disconnect() is implemented, and if not fall back to #2.  Then you could implement this in all currently supported versions of MM (1.8.X and 1.10.X).  This would support situations where an older MM is present with a newer NM.

The approach #3 should be totally compatible with #2 I believe, there
would be no need to add any version check to do things differently.
Let me explain.
In approach #2, by making MM never report itself the PPP-based bearer
as disconnected, we're forcing the upper layer to always call
Bearer.Disconnect(). This is how the logic worked up to MM 1.8
already, the Disconnect() method is not new.
In approach #3, we would be adding an optional signal, e.g.
"needs-disconnect" that MM would use to notify the upper layers that a
disconnect is needed, and so NM (or any other connection manager) can
monitor that signal and call Bearer.Disconnect() explicitly. If NM
does not monitor the signal, the behavior would be 100% equivalent to
#2 already; i.e. NM/pppd need to detect the disconnection themselves
and call Bearer.Disconnect().


More information about the ModemManager-devel mailing list