Date: Thu, 30 Sep 1999 09:50:47 +0100 From: "Daniel Hilevich" <danhil@cwnt.com> To: "John Hay" <jhay@mikom.csir.co.za> Cc: <freebsd-hackers@FreeBSD.ORG>, <freebsd-questions@FreeBSD.ORG> Subject: Re: A bug in the sppp driver? Message-ID: <049401bf0b20$e3621c20$2e00a8c0@nt46daniel> References: <199909291925.VAA65012@zibbi.mikom.csir.co.za>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?049401bf0b20$e3621c20$2e00a8c0>