(TCP/IP) Server side sends RST after 3-way handshake.Syn flood defense or queue overflow?

[Vladimir Budnev]

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
>