From owner-freebsd-net@FreeBSD.ORG Sat Jul 16 15:28:29 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7CC0106566B for ; Sat, 16 Jul 2011 15:28:28 +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 471E18FC14 for ; Sat, 16 Jul 2011 15:28:27 +0000 (UTC) Received: (qmail 72049 invoked from network); 16 Jul 2011 14:26:13 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 16 Jul 2011 14:26:13 -0000 Message-ID: <4E21AE1B.6070000@freebsd.org> Date: Sat, 16 Jul 2011 17:28:27 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Vladimir Budnev References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: (TCP/IP) Server side sends RST after 3-way handshake.Syn flood defense or queue overflow? 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: Sat, 16 Jul 2011 15:28:29 -0000 On 13.07.2011 12:37, Vladimir Budnev wrote: > Hello. > > Iv faced some problem and seems don't realize the mechanincs why does it > occures. > First of all i'd like to notice that my freebsd knowledge and expirience is > limited, especially in such "strange" cases. > > In details(code example ill be at the end): > > System: > # uname -spr > FreeBSD 7.2-RELEASE amd64 > > We have simple TCP client and server. > > Server is very casual, it listens on some port in while->select->accept > loop. > > Client knocks on server port and sends some data and closes the port. > First it was designed for sending data 3-5/times per minute. But once during > test I'v noticed that if client sends data very fast (more precisely it > opens and closes socket to server very fast) there is > "54 - Connection reset by peer" error on call to "connect".(on client side > ofc) > > Some illustration from tcpdump: > (test on localhost.server side is port 10002.i'v cuted other fields for > simplicity) > <...> > 13:48:58.491229 IP 127.0.0.1.56677> 127.0.0.1.10002: S > 13:48:58.491255 IP 127.0.0.1.10002> 127.0.0.1.56677: S ack > 13:48:58.491266 IP 127.0.0.1.56677> 127.0.0.1.10002: . ack > 13:48:58.491300 IP 127.0.0.1.56677> 127.0.0.1.10002: P > 13:48:58.491346 IP 127.0.0.1.56677> 127.0.0.1.10002: F > 13:48:58.491365 IP 127.0.0.1.10002> 127.0.0.1.56677: . ack > > 13:48:58.491466 IP 127.0.0.1.55238> 127.0.0.1.10002: S // > 13:48:58.491490 IP 127.0.0.1.10002> 127.0.0.1.55238: S ack // handshake > 13:48:58.491503 IP 127.0.0.1.55238> 127.0.0.1.10002: . ack // > 13:48:58.491536 IP 127.0.0.1.55238> 127.0.0.1.10002: P<--data > 13:48:58.491580 IP 127.0.0.1.55238> 127.0.0.1.10002: F<-- client > closes session > 13:48:58.491599 IP 127.0.0.1.10002> 127.0.0.1.55238: . ack // OK > > 13:48:58.491701 IP 127.0.0.1.60212> 127.0.0.1.10002: S > 13:48:58.491726 IP 127.0.0.1.10002> 127.0.0.1.60212: S ack > 13:48:58.491738 IP 127.0.0.1.60212> 127.0.0.1.10002: . ack > 13:48:58.491745 IP 127.0.0.1.10002> 127.0.0.1.60212: R<-- this is > strange answer.Why? > > 13:48:58.491887 IP 127.0.0.1.60804> 127.0.0.1.10002: S > 13:48:58.491914 IP 127.0.0.1.10002> 127.0.0.1.60804: S ack > 13:48:58.491924 IP 127.0.0.1.60804> 127.0.0.1.10002: . ack > 13:48:58.491931 IP 127.0.0.1.10002> 127.0.0.1.60804: R > <...> > > Some connections were OK but then server application begin to send RST right > after handshake. > Tuning listen backlog parameter doesn't help much, BUT what really solves > the "problem" is increasing time interval between client > requests.egusleep(10000) solves the "problem" at all. > > Iv maned for some tuning like syncache and syncookies but nothing usefull, > or i missed something.But here they are: > > # sysctl -a | grep syncache > net.inet.tcp.syncache.rst_on_sock_fail: 1 > net.inet.tcp.syncache.rexmtlimit: 3 > net.inet.tcp.syncache.hashsize: 512 > net.inet.tcp.syncache.count: 0 > net.inet.tcp.syncache.cachelimit: 15360 > net.inet.tcp.syncache.bucketlimit: 30 > > > ipfw rules allows any from any, nothing special. > > QUESTION: > So the question is why such thing happening?Is this is some freebsd defense > from syn flood?(to be honest don't think so because seems there is no fixed > "ALLOWED syn/syn-ack/ack per seconds"). It more looks like some queue > overflow,but I don't know what queue and how it can be enlarged. > > If i can provide some more info to clear some aspects I will! When you enable "net.inet.tcp.log_debug=1" it will tell you at LOG_DEBUG level what went wrong and why it sent the RST. -- Andre