Re: Problem with Simple.Connect

[Dan Williams <dcbw redhat com>]

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.

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.

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