Subject: Re: (ML)PPP State Machine Issues

From: Henrik Kristensen <[email-masked]>
Date: Thu, 24 Feb 2000 17:16:52 -0800 (PST)

Thanks for the sugegstion. Increasing timeout value didn't help in 
this case (and latency was low; I was only running a few feet of 
fiber in a lab).

(What happened was that one end restarted without the other end
 noticing, which can happen if there are switches or cross-connects 
 in the telecom path and, one end doesn't get the chance to send 
 TERM_ACK before it is disconnected. 
 This causes the "innocent end" to jump back from OPENED to REQSENT 
 or ACKSENT when it gets the CONF_REQ and in this situation there's
 a chance the two ends will end up cycling between OPENED and 
 REQSENT/ACKSENT.)

Thanks,
--Henrik

> From [email-masked] Thu Feb 24 16:57 PST 2000
> Delivered-To: [email-masked]
> From: Archie Cobbs <[email-masked]>
> Subject: Re: (ML)PPP State Machine Issues
> To: [email-masked] (Henrik Kristensen)
> Date: Thu, 24 Feb 2000 16:56:53 -0800 (PST)
> Cc: [email-masked]
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> 
> Henrik Kristensen writes:
> > Please forgive me if I'm missing what ought to be "common 
> > knowledge":
> > 
> > I've seen problems with (ML)PPP LCP/NCP negotiation sequences 
> > that didn't converge even when the two ends agreed on all 
> > options.
> 
> In my experience this is usually because the link latency is
> too high compared to the retransmit delay... does increasing
> the retransmit time not solve your problem?
> 
> -Archie
> 
> ___________________________________________________________________________
> Archie Cobbs   *   Whistle Communications, Inc.  *   http://www.whistle.com
> 
>

---

From: Archie Cobbs <[email-masked]>
Date: Thu, 24 Feb 2000 17:30:35 -0800 (PST)

>  a chance the two ends will end up cycling between OPENED and 

Hmm... do you have a log trace of this? I still don't see how
that would happen (though I believe you that it does)..

-Archie