list of available matches and targets through /proc
Mon, 15 Apr 2002 12:00:36 +0200
On Sun, Apr 14, 2002 at 01:02:32AM -0400, Zygo Blaxell wrote:
> In article <20020411122102.G24408@sunbeam.de.gnumonks.org>,
> Harald Welte <email@example.com> wrote:
> >On Wed, Apr 10, 2002 at 09:36:05PM -0400, Zygo Blaxell wrote:
> >> I think that the user-space modules should provide much richer version
> >> information than a simple version number. Simple version numbers are
> >> useless if there are multiple maintainers each extending the code in
> >> different ways and distributing it before it is officially integrated
> >> (i.e. the status quo for netfilter and indeed most of the Linux kernel).
> >Where did you get this idea from? Please point me to a single occation
> >where any part of iptables was modified in different ways by different
> Sure...the module net/ipv4/netfilter/ip_conntrack_standalone.c was
> modified in different ways by Gerd Knorr, Henrik Nordstrom, Jay Schulist,
> Harald Welte, Jozsef Kadlescik, Rusty Russell, and Various Artists.
> Some of these modifications change kernel-to-user communication mechanisms
> (note I include renaming or reformatting things under /proc here),
> most change internal kernel-to-kernel API's, or cause failure to build,
> or cause failures in other patches.
I was explicitly talking about _iptables_, namely iptables extensions
(ipt_XXX.o and their respective counterparts libipt_XXX.so and their userspace
api exposed via the iptabels commandline utility).
btw: The connection tracking changes you have mentioned all occurred
sequentialy, whereas your original statement was suggesting that they had been
modified at the same time and different versions were distributed at the same
And please don't refer to some development stages. Code which is under active
development (and has not been officially released by submission to the
mainstream kernel) is subject to code fluctutation. I don't see anything
> In addition to the CVS tree there are other large distributors of
> netfilter--the Linux kernel and all of its derivative flavours (some
> of which you mostly control) and all the different Linux distributors
> who are now packaging this stuff.
> Suppose some Linux distributor is insane enough to package netfilter with
> non-default patch/compile options (oops, too late, Red Hat already did
> this), and the distro people throw in some of their own patches that
> are not in your CVS because they haven't submitted them yet, or their
> patches were submitted but you've rejected them.
This is a general problem with free software in general. I have to admit
that I am not very lucky with the behaviour of distributors with regard to
> It would not be difficult to implement version checking module by module,
> since the extensible part of kernel/userspace communication is just
> passing arbitrary struct's back and forth. Add a struct member for
> version and check it whenever the struct is received at both ends.
Well, that might be suitable if we'd be taliking about 2.5.x - but we
certainly cannot make this change during 2.4.x, because it would break
all compatibility to old versions of the iptables commandline utility.
As already stated (and documented in the devel meeting proceedings), 2.5.x
will see a major redesign of the iptables structures anyway - and versioning
is definitely a design criteria.
> Ah, iptables2 would be the code I never bother to look at as I'm too
> busy banging on the parts of netfilter I'm actually trying to use. ;-)
:) well, there's a lot of recent work on libiptables, which i haven't
committed to CVS yet, since it is not in a state where it even compiles.
> I wonder if there has been some thought to what happens to e.g. a GUI
> config tool when new options to an iptables module are added. Will there
> be a backward-compatible mechanism that can be used if the GUI finds
> a data type newer than itself?
The GUI can query libiptables about available plugins and their options.
Everything behind is covered by libiptables. The Applications _must not_
make any assumption on which options are present and what data types
they use. Everything needs to be read via libiptables at runtime.
With libiptables (as soon as it is fully implemented) it is possible to
write a GUI (or any other application) which doesn't know anything about
individual matches/targets, their options, data types or help messges.
The application does not need to be modified if a new match/target is
Please see the README file, it gives some basic idea...
> Zygo Blaxell (Laptop) <firstname.lastname@example.org>
Live long and prosper
- Harald Welte / email@example.com http://www.gnumonks.org/
GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M+
V-- PS++ PE-- Y++ PGP++ t+ 5-- !X !R tv-- b+++ !DI !D G+ e* h--- r++ y+(*)