netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Rui Sousa <rui.p.m.sousa@gmail.com>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: [PATCH] conntrack event missing TCP protoinfo
Date: Tue, 05 Jan 2010 21:39:42 +0100	[thread overview]
Message-ID: <4B43A38E.4010104@netfilter.org> (raw)
In-Reply-To: <4B4390B0.7090009@netfilter.org>

Pablo Neira Ayuso wrote:
> Rui Sousa wrote:
>> I believe so, but I having a hard time understanding what I'm seeing.
>> AFAICT, I'm exercising the state transition sNo->sES->sES, my 
>> procedure is:
>>
>> PC1 -> linux router -> PC2
>>
>> 1. establish TCP connection between two PC's (using iperf). PC1 is the 
>> client, PC2 is the server.
>> 2. On the router, ifdown of output interface (the interface on PC2 side)
>> 3. On the router, manual destroy of connection in kernel
>> 4. On the router, ifup of output interface
>> 5. wait for iperf to start sending packets again. The connection 
>> between the endpoints is always established.
>>
>> Between 3 and 4 I receive a NFCT_DESTROY event (from 
>> libnetfilter_conntrack).
>> During 5. I get two events, both NFCT_UPDATEs, the first with 
>> conntrack status CONFIRMED/SEEN_REPLY, the second with conntrack 
>> status ASSURED. Both are missing the TCP protoinfo. In this is my 
>> problem, the kernel correctly picked up the on going TCP connection 
>> but never sends enough information to userspace about it.
> 
> Good analysis. Since Linux kernel 2.6.30, you should see a NFCT_NEW 
> event (for conntracks that have been created via ctnetlink) before you 
> get the two NFCT_UPDATE events. The NFCT_NEW contains the TCP protocol 
> state.

Oh, I read your email badly, sorry. Your using the pickup facility of 
the TCP tracking.

I cannot reproduce the problem following your steps, I'm using conntrack 
-F, the loopback device and some netcat commands:

[DESTROY] tcp      6 src=127.0.0.1 dst=127.0.0.1 sport=58383 dport=8000 
packets=2 bytes=112 src=127.0.0.1 dst=127.0.0.1 sport=8000 dport=58383 
packets=1 bytes=60 [ASSURED]
  [NEW] tcp      6 432000 ESTABLISHED src=127.0.0.1 dst=127.0.0.1 
sport=58383 dport=8000 [UNREPLIED] src=127.0.0.1 dst=127.0.0.1 
sport=8000 dport=58383
  [UPDATE] tcp      6 432000 src=127.0.0.1 dst=127.0.0.1 sport=58383 
dport=8000 src=127.0.0.1 dst=127.0.0.1 sport=8000 dport=58383
  [UPDATE] tcp      6 300 src=127.0.0.1 dst=127.0.0.1 sport=58383 
dport=8000 src=127.0.0.1 dst=127.0.0.1 sport=8000 dport=58383 [ASSURED]

I'm using a git snapshot from the current Linux kernel development version.

      reply	other threads:[~2010-01-05 20:39 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-31 13:03 [PATCH] conntrack event missing TCP protoinfo Rui Sousa
2009-12-31 18:09 ` Pablo Neira Ayuso
2010-01-04 18:03   ` Rui Sousa
2010-01-05 19:19     ` Pablo Neira Ayuso
2010-01-05 20:39       ` Pablo Neira Ayuso [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B43A38E.4010104@netfilter.org \
    --to=pablo@netfilter.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=rui.p.m.sousa@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).