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 [1] procedure. When a packet is received, a listening socket is looked up [2]. If it’s found, I guess its state is TCP_LISTEN [3]. Through a tcp_v4_do_rcv() [4] helper procedure, we reach tcp_rcv_state_process() [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?
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
