netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Michael T Kerrisk" <mtk-lists@gmx.net>
To: netdev@oss.sgi.com
Subject: Assassination of TIME_WAIT state (RESEND)
Date: Wed, 4 Aug 2004 15:22:27 +0200 (MEST)	[thread overview]
Message-ID: <16217.1091625747@www2.gmx.net> (raw)

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 2745 bytes --]

Gidday,

I did try posting this many weeks back, but got response.
I'll take another shot -- does anyone have thoughts on the
questions below?

==

In the scenario below, one achieves assassination of the
TIME_WAIT state on Linux 2.6.5 and 2.4.x.  From a conversation
I had a while ago with Andi Kleen (see below), it appears
that this is expected behavior.  I have two (closely linked)
questions:

-- what is the rationale for this behavior (i.e., why assassinate
   in this scenario)?

-- why does Linux behave differently from FreeBSD and Solaris
   in this scenario?

Assume in the following scenario that SO_RESUSEADDR is set on
the server socket(s):

Server                           Client

1. Create listening socket
   bound to INADDR_ANY/port=9999
2. Accept a connection on
   the listening socket
                                 3. Create a socket bound
                                    to INADDR_ANY/port=50000
                                 4. Connect to server socket
                                    (on port 9999)
5. Close listening and
   connected sockets
                                 6. Close the socket

At this point, there is TCP on the server side in the TIME_WAIT
state: { local=localhost:9999, peer=XXX:50000 }

(re-run server)
7. Create listening socket
   bound to INADDR_ANY/port=9999
8. Accept a connection on
   the listening socket
                                 (re-run client while TIME_WAIT
                                 TCP still exists)
                                 9. Create a socket bound
                                    to INADDR_ANY/port=50000
                                 10.Connect to server socket
                                    (on port 9999)

On Linux the connect() in step 10 succeeds; the reason that it
does is that the TIME_WAIT TCP is immediately assassinated.  

A while back I asked Andi Kleen about this scenario, and he
commented that this behavious was:

> a (dubious) BSD extension, also implemented
> in linux (after all sockets is about being bug to bug coompatible).
> the kernel sees the TIME-WAIT and choses a sequence number with
> a large offset to avoid conflicts. When you don't have PAWS
> but still had a big window it is rather risky though.

However, when I try the above on FreeBSD 5.1 and Solaris 8, we see
different behavior: the TIME_WAIT TCP is NOT assassinated and the
connect() at step 10 fails with EADDRINUSE (which makes sense
because we can't create a duplicate 4-tuple...).

Cheers,

Michael

-- 
Michael Kerrisk
mtk-lists@gmx.net

NEU: WLAN-Router für 0,- EUR* - auch für DSL-Wechsler!
GMX DSL = supergünstig & kabellos http://www.gmx.net/de/go/dsl

                 reply	other threads:[~2004-08-04 13:22 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=16217.1091625747@www2.gmx.net \
    --to=mtk-lists@gmx.net \
    --cc=netdev@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).