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.
prev parent 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).