From: Patrick McHardy <kaber@trash.net>
To: Harald Welte <laforge@netfilter.org>
Cc: Bart De Schuymer <bdschuym@telenet.be>,
Bart De Schuymer <bdschuym@pandora.be>,
Herbert Xu <herbert@gondor.apana.org.au>,
netfilter-devel@lists.netfilter.org,
linux-kernel@vger.kernel.org, rankincj@yahoo.com,
ebtables-devel@lists.sourceforge.net, netfilter-devel@manty.net
Subject: Re: 2.6.12: connection tracking broken?
Date: Mon, 27 Jun 2005 13:46:46 +0200 [thread overview]
Message-ID: <42BFE726.20305@trash.net> (raw)
In-Reply-To: <20050627083219.GZ19928@sunbeam.de.gnumonks.org>
Harald Welte wrote:
> I have to agree with Bart. I don't know any bridging-packetfilter setup
> that doesn't use ipt_physdev in FORWARD :(
It shouldn't be a problem to MARK in ebtables and use the marks instead.
So far I think we can only remove the support for locally generated
packets, but the way bridge-netfilter and ip-netfilter interact causes
some more problems and inconsistencies which I would like to look into
first. One thing I've noticed is that NF_IP_LOCAL_OUT, NF_IP_FORWARD and
NF_IP_POST_ROUTING get called for every clone when packets are delivered
to multiple ports, which causes unexpected results with REJECT (many
packets sent in response to a single one) and probably others. This
could be avoided by only passing packets to the NF_IP_* hooks once, but
that would make the physdev match useless.
Another problem is defragmentation, we've added the user argument to
ip_defrag to avoid packets from jumping through the stack between
different callers. With bridge-netfilter defragmentation in
NF_IP_PRE_ROUTING can be reached from both the IP layer and the bridge
layer, so packets can still jump (see netfilter bugzilla #339).
I expect there are more problems, I hope I can find some time to look
into it this week.
Regards
Patrick
WARNING: multiple messages have this Message-ID (diff)
From: Patrick McHardy <kaber@trash.net>
To: Harald Welte <laforge@netfilter.org>
Cc: Bart De Schuymer <bdschuym@pandora.be>,
Herbert Xu <herbert@gondor.apana.org.au>,
Bart De Schuymer <bdschuym@telenet.be>,
netfilter-devel@manty.net, netfilter-devel@lists.netfilter.org,
linux-kernel@vger.kernel.org,
ebtables-devel@lists.sourceforge.net, rankincj@yahoo.com
Subject: Re: 2.6.12: connection tracking broken?
Date: Mon, 27 Jun 2005 13:46:46 +0200 [thread overview]
Message-ID: <42BFE726.20305@trash.net> (raw)
In-Reply-To: <20050627083219.GZ19928@sunbeam.de.gnumonks.org>
Harald Welte wrote:
> I have to agree with Bart. I don't know any bridging-packetfilter setup
> that doesn't use ipt_physdev in FORWARD :(
It shouldn't be a problem to MARK in ebtables and use the marks instead.
So far I think we can only remove the support for locally generated
packets, but the way bridge-netfilter and ip-netfilter interact causes
some more problems and inconsistencies which I would like to look into
first. One thing I've noticed is that NF_IP_LOCAL_OUT, NF_IP_FORWARD and
NF_IP_POST_ROUTING get called for every clone when packets are delivered
to multiple ports, which causes unexpected results with REJECT (many
packets sent in response to a single one) and probably others. This
could be avoided by only passing packets to the NF_IP_* hooks once, but
that would make the physdev match useless.
Another problem is defragmentation, we've added the user argument to
ip_defrag to avoid packets from jumping through the stack between
different callers. With bridge-netfilter defragmentation in
NF_IP_PRE_ROUTING can be reached from both the IP layer and the bridge
layer, so packets can still jump (see netfilter bugzilla #339).
I expect there are more problems, I hope I can find some time to look
into it this week.
Regards
Patrick
next prev parent reply other threads:[~2005-06-27 11:46 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-18 12:43 2.6.12: connection tracking broken? Chris Rankin
2005-06-18 14:57 ` Jan Engelhardt
2005-06-18 15:14 ` Tobias DiPasquale
2005-06-18 17:16 ` Chris Rankin
2005-06-20 7:19 ` Harald Welte
2005-06-20 7:19 ` Harald Welte
2005-06-18 19:25 ` Santiago Garcia Mantinan
2005-06-18 22:12 ` Santiago Garcia Mantinan
2005-06-19 13:05 ` Patrick McHardy
2005-06-19 13:05 ` Patrick McHardy
2005-06-20 0:05 ` Herbert Xu
2005-06-20 0:05 ` Herbert Xu
2005-06-20 0:18 ` David S. Miller
2005-06-20 0:18 ` David S. Miller
2005-06-20 0:50 ` Herbert Xu
2005-06-20 0:50 ` Herbert Xu
2005-06-20 2:45 ` Patrick McHardy
2005-06-20 2:45 ` Patrick McHardy
2005-06-20 6:39 ` Bart De Schuymer
2005-06-20 12:15 ` Patrick McHardy
2005-06-20 12:15 ` Patrick McHardy
2005-06-20 18:46 ` Bart De Schuymer
2005-06-20 18:46 ` Bart De Schuymer
2005-06-20 18:57 ` Phil Oester
2005-06-20 18:57 ` Phil Oester
2005-06-20 23:27 ` Patrick McHardy
2005-06-20 23:27 ` Patrick McHardy
2005-06-20 23:22 ` Patrick McHardy
2005-06-20 23:22 ` Patrick McHardy
2005-06-21 7:19 ` Bart De Schuymer
2005-06-21 7:19 ` Bart De Schuymer
2005-06-21 15:16 ` Patrick McHardy
2005-06-21 15:16 ` Patrick McHardy
[not found] ` <42B82F35.3040909-dcUjhNyLwpNeoWH0uzbU5w@public.gmane.org>
2005-06-21 20:46 ` Bart De Schuymer
2005-06-21 20:46 ` Bart De Schuymer
2005-06-21 21:23 ` Chris Wright
2005-06-21 22:32 ` David S. Miller
2005-06-21 22:34 ` Chris Wright
2005-06-22 0:26 ` Patrick McHardy
2005-06-22 22:58 ` Chris Rankin
2005-06-23 17:42 ` Patrick McHardy
2005-06-23 19:49 ` David S. Miller
2005-06-24 8:39 ` Patrick McHardy
2005-06-28 23:07 ` David S. Miller
2005-06-22 0:45 ` Patrick McHardy
2005-06-22 0:45 ` Patrick McHardy
2005-06-22 21:49 ` Herbert Xu
2005-06-22 21:49 ` Herbert Xu
2005-06-23 0:02 ` Carl-Daniel Hailfinger
2005-06-23 0:02 ` Carl-Daniel Hailfinger
2005-06-23 3:31 ` Patrick McHardy
2005-06-23 3:31 ` Patrick McHardy
2005-06-23 6:27 ` [Ebtables-devel] " Bart De Schuymer
2005-06-23 6:27 ` Bart De Schuymer
2005-06-23 3:26 ` Patrick McHardy
2005-06-23 3:26 ` Patrick McHardy
2005-06-23 3:53 ` Herbert Xu
2005-06-23 3:53 ` Herbert Xu
2005-06-23 6:23 ` Bart De Schuymer
2005-06-23 6:23 ` Bart De Schuymer
2005-06-27 8:32 ` Harald Welte
2005-06-27 8:32 ` Harald Welte
2005-06-27 11:46 ` Patrick McHardy [this message]
2005-06-27 11:46 ` Patrick McHardy
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=42BFE726.20305@trash.net \
--to=kaber@trash.net \
--cc=bdschuym@pandora.be \
--cc=bdschuym@telenet.be \
--cc=ebtables-devel@lists.sourceforge.net \
--cc=herbert@gondor.apana.org.au \
--cc=laforge@netfilter.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netfilter-devel@lists.netfilter.org \
--cc=netfilter-devel@manty.net \
--cc=rankincj@yahoo.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 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.