From: Pablo Neira <pablo@eurodev.net>
To: Amin Azez <azez@ufomechanic.net>
Cc: netfilter-devel@lists.netfilter.org
Subject: Re: nfnetlink/ctnetlink from pom-ng r3884
Date: Thu, 21 Apr 2005 00:44:10 +0200 [thread overview]
Message-ID: <4266DB3A.8060106@eurodev.net> (raw)
In-Reply-To: <42665BF9.9090707@ufomechanic.net>
Amin Azez wrote:
> I'm using now kernel 2.6.11.7 with nfnetlink, ctnetlink,
> conntrack-event-api from patch-o-matic-ng svn (3884)
>
> I'm using conntrack (3880) and libctnetlink (3877) and libnfnetlink
> (3876) from svn.
Plus the three patches that I posted recently that fix:
a) core dump when a packet of a not know protocol is received.
b) core dump when you receive a destroy message.
c) fail if ip_queue is loaded.
Make sure that you install the libraries correctly and you aren't using
the old ones, this is *very* important.
> I fixed conntrack to remove the "id" parameter, I also have
> CONFIG_IP_NF_CT_ACCT=y
>
> Yet conntrack -E conntrack shows for every packet a new connection
> type: [NEW] src=192.168.0.204 dst=192.168.0.131 sport=41605 ...
> type: [NEW] src=192.168.0.204 dst=192.168.0.131 sport=41605 ...
> type: [NEW] src=192.168.0.204 dst=192.168.0.131 sport=41605 ...
> type: [NEW] src=192.168.0.204 dst=192.168.0.131 sport=41605 ...
> type: [NEW] src=192.168.0.204 dst=192.168.0.131 sport=41605 ...
> type: [NEW] src=192.168.0.204 dst=192.168.0.131 sport=41605 ...
I'm not able to reproduce such behaviour. It works just fine here. Make
sure that you are really using the lastest version. In such case, send
me in private a tcpdump trace and the full list of event displayed.
> I'm also still getting some kind of "alignment" problems in
> ip_conntrack_netlink.c such that original-bytes is 0 and reply-packets
> seems to have the value for originating bytes.
>
> printk("OP=%ld OB=%ld RP=%ld RB=%ld\n",
> ct->counters[IP_CT_DIR_ORIGINAL].packets,
> ct->counters[IP_CT_DIR_ORIGINAL].bytes,
> ct->counters[IP_CT_DIR_REPLY].packets,
> ct->counters[IP_CT_DIR_REPLY].bytes);
>
> OP=1 OB=0 RP=60 RB=0
> OP=1 OB=0 RP=60 RB=0
> OP=2 OB=0 RP=112 RB=0
> OP=2 OB=0 RP=112 RB=0
> OP=3 OB=0 RP=164 RB=0
> OP=4 OB=0 RP=238 RB=0
> OP=4 OB=0 RP=238 RB=0
> OP=5 OB=0 RP=930 RB=0
> OP=5 OB=0 RP=930 RB=0
> OP=5 OB=0 RP=930 RB=0
> OP=6 OB=0 RP=1006 RB=0
> OP=6 OB=0 RP=1006 RB=0
>
> I even put my debug in ctnetlink_conntrack_event() and it prints these
> bogus values, and yet I can't see how this canbe the case unless the
> kernel is walking all over the ip_conntrack struct, but then the box
> wouldn't be this stable.
They aren't bogus, actually you see snapshots of the counters value in
every event message.
See that we don't send a netlink message to user space every time a
packet is received, instead we do when the state of a conntrack changes.
So this is not a bug, it's a feature. As soon as I get some spare time
I'll write the proper documentation and a manpage. Alternatively I'll
appreciate if you could start writing it.
Then, to see the current value of counters use: conntrack -L conntrack
> All I can think of is to
> 1) do binary dump of ip_conntrack
if you're planning cat'ing from /proc/net/ip_conntrack, you must know
that it harm system performance. You've been warned.
--
Pablo
next prev parent reply other threads:[~2005-04-20 22:44 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-19 13:37 nfnetlink/ctnetlink from pom-ng r3884 Wang Jian
2005-04-20 0:55 ` Pablo Neira
2005-04-21 8:21 ` Wang Jian
2005-04-21 11:05 ` Pablo Neira
2005-04-21 11:29 ` Wang Jian
2005-04-20 13:41 ` Amin Azez
2005-04-20 14:17 ` Samuel Liddicott
2005-04-20 22:44 ` Pablo Neira [this message]
2005-04-21 8:07 ` Amin Azez
2005-04-21 9:25 ` extending conntrack event data Amin Azez
2005-04-21 9:49 ` Amin Azez
2005-04-21 10:14 ` Wang Jian
2005-04-21 11:04 ` Pablo Neira
2005-04-25 13:51 ` Amin Azez
2005-04-25 16:35 ` IPCT_NEW comes from was " Amin Azez
2005-04-25 16:43 ` Amin Azez
2005-04-26 13:37 ` BUG/CONFLICT conntrack with preroute/postroute mangle table Samuel Liddicott
2005-04-26 13:38 ` Amin Azez
2005-05-05 11:08 ` Amin Azez
2005-05-05 13:36 ` RFC for fix? Was " Amin Azez
2005-05-05 16:05 ` Pablo Neira
2005-05-09 11:11 ` Amin Azez
2005-05-09 13:48 ` Amin Azez
2005-04-21 11:04 ` extending conntrack event data Amin Azez
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=4266DB3A.8060106@eurodev.net \
--to=pablo@eurodev.net \
--cc=azez@ufomechanic.net \
--cc=netfilter-devel@lists.netfilter.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.