netdev - Re: net.ipv4.tcp_max_syn_backlog implementation

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Tue, 29 Aug 2017 09:17:10 -0700
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     Harsha Chenji <cjkernel@...il.com>
Cc:     netdev@...r.kernel.org
Subject: Re: net.ipv4.tcp_max_syn_backlog implementation

On Tue, 2017-08-29 at 11:05 -0400, Harsha Chenji wrote:
> According to the man:
> 
> The behavior of the backlog argument on TCP sockets changed with Linux
> 2.2. Now it specifies the queue length for *completely established
> sockets waiting to be accepted*, instead of the number of incomplete
> connection requests. The maximum length of the queue for incomplete
> sockets can be set using /proc/sys/net/ipv4/tcp_max_syn_backlog. When
> syncookies are enabled there is no logical maximum length and this
> setting is ignored. See tcp(7) for more information.
> 
> 


The sysctl was simply there to make sure that someone would not :

listen(fd, 0x40000000);

It served to cap the 2nd argument of listen() to something that the
admin considered as acceptable.

This was particularly important few years back when handling of SYN_RECV
sockets involved O(N) behavior for SYNACK retransmits.

Nowadays, a backlog of 10,000,000 is okay, if you have ram to spend on
it.

> On Tue, Aug 29, 2017 at 12:17 AM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> > On Mon, 2017-08-28 at 23:47 -0400, Harsha Chenji wrote:
> >> So I have ubuntu 12.04 x32 in a VM with syncookies turned off. I tried
> >> to do a syn flood (with netwox) on 3 different processes. Each of them
> >> returns a different value with netstat -na | grep -c RECV :
> >>
> >> nc -l 5555 returns 16 (netcat-traditional)
> >> apache2 port 80 returns 256
> >> vsftpd on 21 returns 64.
> >> net.ipv4.tcp_max_syn_backlog is 512.
> >>
> >> Why do these different processes on different ports have different
> >> queue lengths for incomplete connections? Where exactly in the kernel
> >> is this decided?
> >
> > See 2nd argument in listen() system call, ie backlog
> >
> > man listen
> >
> > Without a synflood, just look at "ss -t state listening"
> >
> > The backlog is the 2nd column (Send)
> >
> >
> >