On Fri, 2009-10-09 at 10:03 +0200, Pablo Martí Gamboa wrote: > > > 2009/10/9 Dan Williams <[email protected]> > > On Thu, 2009-10-08 at 10:33 +0200, Pablo Martí Gamboa wrote: > > > > > > 2009/10/8 Pablo Martí Gamboa <[email protected]> > > > > > > 2009/10/7 Dan Williams <[email protected]> > > > > 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 _______________________________________________ NetworkManager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
