Yes, this should be fixed in NetworkManager.On Mon, 2009-10-26 at 13:36 +0100, Pablo Martí Gamboa wrote:
>
>
> 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.
This is sub-optimal behavior in NetworkManager, and it should be fixed
>
> 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
in NetworkManager before NM 0.8. NM should not be sending this when the
device is recognized. The problem code is in
nm-modem.c::device_state_changed(), and should be changed to take the
"old_state" into account.
This is most likely the same problem as above; and the fix should be the
> * 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
same as the problem above.
This is a second problem, and should be fixed in NetworkManager.
> * When I press "Disconnect" from nm-applet, it won't send a
> "Disconnect", it sends Enable(0) twice again. workaround #3
Fair enough; if we relied on that behavior explicitly, it should have
> * 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
been included in the specification documentation originally.
That may be because the data session is not properly torn down by either
> 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.
Disconnect or Enable(false). Not sure though, I have seen this at
various times too and haven't been able to pin it down. Usually some
combination of init strings end up fixing this.