From 1a244a616dc22980d6f2696cc9ca61c1ec5cf8cf Mon Sep 17 00:00:00 2001 From: Jonathan Lemon Date: Sat, 11 Dec 1999 04:05:52 +0000 Subject: [PATCH] According to RFC 793, a reset should be honored if the sequence number is within the receive window. Follow this behavior, instead of only allowing resets at last_ack_sent. Pointed out by: jayanth@yahoo-inc.com --- sys/netinet/tcp_input.c | 13 ++++++------- sys/netinet/tcp_reass.c | 13 ++++++------- 2 files changed, 12 insertions(+), 14 deletions(-) diff --git a/sys/netinet/tcp_input.c b/sys/netinet/tcp_input.c index 909adf998ede..d3b5461c7053 100644 --- a/sys/netinet/tcp_input.c +++ b/sys/netinet/tcp_input.c @@ -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: diff --git a/sys/netinet/tcp_reass.c b/sys/netinet/tcp_reass.c index 909adf998ede..d3b5461c7053 100644 --- a/sys/netinet/tcp_reass.c +++ b/sys/netinet/tcp_reass.c @@ -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: