From: Patrick McHardy <kaber@trash.net>
To: Afi Gjermund <afigjermund@gmail.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>,
Jan Engelhardt <jengelh@medozas.de>,
netfilter-devel@vger.kernel.org
Subject: Re: nf_conntrack_count versus '/proc/net/nf_conntrack | wc -l' count
Date: Thu, 18 Feb 2010 19:19:50 +0100 [thread overview]
Message-ID: <4B7D84C6.2040102@trash.net> (raw)
In-Reply-To: <48ceaa831002181013q46d4d623xcd88f6164a088729@mail.gmail.com>
Afi Gjermund wrote:
> On Thu, Feb 18, 2010 at 10:07 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>>>>> Shouldn't the value after the flush be 0? The traffic that has created
>>>>> this mess is from a REDIRECT rule in the PREROUTING chain of the 'nat'
>>>>> table.
>>>> Could you post a copy of these rules ?
>>>>
>>> iptables -t nat -A PREROUTING -p tcp -s X.X.X.X -d X.X.X.X --sport X
>>> --dport X -j REDIRECT --to-port X
>> Yes I understood you were using such rules, but I cannot understand how
>> it can trigger without real nics being plugged. So I asked you some
>> details, apprently you dont want to provide them and prefer to hide from
>> us :)
>>
> Lol, sorry. The X values are dynamic and depend on what network the
> device happens to be on, as well as the ephemeral source port.
>
> iptables -t nat -A PREROUTING -p tcp -s 172.168.8.45 -d 172.168.8.200
> --sport 4351 --dport 4500 -j REDIRECT --to-port 45001
NAT is unlikely to be the cause since its widely used and there
are no other reports of leaks. Please describe your full setup,
especially things like traffic scheduling, network devices,
userspace queueing etc etc.
next prev parent reply other threads:[~2010-02-18 18:19 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-15 17:27 nf_conntrack_count versus '/proc/net/nf_conntrack | wc -l' count Afi Gjermund
2010-02-15 17:29 ` Patrick McHardy
2010-02-15 17:46 ` Jan Engelhardt
2010-02-15 18:04 ` Afi Gjermund
2010-02-15 19:00 ` Jan Engelhardt
2010-02-15 19:30 ` Afi Gjermund
2010-02-15 19:45 ` Afi Gjermund
2010-02-15 20:04 ` Eric Dumazet
2010-02-15 20:33 ` Jan Engelhardt
2010-02-15 21:08 ` Afi Gjermund
2010-02-15 21:52 ` Eric Dumazet
2010-02-15 22:00 ` Afi Gjermund
2010-02-15 22:02 ` Eric Dumazet
2010-02-15 22:10 ` Afi Gjermund
2010-02-18 17:40 ` Afi Gjermund
2010-02-18 17:51 ` Eric Dumazet
2010-02-18 17:55 ` Afi Gjermund
2010-02-18 18:07 ` Eric Dumazet
2010-02-18 18:13 ` Afi Gjermund
2010-02-18 18:19 ` Patrick McHardy [this message]
2010-02-18 19:39 ` Afi Gjermund
2010-02-19 0:53 ` Afi Gjermund
2010-02-19 14:12 ` Eric Dumazet
2010-02-19 14:29 ` Patrick McHardy
2010-02-18 18:12 ` Douglas Diniz
2010-02-18 18:22 ` Patrick McHardy
2010-02-18 18:35 ` Douglas Diniz
2010-02-15 21:17 ` Eric Dumazet
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=4B7D84C6.2040102@trash.net \
--to=kaber@trash.net \
--cc=afigjermund@gmail.com \
--cc=eric.dumazet@gmail.com \
--cc=jengelh@medozas.de \
--cc=netfilter-devel@vger.kernel.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.