lkml.org 
[lkml]   [2001]   [May]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: SyncPPP IPCP/LCP loop problem and patch
Date
> > 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/

\
 
 \ /
  Last update: 2005-03-22 12:53    [W:0.064 / U:0.688 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site