Re: /proc/net/ip_conntrack trange behavior

[Dong_Wei <Dong_Wei@nj.cpsecure.com>]

Thanks a lot. Yasuyuki and kaber

I have looked the 2.6.20 kernel and found that the reason.

When ip_conntrack try to pick up an ESTABLISHED TCP connection, this 
issue will happen.

2.6 set an 'sysctl' value to deal with this situation

static int tcp_new()
{
	...snip...
          if (new_state == TCP_CONNTRACK_SYN_SENT) {
		do_something();
          } else if (ip_ct_tcp_loose == 0) {
                  /* Don't try to pick up connections. */
                  return 0;
          } else {
		do_something();
          }
}

And we can't avoid this issue on 2.4, because no code deal with the 
special case.

Thanks!

> Yasuyuki KOZAKAI wrote:
>> From: Dong_Wei <Dong_Wei@nj.cpsecure.com>
>> Date: Fri, 24 Aug 2007 15:43:01 +0800
>>
>>> Hi, all
>>>     When I checked /proc/net/ip_conntrack in my Linux server, I found 
>>> some strange tracks like the following:
>>>
>>> [normal case]
>>> tcp      6 387113 ESTABLISHED src=219.135.189.40 dst=58.60.9.41
>>> sport=2391 dport=443 src=58.60.9.41 dst=219.135.189.40 sport=443
>>> dport=2391 [ASSURED] use=1
>>>
>>> [strange track]
>>> tcp      6 377231 ESTABLISHED src=222.173.17.207 dst=219.135.189.11
>>> sport=19691 dport=3815 [UNREPLIED] src=219.135.189.11 dst=222.173.17.207
>>> sport=3815 dport=19691 use=1
>>>
>>> As we kown after SYN->SYN,ACK->ACK. TCP connection is in ESTABLISHED
>>> state. and the ip_conntrack "see" the REPLY direction packet, I think
>>> the conntrak should be ASSURED. not UNREPLIED.
>>>
>>> So, pls help me. My kernel version is 2.4.22
>>>
>>> Thanks in advance  :-)
>>>
>>
>> When only SYN and SYN/ACK are detected by ip_conntrack, the state of the
>> connection is ESTABLISHED. Please note that 'ESTABLISHED' is not TCP 
>> state,
>> but generic connection state.
> 
> 
> Well, its TCP connection state. Whats probably happening is that you
> have connection pickup enabled, in which case a single ACK can lead
> to TCP ESTABLISHED state. It won't match "-m state --state ESTABLISHED"
> though.
>