From owner-freebsd-net@FreeBSD.ORG Wed Jul 13 12:37:25 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 6A3A2106566B for ; Wed, 13 Jul 2011 12:37:25 +0000 (UTC) (envelope-from vladimir.budnev@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 20B7D8FC19 for ; Wed, 13 Jul 2011 12:37:24 +0000 (UTC) Received: by vws18 with SMTP id 18so5741848vws.13 for ; Wed, 13 Jul 2011 05:37:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=INCkpSjooey2gwBTpGGCcopKtYQeTS+pVtvVdZfT6/g=; b=aolCNzsxZ3WW6Yea8PHJoNdYChzGSwWO6yUbBzsFd0oBg/mFWBRoyiIgRjJc6p0jfK PTUAWENdNNgWwpMUw5ZkDl/isQNtv04g8DVYkwcRSj2x3ivMc05CZ1I4Y/V7NTeNX9Ax eEMgM/yR8X1GKe6y4T0ymZIBM42iHogYhM8kw= MIME-Version: 1.0 Received: by 10.52.65.228 with SMTP id a4mr1205928vdt.137.1310560644343; Wed, 13 Jul 2011 05:37:24 -0700 (PDT) Received: by 10.220.178.129 with HTTP; Wed, 13 Jul 2011 05:37:24 -0700 (PDT) In-Reply-To: <201107130757.19178.jhb@freebsd.org> References: <201107130757.19178.jhb@freebsd.org> Date: Wed, 13 Jul 2011 16:37:24 +0400 Message-ID: From: Vladimir Budnev To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 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: Wed, 13 Jul 2011 12:37:25 -0000 First of all thanks for response! It is normal for syncache entries added == completed == cookies sent, I'm > mostly curious about anything else besides that. It is possible when using > the syncache to have the network stack decide it can't create a connection > until it gets to the end of the 3-way handshake due to resource limits, > etc. > In that case the end of the 3-way handshake will get a RST in response. > statistics i have: (cutted from netstat -s -p tcp) 89514 syncache entries added 0 retransmitted 0 dupsyn 0 dropped 50220 completed 0 bucket overflow 0 cache overflow 0 reset 0 stale 39294 aborted 0 badack 0 unreach 0 zone failures 89514 cookies sent According to your hint I see nonzero aborted field, but dont know how to get the reason/interpret this. > However, if your app just sends data and calls close() without doing any > reads, it might close() succesfully while the data is in flight before the > client machine sees the RST, so the client app will not see any errors. If > the RST arrives before you finish calling write() and close() then you will > get ECONNRESET errors from write() and close(). > Hm..hope i get your idea, the difference is that client application recieve ECONNRESET as result to _connect_ call not as result from write/read/close, at that point i cant ignore it. I can spin/wait and try again, but that way every N iterations when problem occures there will be this "problem". As i mentioned(and in code example) client on every iteration makes connect/close, and those come very fast. Mb i misunderstood smth. You can try turning off the syncache and syncookies as a test. This will > probably trigger more ECONNRESET errors in connect() (which your app will > need > to retry on). Spin idea...yeah it sounds friendly but i dont think sy/syn-ack/ack/rst flood would be great:( > However, the better fix is to track down what is causing your > connections to be dropped in the first place, e.g. if you are hitting the > limit on inpcbs (look for failures in vmstat -z output) and fix that. > # vmstat -z ITEM SIZE LIMIT USED FREE REQUESTS FAILURES <...> inpcb: 288, 25610, 6, 5155, 142849, 0 tcpcb: 728, 25600, 6, 454, 142849, 0 <...> Those ones looks ok? > > -- > John Baldwin >