From owner-freebsd-questions Thu Sep 30 0:53:14 1999 Delivered-To: freebsd-questions@freebsd.org Received: from alpha.netvision.net.il (alpha.netvision.net.il [194.90.1.13]) by hub.freebsd.org (Postfix) with ESMTP id 2A69215148; Thu, 30 Sep 1999 00:53:01 -0700 (PDT) (envelope-from danhil@cwnt.com) Received: from unspecified.host (RAS4-p71.hfa.netvision.net.il [62.0.146.199]) by alpha.netvision.net.il (8.9.3/8.8.6) with SMTP id JAA13568; Thu, 30 Sep 1999 09:52:43 +0200 (IST) Received: from 192.168.0.46 ([192.168.0.46]) by 192.168.0.1 (WinRoute 3.04g) with SMTP; Thu, 30 Sep 1999 09:50:50 +0200 Message-ID: <049401bf0b20$e3621c20$2e00a8c0@nt46daniel> From: "Daniel Hilevich" To: "John Hay" Cc: , References: <199909291925.VAA65012@zibbi.mikom.csir.co.za> Subject: Re: A bug in the sppp driver? Date: Thu, 30 Sep 1999 09:50:47 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Are you busy with a leased line driver or a dialup/isdn kind of driver? > I have been busy fixing sppp to work properly with leased line drivers > again, but am not finished with it yet. :-/ Hopefully I won't break > the isdn handling at the same time. > I'm writing this pseudo driver with lots of interfaces. Each interface can be configured to work with a variety of protocols. Currently I'm working on the connection to the PPP protocol. > > While trying to use the sppp, I came across this situation and I think it's > > a bug: > > When you trying to establish connection from one peer (local) to another > > (remote), you sent a CONF_REQ message to the remote peer. The remote peer > > should answer with a CONF_ACK message. In the code of the sppp driver > > (net/if_spppsubr.c, lines 1321 - 1357) you can see that the remote peer > > send's a CONF_ACK message to the local peer > > (in the line: rv = (cp->RCR)(sp, h, len);) but doesn't change it state to > > STATE_ACK_SENT (as I think it should do) . Further more, you can see that > > after a few lines, there are these strange lines: > > case STATE_ACK_SENT: > > case STATE_REQ_SENT: > > sppp_cp_change_state(cp, sp, rv? > > STATE_ACK_SENT: STATE_REQ_SENT); > > break; > > My patch for this part looks like this, carefull I have just cut and > paste it, so the tabs got lost: > > --------- > @@ -1298,6 +1299,16 @@ > /* fall through... */ > case STATE_ACK_SENT: > case STATE_REQ_SENT: > + /* > + * sppp_cp_change_state() have the side effect of > + * restarting the timeouts. We want to avoid that > + * if the state don't change, otherwise we won't > + * ever timeout and resend a configuration request > + * that got lost. > + */ > + if (sp->state[cp->protoidx] == (rv ? STATE_ACK_SENT: > + STATE_REQ_SENT)) > + break; > sppp_cp_change_state(cp, sp, rv? > STATE_ACK_SENT: STATE_REQ_SENT); > break; > -------- My problem is that when you get the first CONF_REQ message, the driver's state is INITIAL. The call to the RCR function return with the value 1 but, no one changes the state to STATE_ACK_SENT. I think the fix should be like this (line 1274): .... rv = (cp->RCR)(sp, h, len); /* Daniel - fix */ if (rv && sp->state[cp->protoidx] == STATE_INITIAL) sppp_cp_change_state(cp, sp, STATE_ACK_SENT); sp->rst_counter[cp->protoidx] = sp->lcp.max_configure; /* End of fix */ switch (sp->state[cp->protoidx]) { case STATE_OPENED: ... Thanks for the help Daniel To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message