From owner-freebsd-net@FreeBSD.ORG Tue Jun 1 13:44:59 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 48F0C16A4CE for ; Tue, 1 Jun 2004 13:44:59 -0700 (PDT) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 85EF043D1F for ; Tue, 1 Jun 2004 13:44:58 -0700 (PDT) (envelope-from andre@freebsd.org) Received: (qmail 95485 invoked from network); 1 Jun 2004 20:44: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 ; 1 Jun 2004 20:44:57 -0000 Message-ID: <40BCEACA.8918878F@freebsd.org> Date: Tue, 01 Jun 2004 22:44:58 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mike Silbersack References: <20040601120238.B44353@atlantis.atlantis.dp.ua> <20040601120412.B63021@odysseus.silby.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: Dmitry Pryanishnikov cc: freebsd-net@freebsd.org Subject: Re: net.inet.ip.portrange.randomized=1 hurts X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2004 20:44:59 -0000 Mike Silbersack wrote: > > On Tue, 1 Jun 2004, Dmitry Pryanishnikov wrote: > > > The main question is: how to prevent this situation? Of course, as a > > workaround I can set net.inet.ip.portrange.randomized to zero, but what's > > the real solution? Is it FTP-client or FTP-server that should take care of > > the previous DATA port usage? Or even network stack behaviour should be > > further modified to avoid this collision? > > > > Sincerely, Dmitry > > -- > > Atlantis ISP, System Administrator > > e-mail: dmitry@atlantis.dp.ua > > nic-hdl: LYNX-RIPE > > Sounds like something that should be dealt with on the server's end. Some > of the changes we've made in 5.x might fix the problem, but I don't think > anyone has looked into that specific case. A port should not be reused this fast. Maybe the randomness isn't so random after all and choses the same port over again and again? > A simpler solution might be to use passive mode. I think that you can set > that somewhere in the install options. Unless he does a full cycle of all available ports there shouldn't be a collision. -- Andre