From owner-freebsd-net@FreeBSD.ORG Tue Oct 28 11:23:35 2003 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 F00C216A4CE for ; Tue, 28 Oct 2003 11:23:35 -0800 (PST) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id EAFA443F85 for ; Tue, 28 Oct 2003 11:23:34 -0800 (PST) (envelope-from silby@silby.com) Received: (qmail 43684 invoked from network); 28 Oct 2003 19:23:33 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 28 Oct 2003 19:23:33 -0000 X-pair-Authenticated: 209.68.2.70 Date: Tue, 28 Oct 2003 13:23:32 -0600 (CST) From: Mike Silbersack To: Bruce M Simpson In-Reply-To: <20031028050103.GA7279@saboteur.dek.spc.org> Message-ID: <20031028131329.J19707@odysseus.silby.com> References: <20031027014854.K2023@odysseus.silby.com> <20031028050103.GA7279@saboteur.dek.spc.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: Changes to PCBPORTHASH wrt TCP, review needed 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, 28 Oct 2003 19:23:36 -0000 On Tue, 28 Oct 2003, Bruce M Simpson wrote: > We discussed on IRC that this problem of ephemeral port hash mapping may also > affect udp PCBs, and that it may be having undesirable effects with multiple > concurrent media streams, as RTP/RTCP is a heavy udp socket consumer in a > large installation, and has specific requirements for binding consecutive > odd/even port pairs (more details in RFC 3550 for those who care). > > I will test the patch shortly. I have looked over it and can't find any > immediate problems with it, but further digestion on my part is required. > > BMS Bleh, I found a problem with my suggested change. Suppose that a program works as follows: 1. bind (to an ephemeral port) 2. connect It's very possible that bind will return a port which can't be used because it's already in use for that destination lport-laddr-fport-faddr tuple, so the connect will fail with EADDRINUSE. So, it looks like I can't solve this so simply... looks like I'll have to have the port lookup do IP comparisons as well. Mike "Silby" Silbersack