Jozsef Kadlecsik wrote:
On Fri, 12 Jun 2009, Patrick McHardy wrote:
I didn't mean to finally say no, just wondering if there are special
circumstances which would justify an exception.
No need for an exception, there's a much nicer solution.
What is my main problem actually? That currently there is no way for an
extension-specific error reporting from the kernel to iptables when
there's some problem with a rule. Therefore in order to catch the typical
mistakes, I have to check the existence of the set specified on the
iptables command line before the rules are sent to the kernel. It is done
by querying the kernel about the set, currently via *sockopt calls. But
when ipset is migrated to nfnetlink, it'd mean libnfnetlink dependecy,
just for the sake of the set match/target in iptables. That's a too high
price and I'm not willing to pay it.
So what I'm working on it is a protocol change in iptables itself (:-),
which is fully backward compatible.
- add a new sockopt option, IPT_SO_GET_REPLACE, which is used instead of
IPT_SO_SET_REPLACE (if supported by the kernel. New iptables will
use IPT_SO_SET_REPLACE with old kernels.)
- new checkentry functions, which return the extension-specific error
codes instead of a simple boolean value
- if any error is detected by the checkentry funtions, IPT_SO_GET_REPLACE
returns the corresponding full ipt_entry, with the offset stored in
comefrom to the match/target which produced the error
- the userspace match/targets, with their new error function,
can translate the received error code to the appropriate error message
and can insert any specific data into the text using the offset into the
ipt_entry.
So we'll be able to report back exactly what is wrong with the given rule.
No need anymore to print 'Run `dmesg' for more information.' :-).
That sounds pretty cool.
And from the set match/target point of view, I won't have to query the
kernel at all :-)).
So far, working on the kernel part, surprisingly small modifications are
required.
I'm looking forward to finally have reasonable error reporting :)
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
