Re: Problem with Simple.Connect

[Dan Williams <dcbw redhat com>]

On Fri, 2009-10-09 at 10:03 +0200, Pablo Martí Gamboa wrote:
> 
> 
> 2009/10/9 Dan Williams <dcbw redhat com>
>         
>         On Thu, 2009-10-08 at 10:33 +0200, Pablo Martí Gamboa wrote:
>         >
>         >
>         > 2009/10/8 Pablo Martí Gamboa <pmarti warp es>
>         >
>         >
>         >         2009/10/7 Dan Williams <dcbw redhat com>
>         >
>         >                 On Tue, 2009-10-06 at 12:43 +0200, Pablo
>         Martí Gamboa
>         >                 wrote:
>         >                 > Hi all,
>         >                 >
>         >                 > I'm getting a unreliable behavior with
>         >                 Simple.Connect, the first call
>         >                 > will succeed, but further calls won't.
>         >                 >
>         >                 >
>         >                 > Going through the logs with Tambet, we
>         have noticed
>         >                 that there is
>         >                 > something weird going on with IPv6 code:
>         >
>         >
>         >                 I think that's mostly unrelated; NM will not
>         finish
>         >                 the connection until
>         >                 both IP4 and IP6 have completed, but of
>         course in your
>         >                 case you don't
>         >                 have IP6 configured since this is a mobile
>         broadband
>         >                 connection, so that
>         >                 stage is just a null-op.  The real problem
>         seems to
>         >                 be:
>         >
>         >                 Oct  6 10:27:04 lenovo NetworkManager:
>         <WARN>
>         >                  pppd_timed_out(): Looks
>         >                 like pppd didn't initialize our dbus module
>         >
>         >
>         >                 which indicates that PPP did not
>         successfully
>         >                 complete, or that the NM
>         >                 pppd plugin could not push the IP4 config
>         information
>         >                 back to
>         >                 NetworkManager.  Can you run NM like so:
>         >
>         >                 NM_PPP_DEBUG=1 /usr/sbin/NetworkManager
>         --no-daemon
>         >
>         >         see successful.log and error.log (first and second
>         attempts
>         >         respectively)
>         >
>         >
>         >
>         >                 and then reproduce the issue?  That should
>         show a lot
>         >                 more log output
>         >                 (including pppd's stdout debugging info)
>         that will
>         >                 allow us to figure
>         >                 out what's going on here.
>         >
>         >                 Also, did this just start happening, or has
>         this been
>         >                 around for a bit?
>         >                 Or did you just install something new?
>         >
>         >         I forgot to mention that this with NetworkManager +
>         Wader
>         >         rather than NM + MM. I'm testing the integration of
>         both
>         >         packages before (hopefully) the release of Ubuntu
>         9.10 final.
>         >         I hadn't tested Simple.Connect in a while.
>         >
>         >
>         > I forgot to mention that when I press "Disconnect" from
>         nm-applet,
>         > that just issues an "Enable(false)" to the device rather
>         than
>         > "Disconnect(); Enable(false);", I asked yesterday in #nm and
>         nobody
>         > seemed to recall why that decision had been made, they just
>         remembered
>         > that it was more reliable for a particular device. In my
>         case it is
>         > the other way around! will nm0.8 ship like this?
>         
>         
>         Right now NM doesn't call disconnect at all, AFAIK.  It just
>         calls
>         Enable(false).  We assume that also cleans up the connection
>         and
>         disables the modem, since disabling the modem implies the
>         connection is
>         torn down.  Is that not working?
> 
> 
> That has caused some unreliability problems with HSO devices for us.
> I've added a small guard that before disabling a device will
> disconnect it if its connected and will carry on disabling it. This
> has improved the reliability and can connect with hso devices several
> times in a row.
> 
> 
>         
>         BTW, how do you handle breaking into the ongoing PPP session
>         on a 1-port
>         modem and hanging up the connection?   +++ATH?  Or AT &D1,
>         setting the
>         serial port's DTR to off and then ATH?
> 
> 
> We were using the DTR approach (without ATH), and that was working
> nicely for us (NM 0.7.1), then when we switched to NM 0.8 and faced
> all this Simple.Connect problems I tried switching to +++ATH, but it
> hasn't improved anything...

But with DTR and without ATH, isn't the connection still active?  It
thought DTR transitions just broke into command mode so you *could* run
ATH.  I didn't think they terminated an active data connection too...

Dan