Re: Filtering on bridges

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

On Thursday 2011-12-22 11:56, Steve Hill wrote:
>> But the kernel knows, and that's really all that is needed.
>I think we have a misunderstanding somewhere:

>Looking at nf-packet-flow.svg, [...] the direction of the link
>between "routing decision" and "bridging decision" seems ambiguous
>to me).

In that graphic, when there is a choice, the network stack will pick
only one.

>So at the moment, the only way I can think of doing the filtering is to allow
>the packet to run through *all* the iptables rules without matching the
>physical output NIC and set one bit of the fwmark for each physical interface I
>would let the packet egress.  Then in ebtables (where we know the physical
>interface) filter the packets by looking at the fwmark bit that I've used to
>indicate that interface. This method is pretty unscalable (fwmark is 32

As for filtering, which I had gathered was what you wanted, you could 
set the fwmark to indicate drop-or-not-drop (rather than a bit for each 
interface). As for QoS though, indeed there is a little issue.

>So any other good ideas for how to accomplish this filtering?  (I 
>understand the reasons for removing the physdev-out support for 
>unbridged traffic, but why on earth hasn't it been replaced with 
>something to do a similar job, such as an additional iptables chain 
>after the bridging decision rather than wholesale removing a useful 

Checking the source for possibilities..
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at

[Linux Netfilter Development]     [Linux Kernel Networking Development]     [Linux Networking Development]     [Linux Kernel Development]     [Linux Resources]     [LARTC]     [Bugtraq]     [Consulting]     [Free Internet Dating]     [Yosemite Forum]     [Photo]

Add to Google Powered by Linux