Re: possible issues with blowing up struct ipt_log_info

[Roberto Nibali <ratz@tac.ch>]

>>Trying to insert potentially many LOG rules to empirically determine
>>the maximum prefix length is far less complex, that's for sure. ;-)
> 
> Do we already have indeterminate log prefix length? I thought we had
> one, fixed size, no probing neccessary. Am I wrong?

No, it's fix. And "probing" can easily be done with a large sized prefix,
although I'm a bit astonished as to why someone wouldn't know the prefix size
when loading the packet filter ruleset.

>>For now, that's the only way an upper-level tool will produce valid
>>LOG rules in all cases.
>  
> The way to produce valid log rules in all cases, is to keep this
> fancy long long stuff in user level, and set pointer / index values
> or whatever small token can be used, for a log prefix in the kernel.

This does not work in environments where you need high speed logging since
having a pointer, or hashmap value, would require an intermediate process to
translate it into parsable strings again. This is from an architectural point of
view and from a performance point of view not possible, at least not in our
environment.

> Any scheme which probes the possible length, will also need some
> fallback when kernel length is smaller than user desire. If your
> goal is 'valid in all cases'. Right? Then you'll need such a
> token/pointer approach anyway!

The fallback is as it always was, exit with return value 2. Nothing changes. The
token/pointer approach is not something the netfilter architecture can provide
for you. That's something each packet filter software would have to provide by
itself. Example:

# A filter rule could expand into a ruleset where on of the rules could be
iptables -t filter -A INPUT -j LOG -i eth0 --log-level info --log-prefix
'ptr_666' -p icmp --icmp-type 8 -s 172.23.120.30/32 -d 172.23.120.120 -m state
--state NEW

# The ptr_666 is a pointer which can be translated again into human readable
# or log parsable strings.
ptr_666="pf rule set, ABI/55: icmp_from_fw [666] a:ACCEPT s:NEW f:INPUT TRACK
sub referenced as group"

>>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.
>  
> If getsockopt is good to communicate iptables rules and other stuff,
> it must be good enough to also communicate 'length of X is Y'...

Well, good enough is a relative term :), but the netfilter core team is working
extra hours on the netlink integration which could help a lot in this
perspective. It would be a lot more fun to get the connection tracking table
filled with thousands of entries in less than 2 Minutes, so the monitoring
system does not have so many spikes. Customers often ask if the system is
malfunctioning or down every 5-15 Minutes :).

Regards,
Roberto Nibali, ratz
-- 
-------------------------------------------------------------
addr://Rathausgasse 31, CH-5001 Aarau  tel://++41 62 823 9355
http://www.terreactive.com             fax://++41 62 823 9356
-------------------------------------------------------------
terreActive AG                       Wir sichern Ihren Erfolg
-------------------------------------------------------------