On 02/13/15 20:03, Florian Westphal wrote: > Imre Palik <imrep.amz@xxxxxxxxx> wrote: >> The trouble is that there are some bridges (with low traffic) where I need netfilter, and some other bridges (carrying lots of traffic), where I don't. Being able to set things up on a per bridge basis is a powerful thing. >> >> I only implemented the global switch because the iptables and arptables support also have one. If this is what bugs people here, I can remove it, and resubmit. > > I see. But I agree with David, accepting such patch would pave way > for all kinds of ugly hacks. > > It seems that technically the best solution would be to allow attaching > filter rules to devices, but alas, netfilter doesn't support that. > > Alternatively, you patch *might* be ok iff you can get rid of the extra > userspace-visible configuration knobs, we already have way too many of > these. The sysctl can be removed. But I need some means to switch it off for a given bridge, so I kept the sysfs interface. If there is a more preferred way to do it, then please let me know. > You'll also have to figure out how to avoid any run-time dependency on > br_netfilter module from the bridge core. > > If you can do this, you might be able to get similar effect as your patch > by replacing > > NF_HOOK with NF_HOOK_COND(..., !(br->flags & NO_NETFILTER)) > > or something like this. This works nicely for the NFPROTO_BRIDGE, NF_BR_PRE_ROUTING case. Thanks for the idea. But for the NFPROTO_BRIDGE, NF_BR_FORWARD case the resulting code would be more ugly, because of the chaining of the entries. > I don't know how invasive this would be, though. I will post the cleaned up version in a sec. It looks way better. I hope it will be enough ...