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
