linux-kernel - Re: Doubts about listen backlog and tcp_max_syn

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 22 Jan 2013 14:01:09 -0800
From:	Rick Jones <rick.jones2@...com>
To:	Leandro Lucarella <leandro.lucarella@...iomantic.com>
CC:	Eric Dumazet <eric.dumazet@...il.com>, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: Doubts about listen backlog and tcp_max_syn_backlog

On 01/22/2013 10:42 AM, Leandro Lucarella wrote:
> On Tue, Jan 22, 2013 at 10:17:50AM -0800, Rick Jones wrote:
>>> What is important is the backlog, and I guess you didn't increase it
>>> properly. The somaxconn default is quite low (128)
>>
>> Leandro -
>>
>> If that is being overflowed, I believe you should be seeing something like:
>>
>>      14 SYNs to LISTEN sockets dropped
>>
>> in the output of netstat -s on the system on which the server
>> application is running.
>
> What is that value reporting exactly?

Netstat is reporting the ListenDrops and/or ListenOverflows  which map 
to LINUX_MIB_LISTENDROPS and LINUX_MIB_LISTENOVERFLOWS.  Those get 
incremented in tcp_v4_syn_recv_sock() (and its v6 version etc)

        if (sk_acceptq_is_full(sk))
                 goto exit_overflow;

Will increment both overflows and drops, and drops will increment on its 
own in some additional cases.

> Because we are using syncookies, and AFAIK with that enabled, all
> SYNs are being replied, and what the listen backlog is really
> limitting is the "completely established sockets waiting to be
> accepted", according to listen(2). What I don't really know to be
> honest, is what a "completely established socket" is, does it mean
> that the SYN,ACK was sent, or the ACK was received back?

I have always thought it meant that the ACK of the SYN|ACK has been 
received.

SyncookiesSent SyncookiesRecv SyncookiesFailed also appear in 
/proc/net/netstat and presumably in netstat -s output.

> Also, from the client side, when is the connect(2) call done? When the
> SYN,ACK is received?

That would be my assumption.


In a previous message:

> What I'm seeing are clients taking either useconds to connect, or 3
> seconds, which suggest SYNs are getting lost, but the network doesn't
> seem to be the problem. I'm still investigating this, so unfortunately
> I'm not really sure.

I recently ran into something like that, which turned-out to be an issue 
with nf_conntrack and its table filling.

rick
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/