'port forced close' after failed ppp

[Colin Helliwell]

> On 10 March 2017 at 16:54 Aleksander Morgado <aleksander at aleksander.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)