Can you dump the output of netstat -s -p tcp ? Checking for listen queue overflows and syncache bucket overflows.
jayanth Nguyen-Tuong Long Le ([EMAIL PROTECTED]) wrote: > 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 <mss 1460,nop,wscale 0,nop,nop,timestamp 33031 0> (DF) > 18:11:33.760675 152.2.136.39.6789 > 152.2.135.14.1827: S 4246482515:4246482515(0) >ack 171182595 win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp 28256 33031> > 18:11:33.761000 152.2.135.14.1827 > 152.2.136.39.6789: . ack 1 win 17376 ><nop,nop,timestamp 33061 28256> (DF) > 18:11:33.761390 152.2.135.14.1827 > 152.2.136.39.6789: P 1:5(4) ack 1 win 17376 ><nop,nop,timestamp 33061 28256> (DF) > 18:11:33.761586 152.2.135.14.1827 > 152.2.136.39.6789: P 5:13(8) ack 1 win 17376 ><nop,nop,timestamp 33061 28256> (DF) > 18:11:33.762172 152.2.135.14.1827 > 152.2.136.39.6789: P 13:293(280) ack 1 win 17376 ><nop,nop,timestamp 33061 28256> (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 [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
