From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 06:24:00 2004 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 1F54316A4CE for ; Fri, 9 Jan 2004 06:24:00 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id E059043D2F for ; Fri, 9 Jan 2004 06:23:57 -0800 (PST) (envelope-from andre@freebsd.org) Received: (qmail 234 invoked from network); 9 Jan 2004 14:23:57 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 9 Jan 2004 14:23:57 -0000 Message-ID: <3FFEB979.3C705A85@freebsd.org> Date: Fri, 09 Jan 2004 15:23:53 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Thorsten Greiner References: <20040109085522.GB4246@tybalt.nev.psi.de> <3FFE8232.730F70B8@freebsd.org> <20040109132453.GD2031@tybalt.nev.psi.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: the TCP MSS resource exhaustion commit 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: Fri, 09 Jan 2004 14:24:00 -0000 Thorsten Greiner wrote: > > * Andre Oppermann [2004-01-09 11:34]: > > You can simply increase net.inet.tcp.minmssoverload to any > > higher value. I suggest 2,000 as next step. If set it to > > 0 the check will be disabled entirely. > > Setting net.inet.tcp.minmssoverload to 4000 fixed my problem(s). Ok, that's an important information. > > This makes we wonder why the Oracle database server is sending > > so many small packets. Is your JBoss application doing connection > > pooling (eg. multiplexing multiple SQL sessions over one tcp > > session)? > > It performs connection pooling on the application layer, i.e. it > opens several connections and pools them to avoid reopening them. As > far as I understand each Oracle connection is associated with a TCP > connection - there is no pooling on the TCP level. Ok. Might it be that Oracle is setting the TCP_NODELAY option on its sending socket? I guess it is difficult to find that out... > While I have read your commit message thoroughly I am not sure I > have understood the consequences of the new mechanism. Will the > exchange of many small packets trigger a connection drop? Yes. Once you receive more than 1,000 tcp packets per second whose average size is below the net.inet.tcp.minmss value, then it will assume a malicious DoS attack. It appears that the default value of 1,000 is too low. -- Andre