diff options
| author | jlemon <jlemon@FreeBSD.org> | 1999-12-11 04:05:52 +0000 |
|---|---|---|
| committer | jlemon <jlemon@FreeBSD.org> | 1999-12-11 04:05:52 +0000 |
| commit | 4e4e4d62e2835b733d4f63b5bc99ef3df6dfba04 (patch) | |
| tree | 2459e491d4e78ac7b8ee09b5e5412cd2af33078f | |
| parent | 17b5e08d07bb47bdd9b1a226585ee18c50da2a83 (diff) | |
| download | FreeBSD-src-4e4e4d62e2835b733d4f63b5bc99ef3df6dfba04.zip FreeBSD-src-4e4e4d62e2835b733d4f63b5bc99ef3df6dfba04.tar.gz | |
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
| -rw-r--r-- | sys/netinet/tcp_input.c | 13 | ||||
| -rw-r--r-- | 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 909adf9..d3b5461 100644 --- a/sys/netinet/tcp_input.c +++ b/sys/netinet/tcp_input.c @@ -1092,12 +1092,10 @@ trimthenstep6: * 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 @@ trimthenstep6: * 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 909adf9..d3b5461 100644 --- a/sys/netinet/tcp_reass.c +++ b/sys/netinet/tcp_reass.c @@ -1092,12 +1092,10 @@ trimthenstep6: * 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 @@ trimthenstep6: * 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: |
