2009/10/26 Dan Williams <[email protected]>

> On Mon, 2009-10-26 at 13:36 +0100, Pablo Martí Gamboa wrote:
> >
> >
> > 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.
>
> Yes, this should be fixed in NetworkManager.
>
> >
> > 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
>
> This is sub-optimal behavior in NetworkManager, and it should be fixed
> 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.
>
> >     * 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
>
> This is most likely the same problem as above; and the fix should be the
> same as the problem above.
>
> >     * When I press "Disconnect" from nm-applet, it won't send a
> > "Disconnect", it sends Enable(0) twice again. workaround #3
>
> This is a second problem, and should be fixed in NetworkManager.
>
> >     * 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
>
> Fair enough; if we relied on that behavior explicitly, it should have
> been included in the specification documentation originally.
>
> > 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.
>
> That may be because the data session is not properly torn down by either
> 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.


Thanks for acknowledging this issues Dan. Looking forward to the fixes :)

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

Reply via email to