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

Pablo+

This was an unfortunate change and should be reverted as soon as possible

 

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