Date: Fri, 18 Dec 1998 22:28:56 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: guido@gvr.org (Guido van Rooij) Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: tcp bug on reeBSD Message-ID: <199812182228.PAA13686@usr09.primenet.com> In-Reply-To: <19981216140244.A5966@gvr.org> from "Guido van Rooij" at Dec 16, 98 02:02:44 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> I think wcarchive is not behaving okay by sending the RST. Wcarchive is > in the FIN-WAIT-1 or FIN-WAIT-2 state and from what I see in the rfc, > wcarchive may only send an RST if: > 3. If the connection is in a synchronized state (ESTABLISHED, > FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), > any unacceptable segment (out of window sequence number or > unacceptible acknowledgment number) must elicit only an empty > acknowledgment segment containing the current send-sequence number > and an acknowledgment indicating the next sequence number expected > to be received, and the connection remains in the same state. > > But the RST did not ack anything. But besides, the segment > (3641922000:3641922006) is not an unacceptable segment accoriding > to what thr RFC says. A half-close is a perfectly valid mechanism > and my host is allowed to send additional segments to wcarchive. > However, from looking at the RFC I can not discover how wcarchive > should act. I think it should just ack 3641922000 again and have > my host discover that the other end closed the connection. > > What do you guys think? If this is from a Windows client, there is a well known client bug that no one but Paul Vixie and Microsoft do anything about. Basically, if you do a stream content command based shutdown of the connection, then the server shuts down the connection to the client. If the client does nto call shutdown(2), or is an OS (like Windows) where there is no esource tracking implied shutdown(2) of socket descriptors, and the client destroys the socket without a shutdown, then the server hangs in FIN-WAIT-2 forever. If the server is a FreeBSD box or a Solaris box or a Linux box that has been kludges, then it keeps a FIN-WAIT-2 around for however long the kernel FIN-WAIT-2 timeout is set for (in violation of the RFC 793 requirements for connection drain, we have a timeout). Basically, this is a result in a bug in the TCP/IP protocol design, where a single packet from the server is expected to elicit two response packets from the client. [ Any protocol that expects two reponses for one request is inherently broken. ] If the server is an NT box or an NT compatible box, here's what happens instead: 1) If the CTL/ACK is not seen in 2 MSL, the connection leaves FIN-WAIT-2, sends the shutdown notification again, and reenters FIN-WAIT-1. 2) If the ACK comes back, then it reenters the FIN-WAIT-2, which basically means that it is resoliciting a "lost" CTL/ACK from the client (and the client knows this, since it sent the ACK). 3) If the client has destroyed the connection, then the FIN-WAIT-1 solicitation is not ACK'ed by the client; instead, the client RST's the connection (since it has no record of a connection shutdown in progress). 4) If the server gets an RST, it acts as if, on entering the FIN-WAIT-2 state, that a CTL,ACK had been sent by the client, completing the close normally. This behaviour should be implemented in FreeBSD as a sysctl; you could call it "nt_bug_compatabile", but it's probably more correct to call it "patch_fin_wait_2_bug". A side effect of this is that you may, with a slow but correct client, get a lot of "CTL,ACK->"/"<-ACK" traffic until the client finally drains. More likely, however, since most clients are Windows boxes, you will get much earlier recovery of server resources. With this enabled, you can get rid of the long timeout kludge, as well. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?199812182228.PAA13686>