From owner-freebsd-net@FreeBSD.ORG Thu Jul 11 15:43:16 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 229FB847 for ; Thu, 11 Jul 2013 15:43:16 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 8D7DC1668 for ; Thu, 11 Jul 2013 15:43:15 +0000 (UTC) Received: (qmail 89780 invoked from network); 11 Jul 2013 16:33:48 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 11 Jul 2013 16:33:48 -0000 Message-ID: <51DED28D.80502@freebsd.org> Date: Thu, 11 Jul 2013 17:43:09 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Andriy Gapon 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> <51DEC992.2040902@FreeBSD.org> In-Reply-To: <51DEC992.2040902@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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:43:16 -0000 On 11.07.2013 17:04, Andriy Gapon wrote: > 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. I agree with that. I try to make the system behavior more transparent so that even "hidden" problems can be detected easily. This includes adding more of them, like excessive packet loss. This makes FreeBSD a more friendly platform for sysadmins whereas previously people may have quietly move on to some other OS due to such unspecific complications. Most of the TCP related debugging it is protected by net.inet.tcp.log_debug. In this case it's more complicated because the socket code where this happens is protocol agnostic and I can't bond it with TCP. I'm currently looking into a) applying a rate limiter to the message (as suggested by Luigi); and b) add a per-socket accept queue overflow statistic that is visible via netstat. I'll post patches for testing when done. -- Andre