> > 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 paulkf@microgate.com
Microgate Corporation www.microgate.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed May 23 2001 - 21:00:47 EST