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]
Message-ID: <PbX3K1VwmnXGjijzAWo4F8xM4ZXJGtJCToVeCPBMoSYUBt_fJsoRB4a0pbyzVmr5OVe8sixuCcfBidoJLsW3kLXNonFrjABvMOXSTjmV_y4=@protonmail.com>
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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ