Infinite connection loop

[Aleksander Morgado]

Hey,

> It looks like I celebrated prematurely. As soon as I disabled the debug-level logging for NetworkManager and ModemManager, the issue started to appear again. This tells me that there is some sort of race condition. I’ll look into this more but I’d appreciate if one of the maintainers could explain the desired/expected series of events when the peer hangs up and pppd terminates.
>

I agree this could be some sort of race condition. The root issue, as
far as I can tell, is that modem control lines are in effect (CLOCAL
config in the TTY) when ModemManager is running, and that should NOT
happen. ModemManager does NOT want modem control lines in effect
(CLOCAL=1) and it looks like pppd left them configured (CLOCAL=0).

Here's the sequence:
 * ModemManager configures TTY with CLOCAL=1 and does everything it
needs to do to have the TTY connected after an ATD call.
 * As soon as the TTY is connected, MM says "hey, this TTY is now
connected and someone should run pppd on it".
 * NetworkManager receives the message from MM and launches pppd on the TTY.
 * pppd boots, and opens the TTY itself, and sets CLOCAL=0 because
pppd wants the modem control lines in effect.

Now we assume a user disconnection via NM...
 * NM stops pppd upon the disconnection request.
 * When it stops, pppd resets to the original TTY settings with CLOCAL=1.
 * Once NM see pppd has fully exited, it notifies MM that it can use
the TTY again.
 * MM recovers the control of the TTY: it does a full reopen, does
port flashing (baudrate=0 temporarily) and then reconfigures input
callbacks.

A crash in pppd, as I understand it, could lead to some time with
CLOCAL=0 (modem control lines in effect) between NM detects the crash
and we reconfiguring the port. Maybe that's related?

-- 
Aleksander
https://aleksander.es