From owner-freebsd-net@FreeBSD.ORG Thu May 24 20:26:21 2007 Return-Path: X-Original-To: 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 570DC16A46F for ; Thu, 24 May 2007 20:26:21 +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 C17EE13C448 for ; Thu, 24 May 2007 20:26:20 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 63658 invoked from network); 24 May 2007 19:16:42 -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 ; 24 May 2007 19:16:42 -0000 Message-ID: <4655EEAD.2060307@freebsd.org> Date: Thu, 24 May 2007 21:59:41 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Gleb Smirnoff References: <20070524182545.GF89017@FreeBSD.org> In-Reply-To: <20070524182545.GF89017@FreeBSD.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: net@FreeBSD.org Subject: Re: TCP problems after 124 days of uptime? 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: Thu, 24 May 2007 20:26:21 -0000 Gleb Smirnoff wrote: > Yesterday two of our web servers running 6.2-PRERELEASE experienced > problems with accepting TCP connections. A small percentage of SYN > packets was ignored. The packets were seen in tcpdump output, but not > processed by TCP stack. No accept queue overflows occured, according > to 'netstat -sp tcp'. > > Failing to find any clue I have rebooted one of them, and after > reboot is started to work flawlessly. Reboot also helped the second > one. Both servers were booted at the same time - 124 days ago. > > Any ideas, any similar reports? ticks is a 32 bit signed integer and TCP isn't really aware of it going negative and rolling over. This is something I'm working on fixing in -current. Haven't analyzed all potential cases there yet. -- Andre