From owner-freebsd-net@FreeBSD.ORG Mon Jan 1 14:22:54 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 10C6416A412 for ; Mon, 1 Jan 2007 14:22:54 +0000 (UTC) (envelope-from babolo@cicuta.babolo.ru) Received: from ints.mail.pike.ru (ints.mail.pike.ru [85.30.199.194]) by mx1.freebsd.org (Postfix) with ESMTP id 422D713C458 for ; Mon, 1 Jan 2007 14:22:53 +0000 (UTC) (envelope-from babolo@cicuta.babolo.ru) Received: (qmail 65736 invoked from network); 1 Jan 2007 13:56:10 -0000 Received: from cicuta.babolo.ru (85.30.224.245) by ints.mail.pike.ru with SMTP; 1 Jan 2007 13:56:10 -0000 Received: (nullmailer pid 67044 invoked by uid 136); Mon, 01 Jan 2007 14:00:16 -0000 X-ELM-OSV: (Our standard violations) hdr-charset=KOI8-R; no-hdr-encoding=1 In-Reply-To: <20061228203100.GA1165@gort.synoptic.org> To: Matthew Hudson Date: Mon, 1 Jan 2007 17:00:16 +0300 (MSK) From: .@babolo.ru X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <1167660016.168305.67043.nullmailer@cicuta.babolo.ru> Cc: Stephan Wehner , freebsd-net@freebsd.org Subject: Re: Diagnose co-location networking problem 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: Mon, 01 Jan 2007 14:22:54 -0000 > On Wed, Dec 27, 2006 at 10:08:25PM -0800, Stephan Wehner wrote: ... > Oh, also, going back to the 198.168 address seen in the client dumps, > it's clear that you're going through a NAT firewall or VPN or something > on the way to your server. Thus are you able to reproduce this problem > from a different external network? > > Actually, I just realized that you've provided enough information for me > to run this test myself which I've now done. I ran the following test; > > i=0; while true; do ((i++)); echo $i; curl http://stbgo.org > /dev/null; done > > I was able to make over 64 consecutive connections without a single failure > before I stopped the test (didn't want to spam your site). How sure > are you that this isn't a client-side problem? /usr/ports/net/scand/ designed for such a problem on client side when overactive.