Re: possible issues with blowing up struct ipt_log_info

[Herve Eychenne <rv@wallfire.org>]

On Sun, Jul 03, 2005 at 02:36:50PM +0200, Harald Welte wrote:

> On Wed, Jun 29, 2005 at 06:09:23PM +0200, Herve Eychenne wrote:
> > On Wed, Jun 29, 2005 at 05:40:49PM +0200, Patrick Schaaf wrote:
> > 
> > > > My question is, if anyone sees any problems with this, regarding performance
> > > > degradation on 32bit boxes or with caching problems?
> > 
> > > The problem is compatibility with older versions of the LOG target,
> > > both Userlevel (iptables .so module), and Kernel.
> > 
> > > You can either make this a new target, or look how the versioning
> > > infrastructure discussed here some months ago, worked out. (I don't
> > > know; maybe there's already a HOWTO, or you want to write one :)
> > 
> > I remember saying here that it would be cool to have the log prefix length
> > tunable at kernel LOG module insertion, have it exported (read-only) to some
> > /proc entry, and have userspace (iptables, or any other upper-level
> > application) rely on the real-time extracted value.

> I really don't think that this is worth the complexity...

Trying to insert potentially many LOG rules to empirically determine
the maximum prefix length is far less complex, that's for sure. ;-)
For now, that's the only way an upper-level tool will produce valid
LOG rules in all cases.
Probably many of you won't care, but for this kind of upper-layers
(which I'm particularly concerned with) netfilter/iptables sometimes
makes it hard to turn "should work" into "will work".
That LOG thing is only one example, though probably not the best.

> I also don't really like using out-of-band interfaces such as /proc
> to determine how to communicate rules via {get,set}sockopt()

Maybe you don't like /proc, but the kernel still has to provide a way
to inform userspace about the fixed size of some of its data (as
kernelspace doesn't like dynamic things very much...). If you see a
better way, that's ok, but the need is still there.

 Herve

-- 
 _
(°=  Hervé Eychenne
//)
v_/_ WallFire project:  http://www.wallfire.org/