From owner-freebsd-bugs  Thu Oct  2 09:54:06 1997
Return-Path: <owner-freebsd-bugs>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id JAA08128
          for bugs-outgoing; Thu, 2 Oct 1997 09:54:06 -0700 (PDT)
Received: from red.juniper.net (red.juniper.net [208.197.169.254])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA08107;
          Thu, 2 Oct 1997 09:53:57 -0700 (PDT)
Received: from base.juniper.net (base.juniper.net [208.197.169.208])
	by red.juniper.net (8.8.5/8.8.5) with ESMTP id JAA24951;
	Thu, 2 Oct 1997 09:53:26 -0700 (PDT)
Received: from base.juniper.net (localhost.juniper.net [127.0.0.1]) by base.juniper.net (8.8.7/8.7.3) with ESMTP id JAA05848; Thu, 2 Oct 1997 09:53:13 -0700 (PDT)
Message-Id: <199710021653.JAA05848@base.juniper.net>
To: Don Lewis <Don.Lewis@tsc.tdk.com>
cc: Richard Jones <richard@a42.deep-thought.org>,
        "Jordan K. Hubbard" <jkh@time.cdrom.com>, dg@root.com,
        hackers@FreeBSD.ORG, bugs@FreeBSD.ORG
Subject: Re: FreeBSD TCP stack and RST processing [subj changed] 
In-reply-to: Your message of "Wed, 01 Oct 1997 18:37:36 PDT."
             <199710020137.SAA16461@salsa.gv.tsc.tdk.com> 
Date: Thu, 02 Oct 1997 09:53:13 -0700
From: Paul Traina <pst@juniper.net>
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk


  From: Don Lewis <Don.Lewis@tsc.tdk.com>
  Subject: Re: FreeBSD TCP stack and RST processing [subj changed]
  On Oct 2, 11:09am, Richard Jones wrote:
  } Subject: Re: FreeBSD TCP stack and RST processing [subj changed]
  } Paul Traina <pst@juniper.net> wrote:
  } > I put it in there for a reason, Steven's III showed a case where you coul
>>d
  } > pummel the box with a barage of, I believe, syn ack's and basicly melt th
>>ings.
  } > Sorry my memory is so foggy on the issue now.  I'll go back and try to 
  } > remember.
  
  Steven's III?  I don't have that one, since I figured that I already knew
  how NNTP worked.

No, it's actually the most interesting, because it goes into a lot of
performance.
  
  } Hmm..but if you barrage the system with SYN ACK's when the system is in a 
  } listen state, you shouldn't jump into SYN_RECEIVED should you?
  
  Nope.  This case is handled earlier:
  
          case TCPS_LISTEN: {
                  struct mbuf *am;
                  register struct sockaddr_in *sin;
                  
                  if (tiflags & TH_RST)
                          goto drop;
                  if (tiflags & TH_ACK)
                          goto dropwithreset;
                  if ((tiflags & TH_SYN) == 0)
                          goto drop;

Yep, and the bug is that the two got spammed together after I gutted one.