Re: Problem with Simple.Connect



On Wed, 2009-10-14 at 14:16 +0200, Pablo Martí Gamboa wrote:
> 
> 
> 2009/10/14 Pablo Martí Gamboa <pmarti warp es>
>         
>         
>         2009/10/13 Dan Williams <dcbw redhat com>
>                 
>                 On Fri, 2009-10-09 at 10:00 +0200, Pablo Martí Gamboa
>                 wrote:
>                 >
>                 >
>                 
>                 > The puzzling thing is that the very first time it
>                 will connect no
>                 > problem, it is the second and third attempts that
>                 fail. Nothing in the
>                 > wader log indicates that there's been a problem (the
>                 log trace of a
>                 > successful and unsuccessful attempts are exactly
>                 similar). So perhaps
>                 > there is a problem with that ppp timeout?
>                 >
>                 >
>                 > Is not like Simple.Connect is complicated right, it
>                 is basically the
>                 > old connect beefed up. And the old connect
>                 reliability was way better
>                 > (i.e. several connection attempts in a row no
>                 problem)
>                 >
>                 >
>                 > Is there anything else I can do to help you figure
>                 out this one?
>                 
>                 
>                 I'd hazard a guess that we're not disconnecting or
>                 hanging up the
>                 previous connection correctly somewhere.  Disable
>                 implies disconnect of
>                 course, so any Enable(False) handler should also be
>                 ensuring clean
>                 disconnection.
>                 
>                 Can you run NM with:
>                 
>                 NM_PPP_DEBUG=1 /usr/sbin/NetworkManager --no-daemon
>                 
>                 
>                 and lets see what comes out?  That will provide the
>                 PPP spew which could
>                 help us get closer.
>                 
>         
>         
>         Attached you can find success1.log and error2.log, the first
>         attempt succeed and the second failed.
>         
>         
>         I've tried with:
>          * plain '+++ATH\r'
>          * lower & raise DTR
>          * lower & raise DTR + 'ATH\r'
> 
> 
> Turns out that ModemManager actually uses a fourth one:
>   * Set baudrate temporally to 0 and restore speed in some
> milliseconds

Yeah, though depending on the modem and driver that might actually not
work, and I"ve had reports of it not working on some devices, hence my
interest.  I think maybe the combination of DTR + ATH and "flash"-ing
the modem would give us the best coverage, since +++ in the PPP data
stream is just too fragile.

Have you found any combination that apparently just works everywhere?
(hopeful, I know...)

Dan

> 
> I tried this attempt with the same results (see attached files)
> 
> 
> 
> 
>  
>         
>         
>         And the outcome was the same
>         
>         
>         Regards,
>         
>         
>         
>         -- 
>         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')"
> 



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]