Date: Wed, 13 Jul 2011 16:37:24 +0400 From: Vladimir Budnev <vladimir.budnev@gmail.com> To: John Baldwin <jhb@freebsd.org> 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: <CAAvRK952ci0OFhvrXH2Ji22=QYjQ4jw1W1gpiKkoEAQ29vauTA@mail.gmail.com> In-Reply-To: <201107130757.19178.jhb@freebsd.org> References: <CAAvRK97hwamb8mpu6G6FEbkYATQ3BWNZoFYbsvmgKDwHNXFsLA@mail.gmail.com> <201107130757.19178.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAAvRK952ci0OFhvrXH2Ji22=QYjQ4jw1W1gpiKkoEAQ29vauTA>