placement of postrouting
Fri, 26 Apr 2002 11:26:07 -0700
Harald Welte writes:
> On Fri, Apr 26, 2002 at 09:52:46AM -0700, Don Cohen wrote:
> > Harald Welte writes:
> So you want to have a big case statement _after_ enqueuing of the packet
> happens [ i.e. in the network TX softirq], calling NF_HOOK for the
> respective protocol family?
Actually, after dequeuing.
I did suggest an alternative to the big case statement, which was
a new hook. You'd loop through the registered functions. Perhaps
these functions should be able to return something to drop the packet.
> > ... I think in general it would be
> > worth while to save more of this data for use in later hooks.
> > So I think that nat should save the original data just for use in
> > later hooks.
> well, but it's added overhead and none of the existing functions within
> the framework need it. If there is any chance for adding such overhead,
> then if at the same time we actually have some code which uses it.
> Just providing features because they are nice for some
> not-included-in-kernel code is not our philosophy.
Netfilter itself seems to be a counterexample to that statement.
Its whole purpose is to enhance the range of things that can be done
by not-included-in-kernel code(*). Certainly it's worth saving a
little more data in order to increase that range further.
For any particular data this is a cost benefit question.
The cost of saving the data is to be compared with the benefit of
what can be done with that data.
(*) Now that I reread this, it occurs to me that in-kernel could mean
two different things. The code in modules (or code that could have
been in modules) could be considered in or out. I meant to include it
as part of what netfilter is meant to support. The other code is
stuff like iptables rules, which I think is clearly out. In both
cases it's useful to make something like input device available.