From owner-freebsd-current@FreeBSD.ORG Wed Jan 26 02:45:39 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CDF4D16A4CE; Wed, 26 Jan 2005 02:45:39 +0000 (GMT) Received: from daintree.corp.yahoo.com (daintree.corp.yahoo.com [216.145.52.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC5E943D48; Wed, 26 Jan 2005 02:45:39 +0000 (GMT) (envelope-from peter@wemm.org) Received: by daintree.corp.yahoo.com (Postfix, from userid 2154) id A332A19771; Tue, 25 Jan 2005 18:45:39 -0800 (PST) From: Peter Wemm To: freebsd-current@freebsd.org Date: Tue, 25 Jan 2005 18:45:38 -0800 User-Agent: KMail/1.7.1 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200501251845.39192.peter@wemm.org> cc: Robert Watson cc: current@freebsd.org Subject: Re: OpenBSD's tcpdrop(8) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2005 02:45:40 -0000 On Sunday 23 January 2005 09:33 am, Robert Watson wrote: > On Sun, 23 Jan 2005, Maxim Konovalov wrote: > > I've ported OpenBSD's tcpdrop(8) and a relevant kernel part. > > > > >From the man page, http://tinyurl.com/4lvo9 > > > > The tcpdrop command drops the TCP connection specified by the > > local address laddr, port lport and the foreign address faddr, port > > fport. > > > > There are patches for HEAD and RELENG_4: > > > > http://people.freebsd.org/~maxim/diff/tcpdrop.diff > > http://people.freebsd.org/~maxim/diff/tcpdrop.diff-4 > > > > Two questions: do we want to have it in the base system? Does the > > diff look OK (I didn't test IPv6 part)? > > The locking in the 6.x version looked reasonable, although you need > to check to see if the (tp) returned by tcp_drop() is NULL or not and > then conditionally unlock the inpcb if it's non-NULL -- otherwise you > might unlock a free'd inpcb. There doesn't seem to be much > validation of the tcp_ident_mapping structure, such as validation > that the address lengths, etc, are correct? We have used something like this at work for a very long time, except not with such a nice interface. It can actually be rather handy! I'd like to see it go in once the rough edges are smoothed out. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5