'port forced close' after failed ppp

[Colin Helliwell]

> On 09 March 2017 at 17:42 Dan Williams <dcbw at redhat.com> wrote:
> 
> On Thu, 2017-03-09 at 09:19 +0000, Colin Helliwell wrote:
> 
> > > On 08 March 2017 at 14:38 Aleksander Morgado <aleksander at aleksander .es> wrote:
> > > 
> > > On Wed, Mar 8, 2017 at 3:08 PM, Colin Helliwell
> > > 
> > > <colin.helliwell at ln-systems.com> wrote:
> > > 
> > > > But this brings me back (in a round-the-houses way!) to my
> > > > original question: when the PPP fails, for example with the ports
> > > > assigned the right way round, but on 'faulty' SIM1, why is the
> > > > PPP port getting "forced closed" and then unable to be retried?
> > > > My concern being if PPP fails for an external reason e.g. at the
> > > > remote end, then it can't retry?
> > > 
> > > Forgive my bad memory here. I think the HUP that triggers the
> > > "forced
> > > close" in the TTY shouldn't be received by ModemManager, it should
> > > be
> > > processed by pppd, which is the one that handles that
> > > disconnection.
> > > pppd resets all modem control lines on exit, IIRC. I recall a
> > > similar
> > > problem when playing with the NetworkManager integration, which is
> > > the
> > > one that would call pppd to establish the connection; I think I
> > > solved
> > > it just by making sure pppd is completely closed before
> > > Disconnect()
> > > is called for the modem in ModemManager (i.e. so that pppd could
> > > recover the original state of the control lines before passing the
> > > control of the TTY to MM through the Disconnect() call). Does that
> > > make any sense at all?
> > 
> > Ermmm, some...!
> > However I've found that the same thing is happening even when the PPP
> > is successful - MM is getting the "unexpected port hangup!" when I
> > close PPP. I'm doing:
> >  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?)