Paul Fulghum wrote:
> >
> > Thanks but I've already tried that. You get a slightly different pattern
> > to the loop but it still loops.
>
> What does the loop look like when the cfg-req is sent 1st?
Thanks for making me go back and look at it again guys. The reordering of
REQ and ACK does work to break the loop. Provided you apply the patch to
both ends of the link.
This is a much smaller patch, remains RFC1661 conformant and works against
all the platforms I've been able to test. Against an unpatched Linux it
still loops but no worse than before.
--- syncppp.c-orig Mon May 21 10:35:59 2001
+++ syncppp.c Thu May 24 15:55:55 2001
@@ -517,8 +517,10 @@
}
/* Send Configure-Ack packet. */
sp->pp_loopcnt = 0;
- sppp_cp_send (sp, PPP_LCP, LCP_CONF_ACK,
- h->ident, len-4, h+1);
+ if (sp->lcp.state != LCP_STATE_OPENED) {
+ sppp_cp_send (sp, PPP_LCP, LCP_CONF_ACK,
+ h->ident, len-4, h+1);
+ }
/* Change the state. */
switch (sp->lcp.state) {
case LCP_STATE_CLOSED:
@@ -534,7 +536,9 @@
sp->ipcp.state = IPCP_STATE_CLOSED;
/* Initiate renegotiation. */
sppp_lcp_open (sp);
- /* An ACK has already been sent. */
+ /* Send ACK after our REQ in attempt to break loop */
+ sppp_cp_send (sp, PPP_LCP, LCP_CONF_ACK,
+ h->ident, len-4, h+1);
sp->lcp.state = LCP_STATE_ACK_SENT;
break;
}
A colleage has suggested that we should apply the same ordering in the NAK
path and for similar code in the stopped state. Since I've not seen loops in
these areas I'm loath to make changes without the ability to test.
--
Bob Dunlop FarSite Communications
rjd@xyzzy.clara.co.uk bob.dunlop@farsite.co.uk
www.xyzzy.clara.co.uk www.farsite.co.uk
-
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 : Thu May 31 2001 - 21:00:17 EST