From owner-freebsd-net Tue Jun 4 16:45:40 2002 Delivered-To: freebsd-net@freebsd.org Received: from wren.cs.unc.edu (wren.cs.unc.edu [152.2.128.86]) by hub.freebsd.org (Postfix) with ESMTP id 1EA0E37B400 for ; Tue, 4 Jun 2002 16:45:33 -0700 (PDT) Received: from capefear.cs.unc.edu (capefear.cs.unc.edu [152.2.128.19]) by wren.cs.unc.edu (8.9.3/8.9.3) with ESMTP id TAA14128; Tue, 4 Jun 2002 19:45:31 -0400 (EDT) Date: Tue, 4 Jun 2002 19:45:31 -0400 (EDT) From: Nguyen-Tuong Long Le To: freebsd-net@freebsd.org Cc: Nguyen-Tuong Long Le Subject: Re: Problem with SYN cache in FreeBSD 4.5 In-Reply-To: <20020603121118.Y38431-100000@patrocles.silby.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 3 Jun 2002, Mike Silbersack wrote: > A few questions: > > 1. Is this 4.5-release, or 4.5-stable (aka 4.6-RC2)? 4.5-release had a > few bugs in the syn cache which could cause crashes. > > 2. Are you using accept filters? Accept filters act oddly on > 4.5-release, you'll have to upgrade to 4.5-stable/4.6. > > 3. Could you use tcpdump to determine what exactly is going wrong and > post a url to the log so that we can investigate what is going wrong? Hi all, Thanks for all your suggestions. I've tried out all of them but they unfortunately didn't fix the problem. I have this problem with 4.5-RELEASE. I cvsup'ed the source tree and tried 4.5-RELEASE-p6 and 4.6-RC #1 but they didn't fix the problem. Setting net.inet.tcp.syncookies didn't help either. I use poll(). I don't use accept filters. I instrumented some code in tcp_input() that seems to indicate that lots of TCP segments (about 42000 segments in 10 minutes) are dropped because syncache_expand() returns 0. This in turn is caused because syncache_lookup() and syncookie_lookup() return NULL. Why this is happening is beyond my knowledge. I took a 10-minute tcpdump trace and put it up at www.cs.unc.edu/~le/tmp/ti.dump.gz (It's actually two one-way tcpdump traces taken at the fiber tap next to the server. I used tcpslice from tcpdump.org to merge them. I checked that all packets from the two one-way traces are in the merged trace and they seem to be sorted in timestamp order). Here is a typical sequence of exchanges for connections that are reset by the server. The server ack's the first SYN by a SYN/ACK but doesn't ack any segment after that. 18:11:33.461574 152.2.135.14.1827 > 152.2.136.39.6789: S 171182594:171182594(0) win 16384 (DF) 18:11:33.760675 152.2.136.39.6789 > 152.2.135.14.1827: S 4246482515:4246482515(0) ack 171182595 win 16384 18:11:33.761000 152.2.135.14.1827 > 152.2.136.39.6789: . ack 1 win 17376 (DF) 18:11:33.761390 152.2.135.14.1827 > 152.2.136.39.6789: P 1:5(4) ack 1 win 17376 (DF) 18:11:33.761586 152.2.135.14.1827 > 152.2.136.39.6789: P 5:13(8) ack 1 win 17376 (DF) 18:11:33.762172 152.2.135.14.1827 > 152.2.136.39.6789: P 13:293(280) ack 1 win 17376 (DF) 18:11:34.031741 152.2.136.39.6789 > 152.2.135.14.1827: R 4246482516:4246482516(0) win 0 18:11:34.046008 152.2.136.39.6789 > 152.2.135.14.1827: R 4246482516:4246482516(0) win 0 18:11:34.060284 152.2.136.39.6789 > 152.2.135.14.1827: R 4246482516:4246482516(0) win 0 Any hint or suggestion would be very much appreciated. Thanks, -- long To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message