system/freebsd-src
system/freebsd-src
1
0
Fork 0
mirror of https://github.com/freebsd/freebsd-src synced 2024-09-21 01:03:42 +00:00
Code Issues Packages Projects Releases Wiki Activity

According to RFC 793, a reset should be honored if the sequence number

Browse source 
is within the receive window.  Follow this behavior, instead of only
allowing resets at last_ack_sent.

Pointed out by:	jayanth@yahoo-inc.com
This commit is contained in:
Jonathan Lemon 1999-12-11 04:05:52 +00:00
parent f1b5e7b750
commit 1a244a616d
Notes: svn2git 2020-12-20 02:59:44 +00:00 
svn path=/head/; revision=54421
2 changed files with 12 additions and 14 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

13
sys/netinet/tcp_input.c
View file

@ -1092,12 +1092,10 @@ tcp_input(m, iphlen)
* valid if its sequence number is in the window.
* Note: this does not take into account delayed ACKs, so
* we should test against last_ack_sent instead of rcv_nxt.
* Also, it does not make sense to allow reset segments with
* sequence numbers greater than last_ack_sent to be processed
* since these sequence numbers are just the acknowledgement
* numbers in our outgoing packets being echoed back at us,
* and these acknowledgement numbers are monotonically
* increasing.
* The sequence number in the reset segment is normally an
* echo of our outgoing acknowlegement numbers, but some hosts
* send a reset with the sequence number at the rightmost edge
* of our receive window, and we have to handle this case.
* If we have multiple segments in flight, the intial reset
* segment sequence numbers will be to the left of last_ack_sent,
* but they will eventually catch up.
@ -1127,7 +1125,8 @@ tcp_input(m, iphlen)
* RFC 1337.
*/
if (tiflags & TH_RST) {
if (tp->last_ack_sent == ti->ti_seq) {
if (ti->ti_seq >= tp->last_ack_sent &&
ti->ti_seq < tp->last_ack_sent + tp->rcv_wnd) {
switch (tp->t_state) {
case TCPS_SYN_RECEIVED:

13
sys/netinet/tcp_reass.c
View file

@ -1092,12 +1092,10 @@ tcp_input(m, iphlen)
* valid if its sequence number is in the window.
* Note: this does not take into account delayed ACKs, so
* we should test against last_ack_sent instead of rcv_nxt.
* Also, it does not make sense to allow reset segments with
* sequence numbers greater than last_ack_sent to be processed
* since these sequence numbers are just the acknowledgement
* numbers in our outgoing packets being echoed back at us,
* and these acknowledgement numbers are monotonically
* increasing.
* The sequence number in the reset segment is normally an
* echo of our outgoing acknowlegement numbers, but some hosts
* send a reset with the sequence number at the rightmost edge
* of our receive window, and we have to handle this case.
* If we have multiple segments in flight, the intial reset
* segment sequence numbers will be to the left of last_ack_sent,
* but they will eventually catch up.
@ -1127,7 +1125,8 @@ tcp_input(m, iphlen)
* RFC 1337.
*/
if (tiflags & TH_RST) {
if (tp->last_ack_sent == ti->ti_seq) {
if (ti->ti_seq >= tp->last_ack_sent &&
ti->ti_seq < tp->last_ack_sent + tp->rcv_wnd) {
switch (tp->t_state) {
case TCPS_SYN_RECEIVED: