Date: Wed, 29 Sep 1999 12:10:00 -0500 (CDT) From: Mark Tinguely <tinguely@plains.NoDak.edu> To: danhil@cwnt.com, freebsd-hackers@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: A bug in the sppp driver? Message-ID: <199909291710.MAA20873@plains.NoDak.edu>
next in thread | raw e-mail | index | archive | help
> 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 majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199909291710.MAA20873>