> 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 you sent the configuration request, you are in state REQ_SENT.
the Receive Config Ack will cause you to state ACK_SENT on line 1327.
> Question: if you are in the STATE_ACK_SENT why change the state to the same
> one according to the value of rv?
STATE_ACK_SENT is the state before we recieved this configuration packet.
the sppp_lcp_RCR will send a REJ, NAK, or ACK, and reflect the packet sent
in the return value rv. RFC 1661 page 12 states what state to go into
ACK_SENT (for RCR+) or REQ_SENT (for RCR-). this make sense we can recieve
a RCR while still ACK the last RCR. And in the other case, if we reject
a parameter in the RCR, we expect them to either remove the objectional
item or give us a value that we can use (hense the REQ_SENT).
> 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.
I requested that a minor state change be made on the FreeBSD-3.2 version
(and from a diff of the two drivers, it appears it has been corrected,
but I haven't studied the 3.3-RELEASE version that closely and the change
was a very minor state that should not happen very often). Besides the
above mentioned state, I thought sppp floowed RFC 1661 very well.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
