Hi!
Here is a fix for the problem I've reported yesterday.
http://marc.info/?l=netfilter-devel&m=132555432331663&w=2
Please review the patch carefully, I'm not a br_netfilter ninja. 8-)
Thanks,
//richard
___
Bridge mailing list
Bridge@lists.linux-fou
If net.bridge.bridge-nf-call-iptables or net.bridge.bridge-nf-call-ip6tables
are set to zero xt_physdev has no effect because skb->nf_bridge has not been
set up.
Signed-off-by: Richard Weinberger
---
net/bridge/br_netfilter.c | 31 +++
1 files changed, 23 insertion
Am 03.01.2012 17:15, schrieb Stephen Hemminger:
> On Tue, 3 Jan 2012 14:26:04 +0100
> Richard Weinberger wrote:
>
>> If net.bridge.bridge-nf-call-iptables or net.bridge.bridge-nf-call-ip6tables
>> are set to zero xt_physdev has no effect because skb->nf_bridge has not been
>> set up.
>>
>> Sign
Am 03.01.2012 21:15, schrieb Bart De Schuymer:
> The documentation is probably not explicit enough, but I would keep the
> behavior as it is now. Setting bridge-nf-call-iptables to 0 makes
> iptables behave as if bridge-netfilter was not enabled at compilation.
> Anyway, your patch is almost certai
Am 04.01.2012 18:55, schrieb Bart De Schuymer:
> Op 3/01/2012 21:29, Richard Weinberger schreef:
>> Am 03.01.2012 21:15, schrieb Bart De Schuymer:
>>> The documentation is probably not explicit enough, but I would keep the
>>> behavior as it is now. Setting bridge-nf-call-iptables to 0 makes
>>> ip
Am 05.01.2012 20:50, schrieb Bart De Schuymer:
> Op 5/01/2012 0:13, Richard Weinberger schreef:
>>
>> Let's export brnf_call_iptables and brnf_call_ip6tables, such that
>> physdev_mt_check() can notify the user that his iptables rule will have
>> no effect.
>>
>
> I don't want to introduce a runti
