Re: SyncPPP IPCP/LCP loop problem and patch

[Paul Fulghum]

> > Seems to me that when you get the conf-request in opened state, you
> > should send your conf-request before sending the conf-ack to the
> > peer's conf-request.  I think this would short-circuit the loop (I
> > could be wrong though, it's getting late).
> 
> Thanks but I've already tried that. You get a slightly different pattern
> to the loop but it still loops.

I'm just wondering if the loop that results when
the cfg-req is sent 1st might be a results of 
syncppp not processing a cfg-ack properly when
in the opened state.

RFC1661 state table shows a transition to req-sent
from opened when a (properly formated with 
correct sequence ID) cfg-ack is received.

Syncppp does not do this (from sppp_lcp_input):

 case LCP_CONF_ACK:
  if (h->ident != sp->lcp.confid)
   break;
  sppp_clear_timeout (sp);
  if ((sp->pp_link_state != SPPP_LINK_UP) &&
      (dev->flags & IFF_UP)) {
   /* Coming out of loopback mode. */
   sp->pp_link_state=SPPP_LINK_UP;
   printk (KERN_INFO "%s: protocol up\n", dev->name);
  }
  switch (sp->lcp.state) {
  case LCP_STATE_CLOSED:
   sp->lcp.state = LCP_STATE_ACK_RCVD;
   sppp_set_timeout (sp, 5);
   break;
  case LCP_STATE_ACK_SENT:
   sp->lcp.state = LCP_STATE_OPENED;
   sppp_ipcp_open (sp);
   break;
  }
  break;

Maybe adding:

  case LCP_STATE_OPENED:
   sppp_lcp_open (sp);
   sp->ipcp.state = IPCP_STATE_CLOSED;
   sp->lcp.state = LCP_STATE_REQ_SENT;
   break;

to the above switch statement in addition to
the cfg-req 1st change would cure both loops.

Paul Fulghum [e-mail]
Microgate Corporation www.microgate.com