Date: Sat, 16 Jul 2011 17:28:27 +0200 From: Andre Oppermann <andre@freebsd.org> To: Vladimir Budnev <vladimir.budnev@gmail.com> Cc: freebsd-net@freebsd.org Subject: Re: (TCP/IP) Server side sends RST after 3-way handshake.Syn flood defense or queue overflow? Message-ID: <4E21AE1B.6070000@freebsd.org> In-Reply-To: <CAAvRK97hwamb8mpu6G6FEbkYATQ3BWNZoFYbsvmgKDwHNXFsLA@mail.gmail.com> References: <CAAvRK97hwamb8mpu6G6FEbkYATQ3BWNZoFYbsvmgKDwHNXFsLA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E21AE1B.6070000>