From owner-freebsd-net@FreeBSD.ORG Wed Jan 4 04:17:34 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 0AF1D16A41F for ; Wed, 4 Jan 2006 04:17:34 +0000 (GMT) (envelope-from Bob.Halley@nominum.com) Received: from shell-ng.nominum.com (shell-ng.nominum.com [81.200.64.181]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4818C43D62 for ; Wed, 4 Jan 2006 04:17:33 +0000 (GMT) (envelope-from Bob.Halley@nominum.com) Received: from [128.177.199.33] (vpn-33.vpn.nominum.com [128.177.199.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 7F10D5685A for ; Tue, 3 Jan 2006 20:17:32 -0800 (PST) (envelope-from Bob.Halley@nominum.com) Message-ID: <43BB4C59.3010800@nominum.com> Date: Wed, 04 Jan 2006 14:47:29 +1030 From: Bob Halley User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: multipart/mixed; boundary="------------060309070601060706020401" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Unexpected EADDRINUSE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2006 04:17:34 -0000 This is a multi-part message in MIME format. --------------060309070601060706020401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Some of our regression tests fail randomly on FreeBSD with an unexpected EADDRINUSE error. We didn't see this problem with 4.7, but we see it in 4.11, 5.4, and 6.0. We don't see this behavior on any of our other supported platforms. We investigated the problem, and managed to come up with a way to reproduce the problem outside of our regression test suite. To reproduce, first start the sink with "python sink.py". Then run "python conn.py". When we do this, we get EADDRINUSE after a short time. Since we're binding the connecting socket to the wild port, this shouldn't happen. If the s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) call is removed, the problem seems to go away. The setting of SO_REUSEADDR is there because that's what some perhaps too-generic make-a-socket library code did; we realize it's not technically needed. Nevertheless, we don't see why it should fail either :). I looked at the differences between 4.7 and later kernels but didn't manage to figure out how the changes caused this change in behavior. Regards, /Bob --------------060309070601060706020401--