Question about tcp reopen in tcp_in_window

Question about tcp reopen in tcp_in_window

[Gao feng]

Hi

I has a question about the tcp reopen request in func tcp_in_window.
The code is below,what confuse me is that the var end is never after sender->td_end.

static int tcp_in_window(struct ip_ct_tcp *state,
		...
	if (sender->td_end == 0) {
		...
	} else if (((state->state == TCP_CONNTRACK_SYN_SENT
                     && dir == IP_CT_DIR_ORIGINAL)
                   || (state->state == TCP_CONNTRACK_SYN_RECV
                     && dir == IP_CT_DIR_REPLY))
                   && after(end, sender->td_end)) {

		...
	}
		...
}


When nf_conn rcv a syn request in TIME_WAIT state,the new_state is SYN_SNET.
in func tcp_packet, this nf_conn will be kill by nf_ct_kill and the syn packet will repeat.
So we will have a new nf_conn,whose sender->td_end is reset in func tcp_new.

finally,when this syn packet arrive tcp_in_window,the var end is equal to sender->td_end.

Maybe there is the other situation Or what I understand is totally wrong?

Re: Question about tcp reopen in tcp_in_window

[Jozsef Kadlecsik]

On Thu, 17 Nov 2011, Gao feng wrote:

> I has a question about the tcp reopen request in func tcp_in_window.
> The code is below,what confuse me is that the var end is never after sender->td_end.
> 
> static int tcp_in_window(struct ip_ct_tcp *state,
> 		...
> 	if (sender->td_end == 0) {
> 		...
> 	} else if (((state->state == TCP_CONNTRACK_SYN_SENT
>                      && dir == IP_CT_DIR_ORIGINAL)
>                    || (state->state == TCP_CONNTRACK_SYN_RECV
>                      && dir == IP_CT_DIR_REPLY))
>                    && after(end, sender->td_end)) {
> 
> 		...
> 	}
> 		...
> }
> 
> 
> When nf_conn rcv a syn request in TIME_WAIT state,the new_state is SYN_SNET.
> in func tcp_packet, this nf_conn will be kill by nf_ct_kill and the syn packet will repeat.

No, the connection entry won't be destroyed by nf_ct_kill. Why do you 
think so?

> So we will have a new nf_conn,whose sender->td_end is reset in func tcp_new.
> 
> finally,when this syn packet arrive tcp_in_window,the var end is equal to sender->td_end.
> 
> Maybe there is the other situation Or what I understand is totally wrong?

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: Question about tcp reopen in tcp_in_window

[Gao feng]

于 2011年11月17日 16:07, Jozsef Kadlecsik 写道:
> No, the connection entry won't be destroyed by nf_ct_kill. Why do you 
> think so?
> 

Thanks Jozsef Kadlecsik.
nf_ct will be destroy when tcp_packet return -NF_REPEAT to nf_conntrack_in.
nf_conntrack_in will call nf_conntrack_put to destroy nf_conn
nf_conntrack_in:

	ret = l4proto->packet(ct, skb, dataoff, ctinfo, pf, hooknum);
        if (ret <= 0) {
                /* Invalid: inverse of the return code tells
                 * the netfilter core what to do */
                pr_debug("nf_conntrack_in: Can't track with proto module\n");
                nf_conntrack_put(skb->nfct);
                skb->nfct = NULL;
                NF_CT_STAT_INC_ATOMIC(net, invalid);
                if (ret == -NF_DROP)
                        NF_CT_STAT_INC_ATOMIC(net, drop);
                return -ret;
        }

I am wrong?
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Question about tcp reopen in tcp_in_window

[Jozsef Kadlecsik]

On Thu, 17 Nov 2011, Gao feng wrote:

> ? 2011?11?17? 16:07, Jozsef Kadlecsik ??:
> > No, the connection entry won't be destroyed by nf_ct_kill. Why do you 
> > think so?
> 
> nf_ct will be destroy when tcp_packet return -NF_REPEAT to nf_conntrack_in.
> nf_conntrack_in will call nf_conntrack_put to destroy nf_conn
> nf_conntrack_in:
> 
> 	ret = l4proto->packet(ct, skb, dataoff, ctinfo, pf, hooknum);
>         if (ret <= 0) {
>                 /* Invalid: inverse of the return code tells
>                  * the netfilter core what to do */
>                 pr_debug("nf_conntrack_in: Can't track with proto module\n");
>                 nf_conntrack_put(skb->nfct);
>                 skb->nfct = NULL;
>                 NF_CT_STAT_INC_ATOMIC(net, invalid);
>                 if (ret == -NF_DROP)
>                         NF_CT_STAT_INC_ATOMIC(net, drop);
>                 return -ret;
>         }
> 
> I am wrong?

No, but I still don't get what's the problem with the code segment you 
cited. You left out the comment:

        } else if (((state->state == TCP_CONNTRACK_SYN_SENT
                     && dir == IP_CT_DIR_ORIGINAL)
                   || (state->state == TCP_CONNTRACK_SYN_RECV
                     && dir == IP_CT_DIR_REPLY))
                   && after(end, sender->td_end)) {
                /*
                 * RFC 793: "if a TCP is reinitialized ... then it need
                 * not wait at all; it must only be sure to use sequence
                 * numbers larger than those recently used."
                 */

This is the reinitialization case in the SYN_SENT and SYN_RECV states.

We destroy the connection in the reopen case, and in that path the code 
segment above won't be called as you noticed.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: Question about tcp reopen in tcp_in_window

[Gao feng]

于 2011年11月17日 17:41, Jozsef Kadlecsik 写道:
> No, but I still don't get what's the problem with the code segment you 
> cited. You left out the comment:

Thanks Jozsef Kadlecsik.
Actually there is no any problem,I just want to know wath's the use of this code segment.

> We destroy the connection in the reopen case, and in that path the code 
> segment above won't be called as you noticed.

Maybe there is the other path?
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html