'port forced close' after failed ppp

[Dan Williams]

On Tue, 2017-03-14 at 14:18 +0000, Colin Helliwell wrote:
> > On 13 March 2017 at 09:53 Colin Helliwell <colin.helliwell at ln-syste
> > ms.com> wrote:
> > 
> > > On 13 March 2017 at 09:06 Colin Helliwell <colin.helliwell at ln-sys
> > > tems.com> wrote:
> > > 
> > > > On 10 March 2017 at 16:54 Aleksander Morgado <aleksander at aleksa
> > > > nder.es> wrote:
> > > > 
> > > > On Fri, Mar 10, 2017 at 5:43 PM, Aleksander Morgado
> > > > <aleksander at aleksander.es> wrote:
> > > > 
> > > > > > > > mmcli -m 0 --enable
> > > > > > > >  mmcli -m 0 --simple-connect="apn=wap.vodafone.co.uk"
> > > > > > > >  pon
> > > > > > > >  ... success ...
> > > > > > > >  poff
> > > > > > > >  mmcli -m 0 --simple-disconnect
> > > > > > > > 
> > > > > > > > Then trying again to connect fails with 'forced close'
> > > > > > > 
> > > > > > > I'd consider this an MM bug then. But as a workaround,
> > > > > > > try passing the
> > > > > > > "local" option to pppd, which disables its munging of
> > > > > > > modem control
> > > > > > > lines and thus prevents a port hangup. Does that help?
> > > > > > 
> > > > > > No, changing 'modem' to 'local' doesn't help.
> > > > > > I'm not sure where this hangup is coming from - is it being
> > > > > > signalled from the pppd process to MM, or is it that MM is
> > > > > > seeing a change on the port lines via the driver? (Would it
> > > > > > help if I tried to find out?)
> > > > > 
> > > > > Just to confirm it, could you trace pppd to see if it re-sets 
> > > > > CLOCAL
> > > > > before exiting?
> > > > 
> > > > Some more context...
> > > > 
> > > > pppd will by default, unless configured otherwise, unset
> > > > CLOCAL, which
> > > > in turn enables the carrier detect modem control line. pppd
> > > > uses this
> > > > to e.g. detect disconnections reported by the other end. When
> > > > pppd
> > > > exits, it re-sets the serial port configuration to what was
> > > > found when
> > > > the daemon was called. If CLOCAL was set before, pppd will re-
> > > > set
> > > > CLOCAL again.
> > > > 
> > > > ModemManager needs to work always with the ports with CLOCAL
> > > > set (i.e.
> > > > ignoring carrier detect).
> > > > 
> > > > Some years ago I fixed a bug in NetworkManager which was
> > > > triggered by
> > > > this logic; NM was telling MM that the port was disconnected as
> > > > soon
> > > > as pppd reported "PHASE_DISCONNECT", and MM was taking control
> > > > of the
> > > > port at that time. The problem was that at that time, pppd
> > > > didn't yet
> > > > recover the original serial port configuration, including
> > > > CLOCAL, so
> > > > MM was actually getting the HUP in the TTY right away as
> > > > carrier
> > > > detect was enabled (CLOCAL unset). The fix was to update NM so
> > > > that it
> > > > reports the disconnection to MM only after the DEAD state was
> > > > reported
> > > > by pppd.
> > > > 
> > > > So, following what the CLOCAL setting is in the different steps
> > > > should
> > > > definitely help I think.
> > > 
> > > Tracing in the driver, I can see the TCSETFS ioctl being called
> > > at the 'pon' and at the 'poff'. Presumably this *is* from pppd -
> > > nothing else is using the port except MM.
> > > The respective c_cflag values in the args seem to be
> > >  pon 020000012267
> > >  poff 016261
> > > So, yes, it appears that CLOCAL [04000] is being set? (and
> > > CRTSCTS cleared)
> > 
> > Using 'local' instead of 'modem' in the ppp settings:
> > pon 20000014267
> > poff 016261
> > i.e. CLOCAL *staying* set, and setting HUPCL?
> > 
> 
> Still trying to get to the bottom of this problem. 
> What are the events which can cause the G_IO_HUP (in MM)?

G_IO_HUP == POLLHUP from the standard C library (see
/usr/include/bits/poll.h).  It's coming directly from the kernel fd for
the serial port, which in turn comes directly from the driver and the
TTY subsystem.  See drivers/tty/n_tty.c which is the default serial
line discipline on Linux (IIRC).

The places n_tty sets POLLHUP are both in n_tty_poll():

	if (test_bit(TTY_OTHER_CLOSED, &tty->flags))
		mask |= POLLHUP;
** this one doesn't apply, since it's only set by drivers/tty/pty.c and
we don't use pseudo-ttys for modem stuff.

	if (tty_hung_up_p(file))
		mask |= POLLHUP;

tty_hung_up_p() will only return true if __tty_hangup() has been
called, which can happen from:

1) tty_vhangup(): called on USB device disconnect, UART port removal
(called from a lot of UART drivers, maybe yours?), from TIOCVHANGUP,
and a couple other places.  Could be the culprit.

2) tty_hangup(): called from uart_handle_dcd_change() (which shouldn't
affect anything that sets CLOCAL, but who knows...), and
tty_port_tty_hangup().  This last one is called mostly from serial
drivers when the DCD has changed.

Check your mux driver, does it do any calls to tty_port_tty_hangup() or
 tty_hangup()?

Dan

> I only plan to use the driver with MM/NM/ppp, so I *could* make mods
> if necessary, but I'm not even sure it's the driver that needs
> alteration. Or, at least, that that's the best place.
> I also came across this old thread - https://mail.gnome.org/archives/
> networkmanager-list/2010-March/msg00140.html - dunno if it's relevant
> to my problem.
> _______________________________________________
> ModemManager-devel mailing list
> ModemManager-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel