When is a child socket created on a receiving side during a 3wh process, given syncookies are not used?

[Вадим Самохин]

That's the main question. But in order for a reply would be meaningful for
me, there are several other questions I should ask. So, here is a bit more
detailed version: what I've found out about a 3wh so far, and questions
left along the way.

When a client initiates a 3wh, it sends a syn packet to the server. There,
the TCP layer’s entrypoint is a tcp_v4_rcv
<https://github.com/torvalds/linux/blob/4d6d4c7f541d7027beed4fb86eb2c451bd8d6fff/net/ipv4/tcp_ipv4.c#L1975>
[1] procedure. When a packet is received, a listening socket is looked up
<https://github.com/torvalds/linux/blob/4d6d4c7f541d7027beed4fb86eb2c451bd8d6fff/net/ipv4/tcp_ipv4.c#L2017>
[2]. If it’s found, I guess its state is
<https://github.com/torvalds/linux/blob/4d6d4c7f541d7027beed4fb86eb2c451bd8d6fff/net/ipv4/tcp_ipv4.c#L2132>
TCP_LISTEN
<https://github.com/torvalds/linux/blob/4d6d4c7f541d7027beed4fb86eb2c451bd8d6fff/net/ipv4/tcp_ipv4.c#L2132>
[3]. Through a tcp_v4_do_rcv()
<https://github.com/torvalds/linux/blob/4d6d4c7f541d7027beed4fb86eb2c451bd8d6fff/net/ipv4/tcp_ipv4.c#L2133>
[4] helper procedure, we reach tcp_rcv_state_process()
<https://github.com/torvalds/linux/blob/4d6d4c7f541d7027beed4fb86eb2c451bd8d6fff/net/ipv4/tcp_ipv4.c#L1744>
[5]. There, I think I fall into this clause [6]. Then, through a
tcp_v4_conn_request()[7] procedure I find myself in tcp_conn_request() [8].
I'm interested in a case when syncookies are not used, so the want_cookie
variable remains false. A request socket is created [9]. Its ireq_state is
TCP_NEW_SYN_RECV [10], a listener socket is attached [11] and a syn-packet
saved [12]. Finally, a request_sock is added in a "queue" (which is a
hash-table actually) [13] and a syn-ack is sent [14]. So, for now I have no
evidence that a child socket is created on a syn-packet-processing stage.

Then, a client sends an ack. As on a syn processing step, a socket is
looked up. From what I've seen, this socket is still a listening socket.
But, there is a clause checking whether sk->sk_state == TCP_NEW_SYN_RECV
[15]. I've looked for places where this state is set and all I could find
was a request_sock ireq_state is set to TCP_NEW_SYN_RECV during a syn
packet processing. So, does __inet_lookup_skb procedure return a
request_sock created on a syn processing step, wrapped into some sock
struct? If not, what does it return, a listening socket? If yes, does it
really have a state TCP_NEW_SYN_RECV?! I haven't found anywhere that a
listening socket status can be TCP_NEW_SYN_RECV. However, I'm inclined to
believe that this if-clause is what I'm looking for, since a tcp_check_req
[16] invoked there creates a child socket by cloning a listening socket
[17], [18]. And if that's the case, I don't understand what tcp_filter does
and why it returns a non-zero code.

If that if-clause is not executed, I guess I will find myself in
tcp_v4_do_rcv again. There, a synsookie is checked, and if there is one, a
listening socket is cloned. [19] [20] Procedure tcp_get_cookie_sock() does
it the same way as in a previous paragraph [17], [18].

But my case is that there are no syncookies. So I end up in an
tcp_rcv_state_process(), a listening socket state is TCP_LISTEN, and in
case of an ack packet, this procedure simply returns[21].

So, what am I missing? Any clues, any thoughts?

[1]
https://github.com/torvalds/linux/blob/4d6d4c7f541d7027beed4fb86eb2c451bd8d6fff/net/ipv4/tcp_ipv4.c#L1975

[2]
https://github.com/torvalds/linux/blob/4d6d4c7f541d7027beed4fb86eb2c451bd8d6fff/net/ipv4/tcp_ipv4.c#L2017

[3]
https://github.com/torvalds/linux/blob/4d6d4c7f541d7027beed4fb86eb2c451bd8d6fff/net/ipv4/tcp_ipv4.c#L2132

[4]
https://github.com/torvalds/linux/blob/4d6d4c7f541d7027beed4fb86eb2c451bd8d6fff/net/ipv4/tcp_ipv4.c#L2133

[5]
https://github.com/torvalds/linux/blob/4d6d4c7f541d7027beed4fb86eb2c451bd8d6fff/net/ipv4/tcp_ipv4.c#L1744

[6]
https://github.com/torvalds/linux/blob/4d6d4c7f541d7027beed4fb86eb2c451bd8d6fff/net/ipv4/tcp_input.c#L6478

[7]
https://github.com/torvalds/linux/blob/4d6d4c7f541d7027beed4fb86eb2c451bd8d6fff/net/ipv4/tcp_ipv4.c#L1529

[8]
https://github.com/torvalds/linux/blob/4d6d4c7f541d7027beed4fb86eb2c451bd8d6fff/net/ipv4/tcp_input.c#L6924

[9]
https://github.com/torvalds/linux/blob/4d6d4c7f541d7027beed4fb86eb2c451bd8d6fff/net/ipv4/tcp_input.c#L6957

[10]
https://github.com/torvalds/linux/blob/4d6d4c7f541d7027beed4fb86eb2c451bd8d6fff/net/ipv4/tcp_input.c#L6815

[11]
https://github.com/torvalds/linux/blob/4d6d4c7f541d7027beed4fb86eb2c451bd8d6fff/include/net/request_sock.h#L101

[12]
https://github.com/torvalds/linux/blob/4d6d4c7f541d7027beed4fb86eb2c451bd8d6fff/net/ipv4/tcp_input.c#L7031

[13]
https://github.com/torvalds/linux/blob/4d6d4c7f541d7027beed4fb86eb2c451bd8d6fff/net/ipv4/tcp_input.c#L7051

[14]
https://github.com/torvalds/linux/blob/4d6d4c7f541d7027beed4fb86eb2c451bd8d6fff/net/ipv4/tcp_input.c#L7053

[15]
https://github.com/torvalds/linux/blob/4d6d4c7f541d7027beed4fb86eb2c451bd8d6fff/net/ipv4/tcp_ipv4.c#L2027

[16]
https://github.com/torvalds/linux/blob/4d6d4c7f541d7027beed4fb86eb2c451bd8d6fff/net/ipv4/tcp_ipv4.c#L2070

[17]
https://github.com/torvalds/linux/blob/4d6d4c7f541d7027beed4fb86eb2c451bd8d6fff/net/ipv4/tcp_minisocks.c#L807

[18]
https://github.com/torvalds/linux/blob/4d6d4c7f541d7027beed4fb86eb2c451bd8d6fff/net/ipv4/tcp_ipv4.c#L1570

[19]
https://github.com/torvalds/linux/blob/4d6d4c7f541d7027beed4fb86eb2c451bd8d6fff/net/ipv4/tcp_ipv4.c#L1730

[20]
https://github.com/torvalds/linux/blob/4d6d4c7f541d7027beed4fb86eb2c451bd8d6fff/net/ipv4/syncookies.c#L448

[21]
https://github.com/torvalds/linux/blob/4d6d4c7f541d7027beed4fb86eb2c451bd8d6fff/net/ipv4/tcp_input.c#L6472
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20230522/b8b06a32/attachment.html>