From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ttttabcd Subject: Re: Why not use all the syn queues? in the function "tcp_conn_request", I have some questions. Date: Wed, 05 Sep 2018 00:20:25 +0000 Message-ID: References: <47NgfBCN4YlW5rstCQGVJicSQ3yqiWFZpYPuBnmE1Jer0vxuBffWYbZzM2VmkeNNdk8gFgnMYo5T1fODpWGiRKnElyAY7bUmS_r-Z-SSaf4=@protonmail.com> Reply-To: Ttttabcd Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Netdev To: Neal Cardwell Return-path: Received: from mail-40133.protonmail.ch ([185.70.40.133]:62389 "EHLO mail-40133.protonmail.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725822AbeIEEsH (ORCPT ); Wed, 5 Sep 2018 00:48:07 -0400 In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: Sent with ProtonMail Secure Email. =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On 4 September 2018 9:06 PM, Neal Cardwell wrote: > On Tue, Sep 4, 2018 at 1:48 AM Ttttabcd ttttabcd@protonmail.com wrote: > > > Hello everyone,recently I am looking at the source code for handling TC= P three-way handshake(Linux Kernel version 4.18.5). > > I found some strange places in the source code for handling syn message= s. > > in the function "tcp_conn_request" > > This code will be executed when we don't enable the syn cookies. > > > > if (!net->ipv4.sysctl_tcp_syncookies && > > (net->ipv4.sysctl_max_syn_backlog - inet_csk_reqsk_= queue_len(sk) < > > (net->ipv4.sysctl_max_syn_backlog >> 2)) && > > !tcp_peer_is_proven(req, dst)) { > > /* Without syncookies last quarter of > > * backlog is filled with destinations, > > * proven to be alive. > > * It means that we continue to communicate > > * to destinations, already remembered > > * to the moment of synflood. > > */ > > pr_drop_req(req, ntohs(tcp_hdr(skb)->source), > > rsk_ops->family); > > goto drop_and_release; > > } > > > > > > But why don't we use all the syn queues? > > If tcp_peer_is_proven() returns true then we do allow ourselves to use > the whole queue. > > > Why do we need to leave the size of (net->ipv4.sysctl_max_syn_backlog >= > 2) in the queue? > > Even if the system is attacked by a syn flood, there is no need to leav= e a part. Why do we need to leave a part? > > The comment describes the rationale. If syncookies are disabled, then > the last quarter of the backlog is reserved for filling with > destinations that were proven to be alive, according to > tcp_peer_is_proven() (which uses RTTs measured in previous > connections). The idea is that if there is a SYN flood, we do not want > to use all of our queue budget on attack traffic but instead want to > reserve some queue space for SYNs from real remote machines that we > have actually contacted in the past. > > > The value of sysctl_max_syn_backlog is the maximum length of the queue = only if syn cookies are enabled. > > Even if syncookies are disabled, sysctl_max_syn_backlog is the maximum > length of the queue. > > > This is the first strange place, here is another strange place > > > > __u32 isn =3D TCP_SKB_CB(skb)->tcp_tw_isn; > > > > if ((net->ipv4.sysctl_tcp_syncookies =3D=3D 2 || > > inet_csk_reqsk_queue_is_full(sk)) && !isn) { > > > > if (!want_cookie && !isn) { > > > > > > The value of "isn" comes from TCP_SKB_CB(skb)->tcp_tw_isn, then it is j= udged twice whether its value is indeed 0. > > But "tcp_tw_isn" is initialized in the function "tcp_v4_fill_cb" > > > > TCP_SKB_CB(skb)->tcp_tw_isn =3D 0; > > > > > > So it has always been 0, I used printk to test, and the result is alway= s 0. > > That field is also set in tcp_timewait_state_process(): > > TCP_SKB_CB(skb)->tcp_tw_isn =3D isn; > > So there can be cases where it is not 0. > > Hope that helps, > neal Thank you very much, I understand