From: Patrick McHardy <kaber@trash.net>
To: "bdschuym@pandora.be" <bdschuym@telenet.be>
Cc: ron lai <ronlai@cs.stanford.edu>,
netfilter@vger.kernel.org, netfilter-devel@vger.kernel.org,
Bart De Schuymer <bdschuym@pandora.be>
Subject: Re: Fw: Problems with nf_nat_ftp.ko and nf_conntrack_ftp.ko in 2.6.22.6
Date: Wed, 07 Nov 2007 12:55:21 +0100 [thread overview]
Message-ID: <4731A7A9.1050606@trash.net> (raw)
In-Reply-To: <W352381485970601194435879@nocme1bl6.telenet-ops.be>
[-- Attachment #1: Type: text/plain, Size: 1461 bytes --]
bdschuym@pandora.be wrote:
>> Patrick McHardy wrote:
>> I can reproduce this with forwarding between two bridges.
>> The reason is that skb->nf_bridge still contains the data
>>from the first bridge and so br_netfilter thinks this is
>> a bridged packet. I don't know how this is supposed to work,
>> but it seems to me that on packets going out a bridge device
>> this should be reset in case it originates from a different
>> bridge (actually I think it should be reset unconditionally
>> but that would probably break bridged DNAT).
>>
>> Bart, what do you think about changing this:
>
> (sorry for the webmail mess)
> I think that would work. It shouldn't be reset unconditionally at that point since we allow IP dnating of bridged packets (bridged-and-DNAT'ed case).
Could you check the attached patch?
> Another solution I think is this:
> in br_nf_post_routing():
> change
> if (!nf_bridge)
> to
> if (!nf_bridge || !(nf_bridge->mask & BRNF_BRIDGED_DNAT))
Wouldn't that break the regular case of packets forwarded
through a single bridge?
> This regression was introduced when the ip_out sabotage stuff was removed. br_nf_post_routing should now only consider bridged IP packets.
Yes, though the underlying problem seems to be that skb->nf_bridge
has no clearly defined lifetime. We want to pass the bridge port
information up exactly one layer, and then it should disappear.
But that seems to require sprinkling nf_bridge_put in lots of places.
[-- Attachment #2: x --]
[-- Type: text/plain, Size: 590 bytes --]
diff --git a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c
index da22f90..b7cac8d 100644
--- a/net/bridge/br_netfilter.c
+++ b/net/bridge/br_netfilter.c
@@ -713,8 +713,11 @@ static unsigned int br_nf_local_out(unsigned int hook, struct sk_buff *skb,
return NF_ACCEPT;
nf_bridge = skb->nf_bridge;
- if (!(nf_bridge->mask & BRNF_BRIDGED_DNAT))
+ if (!(nf_bridge->mask & BRNF_BRIDGED_DNAT)) {
+ nf_bridge_put(skb->nf_bridge);
+ skb->nf_bridge = NULL;
return NF_ACCEPT;
+ }
/* Bridged, take PF_BRIDGE/FORWARD.
* (see big note in front of br_nf_pre_routing_finish) */
next prev parent reply other threads:[~2007-11-07 11:55 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-07 11:44 Fw: Problems with nf_nat_ftp.ko and nf_conntrack_ftp.ko in 2.6.22.6 bdschuym@pandora.be
2007-11-07 11:44 ` bdschuym@pandora.be
2007-11-07 11:55 ` Patrick McHardy [this message]
2007-11-07 23:29 ` Bart De Schuymer
2007-11-12 6:00 ` Patrick McHardy
2007-11-12 7:35 ` Philip Craig
2007-11-12 7:39 ` Patrick McHardy
2007-11-08 2:16 ` Philip Craig
-- strict thread matches above, loose matches on Subject: below --
2007-11-12 7:30 bdschuym@pandora.be
2007-11-12 7:30 ` bdschuym@pandora.be
2007-11-01 21:16 Ron Lai
2007-11-01 21:16 ` Ron Lai
2007-11-05 11:03 ` Amin Azez
2007-11-05 16:36 ` ron lai
2007-11-05 16:36 ` ron lai
2007-11-06 10:14 ` Patrick McHardy
2007-11-06 13:19 ` ron lai
2007-11-06 13:19 ` ron lai
2007-11-06 13:24 ` Patrick McHardy
2007-11-06 13:50 ` ron lai
2007-11-06 13:50 ` ron lai
2007-11-06 14:05 ` Patrick McHardy
2007-11-06 15:17 ` Pascal Hambourg
2007-11-07 5:08 ` ron lai
2007-11-07 5:08 ` ron lai
2007-11-07 9:49 ` Patrick McHardy
2007-11-07 10:33 ` Patrick McHardy
2007-11-07 10:59 ` Pascal Hambourg
2007-11-07 11:37 ` Patrick McHardy
2007-11-07 15:17 ` ron lai
2007-11-07 15:17 ` ron lai
2007-11-07 23:19 ` Patrick McHardy
2007-11-07 23:54 ` Ron Lai
2007-11-07 23:54 ` Ron Lai
2007-11-08 9:03 ` Pascal Hambourg
2007-11-08 11:43 ` 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=4731A7A9.1050606@trash.net \
--to=kaber@trash.net \
--cc=bdschuym@pandora.be \
--cc=bdschuym@telenet.be \
--cc=netfilter-devel@vger.kernel.org \
--cc=netfilter@vger.kernel.org \
--cc=ronlai@cs.stanford.edu \
/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.