Re: Problem with Simple.Connect

[Pablo Martí Gamboa <pmarti warp es>]

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...

-- 
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c "print '706d6172746940776172702e6573'.decode('hex')"