Date: Thu, 02 Oct 1997 11:09:47 +1000 From: Richard Jones <richard@a42.deep-thought.org> To: Paul Traina <pst@juniper.net> Cc: "Jordan K. Hubbard" <jkh@time.cdrom.com>, dg@root.com, Don Lewis <Don.Lewis@tsc.tdk.com>, hackers@FreeBSD.ORG, bugs@FreeBSD.ORG Subject: Re: FreeBSD TCP stack and RST processing [subj changed] Message-ID: <m0xGZlz-0024w4C@a42.deep-thought.org> In-Reply-To: Your message of "Wed, 01 Oct 1997 17:54:24 MST." <199710020054.RAA04241@base.juniper.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Paul Traina <pst@juniper.net> wrote: > I put it in there for a reason, Steven's III showed a case where you could > pummel the box with a barage of, I believe, syn ack's and basicly melt things. > Sorry my memory is so foggy on the issue now. I'll go back and try to > remember. 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? The code which does the if (TH_RST) stuff is prolly ok...its the addition of the case SYN_RECEIVED up the top that does the trick. Its ok to look for an ACK when in SYN_SENT on RST's coz thats what is expected, and if you get other than expected and drop then its no big deal unless you can force a remote freebsd system to send out (pure) SYN's to non-connected ports, unlikely. I only have the snippets posted to the list available, but based on them I'd say remove the case SYN_RECEIVED that was added. You might get away with getting rid of the ACK flag check without losing anything, but any side effects should be thought through. Anyways I'm running late for appointment which is why this may sound a little incoherent, gotta run. Richard Jones.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m0xGZlz-0024w4C>