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