From owner-freebsd-net@FreeBSD.ORG Thu Jul 11 15:05:49 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D4C2422F; Thu, 11 Jul 2013 15:05:49 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id A747912C7; Thu, 11 Jul 2013 15:05:48 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA08475; Thu, 11 Jul 2013 18:05:47 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1UxIRG-000N76-Nc; Thu, 11 Jul 2013 18:05:46 +0300 Message-ID: <51DEC992.2040902@FreeBSD.org> Date: Thu, 11 Jul 2013 18:04:50 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130708 Thunderbird/17.0.7 MIME-Version: 1.0 To: Andre Oppermann Subject: Re: Listen queue overflow: N already in queue awaiting acceptance References: <51DE591E.7040405@FreeBSD.org> <51DE5C8C.3090404@freebsd.org> <20130711133504.GB67810@FreeBSD.org> <51DEC10B.3080409@freebsd.org> In-Reply-To: <51DEC10B.3080409@freebsd.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 15:05:49 -0000 on 11/07/2013 17:28 Andre Oppermann said the following: > Andriy for example would never have found out about this problem other > than receiving vague user complaints about aborted connection attempts. > Maybe after spending many hours searching for the cause he may have > interfered from endless scrolling in Wireshark that something wasn't > right and blame syncache first. Only later it would emerge that he's > either receiving too many connections or his application is too slow > dealing with incoming connections. That's true, but OTOH there are many interesting network conditions like excessive packet loss that we don't shout about. The stats are quietly gathered and can be examined with netstat. If a system is properly monitored then such counters are graphed and can trigger alarms. If the system just misbehaves then an administrator can use netstat for inspection. Spamming logs in the case of e.g. DDoS attack is not very helpful, IMO. -- Andriy Gapon