From owner-freebsd-hackers Sat May 25 19:43:29 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA27931 for hackers-outgoing; Sat, 25 May 1996 19:43:29 -0700 (PDT) Received: from zen.nash.org (nash.pr.mcs.net [204.95.47.72]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA27910 for ; Sat, 25 May 1996 19:42:39 -0700 (PDT) Received: (from alex@localhost) by zen.nash.org (8.7.5/8.6.12) id VAA00267; Sat, 25 May 1996 21:42:11 -0500 (CDT) Date: Sat, 25 May 1996 21:42:11 -0500 (CDT) Message-Id: <199605260242.VAA00267@zen.nash.org> From: Alex Nash To: hackers@freebsd.org Cc: davidg@root.com Subject: Grrr.. is this is a FreeBSD problem (TIME_WAIT again) Reply-to: nash@mcs.com Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I understand the purpose behind the 2MSL wait, but my understanding was that > this was imposed for non-cleanly closed connections to prevent a collision > (and possibly delivering data to the "wrong" client). I won't even attempt to rewrite the words of Stevens, so here they are straight from page 243 of TCP/IP Illustrated Vol 1: Given the MSL value for an implementation, the rule is: when TCP performs an active close, and sends the final ACK, that connection must stay in the TIME_WAIT state for twice the MSL. This lets TCP resend the final ACK in case this ACK is lost (in which case the other end will time out and retransmit the final FIN). Of course this doesn't explain why you don't see the problem across multiple machines. Are you sure that neither end is in TIME_WAIT? Alex