All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.