netdev - Re: [PATCH] tcp: Fix tcp_max_syn_backlog limit on connection requests

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:   Fri, 03 Jan 2020 15:13:02 +0000
From:   Ttttabcd <ttttabcd@...tonmail.com>
To:     Eric Dumazet <edumazet@...gle.com>
Cc:     Netdev <netdev@...r.kernel.org>,
        David Miller <davem@...emloft.net>,
        "kuznet@....inr.ac.ru" <kuznet@....inr.ac.ru>,
        "yoshfuji@...ux-ipv6.org" <yoshfuji@...ux-ipv6.org>
Subject: Re: [PATCH] tcp: Fix tcp_max_syn_backlog limit on connection requests

> There is a difference though....
>
> Set sysctl_max_syn_backlog to 1, and start a reasonable test (not a synflood)
>
> As soon as one SYN_RECV request socket is inserted in the hash, other
> SYN packets will generate a syncookie, even if the backlog of the
> listener is 100,000
>
> I think the intent of the code is to allow a heavy duty server to use
> a huge backlog (say 1,000,000) to avoid syncookies if it has enough
> RAM.
>
> In this mode, people never had to tweak sysctl_max_syn_backlog.

Your scenario is the same as what I said in the previous email, big backlog, small sysctl_max_syn_backlog.

The question now is whether sysctl_max_syn_backlog should still work after syn cookies are turned on. Does the backlog want to be exhausted or kept unused? Whether to use as much memory as possible or keep it as low as possible.

This is also where I was most confused at first. This is totally inconsistent with ip-sysctl.txt. In some scenarios, sysctl_max_syn_backlog is invalid.

Unless we can find the person who wrote this code, we may not find answers to these questions.

This is, uh ... a problem left over by history, it seems that it can only remain the same.