[lkml]   [2001]   [May]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Patch in this message
SubjectSyncPPP IPCP/LCP loop problem and patch. Take 2
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) {
@@ -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;

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
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

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