Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 13 Dec 1999 09:55:17 -0800
From:      Don Lewis <Don.Lewis@tsc.tdk.com>
To:        venkat venkatsubra <venkats@austin.ibm.com>, jayanth <jayanth@yahoo-inc.com>
Cc:        freebsd-net@FreeBSD.ORG
Subject:   Re: peculiar tcp behavior
Message-ID:  <199912131755.JAA19500@salsa.gv.tsc.tdk.com>
In-Reply-To: venkat venkatsubra <venkats@austin.ibm.com> "Re: peculiar tcp behavior" (Nov 24,  9:42am)

next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 24,  9:42am, venkat venkatsubra wrote:
} Subject: Re: peculiar tcp behavior
} This is a multi-part message in MIME format.
} --------------83BAB6521073EDFB9822F331
} Content-Type: text/plain; charset=us-ascii
} Content-Transfer-Encoding: 7bit
} 
} jayanth wrote:
} 
} > hi,
} > I have a tcpdump below.  If a Reset segment is received that is greater
} > than "last_ack_sent" the FreeBSD 2.2.8 tcpip stack does not process the
} > segment and drop the connection.  Is the sender(a.b.c.d) of the Reset
} > wrong in
} > sending a Reset that is within the window but greater than our
} > "last_ack_sent "?

Yes.  The last paragraph on page 36 of RFC 793 says:

    If the incoming segment has an ACK field, the reset takes its
    sequence number from the ACK field of the segment, otherwise the
    reset has sequence number zero and the ACK field is set to the sum
    of the sequence number and segment length of the incoming segment.
    The connection remains in the same state.

} > Since the connection is not dropped the x.y.z.w host has retransmit
} > timeouts.
} > What is the correct behavior ?
} >
} > tcpdump
} > --------
} > 13:54:45.130913 a.b.c.d.1038 > x.y.z.w.http: S 2478243840:2478243840(0)
} > win 2048 <mss 1460> (DF)
} > 13:54:45.130969 x.y.z.w.http > a.b.c.d.1038: S 876676280:876676280(0)
} > ack 2478243841 win 17520 <mss 1460> (DF)
} > 13:54:45.131869 a.b.c.d.1038 > x.y.z.w.http: P 1:78(77) ack 1 win 2048
} > (DF)
} > 13:54:45.161755 x.y.z.w.http > a.b.c.d.1038: . ack 78 win 17520 (DF)
} > 13:54:45.352783 x.y.z.w.http > a.b.c.d.1038: P 1:210(209) ack 78 win
} > 17520 (DF)
} > 13:54:45.353055 x.y.z.w.http > a.b.c.d.1038: F 210:210(0) ack 78 win
} > 17520 (DF)
} >
} > ????????????
} > 13:54:45.353119 a.b.c.d.1038 > x.y.z.w.http: R 2478261437:2478261437(0)
} >
} > ^^^^^^^^^^^^^^^^^^^^^
} > win 1 (DF)
} > ???????????
} >
} > 13:54:46.561619 x.y.z.w.http > a.b.c.d.1038: FP 1:210(209) ack 78 win
} > 17520 (DF)
} > 13:54:49.561403 x.y.z.w.http > a.b.c.d.1038: FP 1:210(209) ack 78 win
} > 17520 (DF)
} > 13:54:55.560988 x.y.z.w.http > a.b.c.d.1038: FP 1:210(209) ack 78 win
} > 17520 (DF)
} > ..................
} >
} > thanks
} > jayanth
} >
} > To Unsubscribe: send mail to majordomo@FreeBSD.org
} > with "unsubscribe freebsd-net" in the body of the message
} 
} --------------83BAB6521073EDFB9822F331
} Content-Type: text/plain; charset=us-ascii;
}  name="xx1"
} Content-Transfer-Encoding: 7bit
} Content-Disposition: inline;
}  filename="xx1"
} 
} Jayanth,
}    Looking at RFC 793, the RST from a.b.c.d seems a valid RST
}    since it is within the window. I haven't seen the freebsd code
}    lately, but i recall that they had added the code from Page 960
}    of TCP/IP Illustrated Vol.2 long time back. That introduces a problem
}    where a RST to a previous incarnation of the same connection could get
}    accepted by the current connection and get terminated. Is the check about
}    'last_ack_sent' as you mentioned is to fix that problem ?
}    By the way, doesn't RST mostly take the ACK number of the received
}    segment for the sequence number ? In that case checking with 
}    last_ack_sent will work. But what if the RST is generated due to
}    retransmission timer connection timeout or the linger period has
}    expired SO_LINGER), etc. and some of the packets ahead were dropped ?  
}    Then the sequence number in RST segment and the last_ack_sent won't
}    match.

I think that should still be OK.  The retransmitted packets may have
lower sequence numbers than that of the last packet sent, but they
should repeat the same ACK number.  It wouldn't make sense to un-ACK
data that has already been received.

}    What platform is a.b.c.d that generates the RST with the sequence 
}    number set to the right edge of the window ?
} Venkat


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199912131755.JAA19500>