As I understand from rfc1661, the state, which the remote machine should be
after sending a CONF_ACK message, is ack_send. The sppp driver doesn't work
properly and I think that this is on of the reasons.
----- Original Message -----
From: Dennis <[EMAIL PROTECTED]>
To: Daniel Hilevich <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Wednesday, September 29, 1999 3:05 PM
Subject: Re: A bug in the sppp driver?
> At 04:51 PM 9/29/99 +0100, Daniel Hilevich wrote:
> >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;
> >
> >Question: if you are in the STATE_ACK_SENT why change the state to the
same
> >one according to the value of rv?
> >
> >As I understand, the state should be changed according to the value of
rv,
> >but it should be done right after the call to cp->RCR. The it is
implemented
> >now, the state won't be changed.
>
> the state is dependent on what state you are in, given the event. Have you
> verified that you are in ack_sent?
>
> doing state machines with switch statements is a big mess.
>
> Dennis
>
>
>
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
