Re: Problem with Simple.Connect

[Dan Williams <dcbw redhat com>]

On Thu, 2009-10-29 at 15:01 +0100, Pablo Martí Gamboa wrote:
> 
> 
> 2009/10/26 Dan Williams <dcbw redhat com>
>         
>         On Mon, 2009-10-26 at 13:36 +0100, Pablo Martí Gamboa wrote:
>         
>         
>         > Also I'm having reliability problems with PPP devices and
>         > Simple.Connect, first attempt will work (most of the time)
>         but the
>         > second will never.
>         
>         
>         That may be because the data session is not properly torn down
>         by either
>         Disconnect or Enable(false).  Not sure though, I have seen
>         this at
>         various times too and haven't been able to pin it down.
>          Usually some
>         combination of init strings end up fixing this.
> 
> 
> It seems other users are having pppd_timeout() problems too:
> 
> 
> https://bugs.edge.launchpad.net/ubuntu/+source/network-manager/+bug/393094
> https://bugs.edge.launchpad.net/ubuntu/+source/network-manager/+bug/407519
> https://bugs.edge.launchpad.net/ubuntu/+source/network-manager/+bug/432205
> 
> 
> Is it possible they are related?

I spent some time last week implementing and testing the DTR switch and
doing "ATH" after doing so.  I'm still working through that this week,
among other things.

For most modems, terminating PPP will make the modem return to command
mode and reply with NO CARRIER.  But I believe there are some modems
that will not necessarily do so.

Also, some drivers simply don't implement DTR ioctls at all (qcserial
for example).  This is a driver bug, but it means everyone needs
multiple methods to break out of data mode and into command mode.  These
methods are roughly:

1) terminate PPP
2) if the modem has a secondary port or can MUX, tear the connection
down from the secondary port by deactivating the PDP context or with ATH
or AT_OWANCALL or AT*ENAP=0 or whatever
3) if the modem only has one port, try toggling the DTR and doing ATH or
deactivating the PDP context
4) if that fails, there's not much else you can do except rfkill the
device

I'm pretty concerned about mobile phones actually.  Most of the data
cards are sane, and most of them present more than one serial port.  But
phones usually only present one (especially in the case of Bluetooth
DUN) and often that port cannot be muxed with GSM 27.010.  Thus, if the
modem or driver does not correctly implement DTR, or the device doesn't
implement DTR, terminating the connection won't work at all.  The PPP
escape +++ sequence is quite failure-prone in my experience and not all
devices care about it.

Dan