From owner-freebsd-hackers  Fri Dec 18 14:56:34 1998
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id OAA14673
          for freebsd-hackers-outgoing; Fri, 18 Dec 1998 14:56:34 -0800 (PST)
          (envelope-from owner-freebsd-hackers@FreeBSD.ORG)
Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93])
          by hub.freebsd.org (8.8.8/8.8.8) with SMTP id OAA14655
          for <freebsd-hackers@freebsd.org>; Fri, 18 Dec 1998 14:56:32 -0800 (PST)
          (envelope-from fenner@parc.xerox.com)
Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <61172(5)>; Fri, 18 Dec 1998 14:56:16 PST
Received: from localhost by crevenia.parc.xerox.com with SMTP id <177534>; Fri, 18 Dec 1998 14:56:10 -0800
To: Terry Lambert <tlambert@primenet.com>
cc: freebsd-hackers@FreeBSD.ORG
Subject: Re: tcp bug on reeBSD 
In-reply-to: Your message of "Fri, 18 Dec 98 14:28:56 PST."
             <199812182228.PAA13686@usr09.primenet.com> 
Date: Fri, 18 Dec 1998 14:56:02 PST
From: Bill Fenner <fenner@parc.xerox.com>
Message-Id: <98Dec18.145610pst.177534@crevenia.parc.xerox.com>
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

In message <199812182228.PAA13686@usr09.primenet.com> you write:
>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.

With delayed ACK's, the sequence is generally
server: FIN
client: FIN/ACK
server: ACK

If you get unlucky with delayed ACK's or your client is extremely
slow, you might get
server: FIN
client: ACK
client: FIN
server: ACK

but from TCP's point of view, the client's FIN isn't related to the
server's FIN; it's in response to the client application's request to
close the connection.

>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".

You're suggesting that the timeout, instead of removing the state,
pretend that the FIN wasn't acknowledged and switch to FIN_WAIT_1 and
retransmit the "unacknowledged" FIN?

>With this enabled, you can get rid of the long timeout kludge, as
>well.

Well, you just do something different when the timeout occurs, n'est-ce
pas?

  Bill

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