Dan, If we could get some betavine developers to work on this, would you accept fixes from us (Vodafone) into NM to get the issues addressed highlighted by Pablo? Or should we wait for your team to help with this area? We are just a bit concerned as we have demonstrations to give in the coming weeks of our integration work with Wader. Kind regards, Nicholas Herriot.
________________________________ From: Pablo Martí Gamboa [mailto:[email protected]] Sent: 26 October 2009 12:36 To: Dan Williams Cc: [email protected]; Tambet Ingo; Herriot, Nicholas, VF-Group Subject: Re: Problem with Simple.Connect 2009/10/26 Pablo Martí Gamboa <[email protected]> 2009/10/9 Dan Williams <[email protected]> On Thu, 2009-10-08 at 10:33 +0200, Pablo Martí Gamboa wrote: > > > 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? For projects like NM this behaviour is acceptable, between every connection attempt you don't do any operations with the 3G device. However for projects like Wader, this is an unfortunate change. Now when we issue a DeactivateConnection, we get an "Enable(false)" sent to our device, deactivating the radio and leaving the device unusable for some operations. Why don't we stick to the original vocabulary? Enable(true); Connect(settings); Disconnect(); Enable(false); Right now the harm is already done, and we are going to have to ship with a workaround for this behaviour (unless somehow the patch makes it into the distros before 0.8, which for Ubuntu is already too late). Please please, go back to the old behaviour. I finally gave up and disabled NM compatibility, the reason is that NM does not respect current ModemManager vocabulary and adding so many workarounds is polluting my code: * When a device is announce via DeviceAdded, NM sends right away two "Enable(0)" (should be boolean). workaround #1 * When a Simple.Connect call is issued, NM sends right away two "Enable(0)" (I assume that to make sure we are not connected) thus breaking my internal state, workaround #2 * When I press "Disconnect" from nm-applet, it won't send a "Disconnect", it sends Enable(0) twice again. workaround #3 * When a Simple.Connect call is issued, NM does not bother to Enable(true) the device, it assumes that the internal simple state machine will do it for us. Not working around it :S 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. Bear in mind that I am not dissing anyone's work here, this is just a summary of some of the problems that an alternate ModemManager implementor faces if she strives for total compatibility. Hopefully in the future I'll be able to re-enable the compatibility... Best regards, Pablo 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? Dan -- Pablo Martí http://www.linkedin.com/in/pmarti || http://www.warp.es python -c "print '706d6172746940776172702e6573'.decode('hex')" -- Pablo Martí http://www.linkedin.com/in/pmarti || http://www.warp.es python -c "print '706d6172746940776172702e6573'.decode('hex')"
_______________________________________________ NetworkManager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
