enabling bridge_ipf

[Maxime Villard]

Any reason this isn't enabled by default? Right now you need to recompile
your kernel with "options BRIDGE_IPF" if you want a firewall on the bridge.
This is annoying.

There is already a dynamic switch behind it anyway: you need to pass "ipf"
to brconfig in order for filtering to actually be enabled, so having the
extra "options BRIDGE_IPF" serves little purpose.

I want to enable BRIDGE_IPF by default, by removing the option and the
#ifdefs. That is, by making the code part of bridge(4) by default.

Note that BRIDGE_IPF is not related to IPF. It uses the pfil interface, so
it works with NPF.

Maxime

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Greg Troxel]

Post by Maxime Villard
Any reason this isn't enabled by default? Right now you need to recompile
your kernel with "options BRIDGE_IPF" if you want a firewall on the bridge.
This is annoying.
There is already a dynamic switch behind it anyway: you need to pass "ipf"
to brconfig in order for filtering to actually be enabled, so having the
extra "options BRIDGE_IPF" serves little purpose.
I want to enable BRIDGE_IPF by default, by removing the option and the
#ifdefs. That is, by making the code part of bridge(4) by default.
Note that BRIDGE_IPF is not related to IPF. It uses the pfil interface, so
it works with NPF.

This makes sense to me.

The only reason not to would be if it created a lot more code and made
the kernel bigger, or some worry about a few instructions per packet in
bridging. Surely it's just a tiny overhead, and it doesn't really make
sense for bridges to be special vs other interfaces. (If someone wants
to compile out PFIL_HOOKS, this should go too.)

So my only request is to do a test compile with PFIL off.


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Maxime Villard]

Post by Greg Troxel
...
The only reason not to would be if it created a lot more code and made
the kernel bigger, or some worry about a few instructions per packet in
bridging. Surely it's just a tiny overhead, and it doesn't really make
sense for bridges to be special vs other interfaces. (If someone wants
to compile out PFIL_HOOKS, this should go too.)

PFIL_HOOKS is IPF-specific, not related to bridges, and hard-enabled as far
as I can tell (ie, not an option).

Post by Greg Troxel
So my only request is to do a test compile with PFIL off.

There is no PFIL option available. "pfil" is a small set of functions which
are unconditionally part of the kernel.

Maxime

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Greg Troxel]

Post by Maxime Villard

Post by Greg Troxel
The only reason not to would be if it created a lot more code and made
the kernel bigger, or some worry about a few instructions per packet in
bridging. Surely it's just a tiny overhead, and it doesn't really make
sense for bridges to be special vs other interfaces. (If someone wants
to compile out PFIL_HOOKS, this should go too.)

I went and read the code. Hard-enabling BRIDGE_IPF does bring in a
bunch of lines of code, but it doesn't seem that big. So I don't have
a problem with this.

Post by Maxime Villard
PFIL_HOOKS is IPF-specific, not related to bridges, and hard-enabled as far
as I can tell (ie, not an option).

I don't follow "IPF-specific" as it seems to be an abstract interface to
an arbitrary packet filter. But agreed that I can find no evidence of
PFIL_HOOKS being optional - I think I am remembering long ago.

Post by Maxime Villard

Post by Greg Troxel
So my only request is to do a test compile with PFIL off.

There is no PFIL option available. "pfil" is a small set of functions which
are unconditionally part of the kernel.

Didn't realize that was non-optional; request withdrawn.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de