RE: Problem with Simple.Connect

["Herriot, Nicholas, VF-Group" <Nicholas Herriot vodafone com>]

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:pmarti warp es]
Sent: 26 October 2009 12:36
To: Dan Williams
Cc: networkmanager-list gnome org; Tambet Ingo; Herriot, Nicholas, VF-Group
Subject: Re: Problem with Simple.Connect

2009/10/26 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:
>
>

> 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')"