> > 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(). -- Aleksander https://aleksander.es _______________________________________________ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
