Re: [PATCH]: Keep the "state" match as alias [Re: state match is obsolete 1.4.17]

[Pablo Neira Ayuso <pablo@netfilter.org>]

On Wed, Jan 23, 2013 at 10:00:19AM +0100, Jozsef Kadlecsik wrote:
> On Wed, 23 Jan 2013, Pablo Neira Ayuso wrote:
> 
> > On Tue, Jan 22, 2013 at 10:47:35PM +0100, Jozsef Kadlecsik wrote:
> > > On Fri, 18 Jan 2013, Pablo Neira Ayuso wrote:
> > > 
> > > > On Tue, Jan 15, 2013 at 06:28:11PM +0100, Jozsef Kadlecsik wrote:
> > > > > On Tue, 15 Jan 2013, Jozsef Kadlecsik wrote:
> > > > > 
> > > > > > With passing one more internal flag, indicating that the "state" alias is 
> > > > > > used, the "conntrack" module can remain completely hidden and the user can 
> > > > > > list/save exactly the same command as the issued one.
> > > > > 
> > > > > Here follows the patch which introduces match module aliases (the same can 
> > > > > be done for targets as well). The alias is handled as it were a real 
> > > > > extension while it's actually handled by another module. Listing/saving 
> > > > > keeps the alias name and options.
> > > > > 
> > > > > The "state" extension is the first example of such an alias.
> > > > 
> > > > I like this symmetrical aliasing approach.
> > > > 
> > > > The aim is to get rid of redundant things in the kernel. And with
> > > > this, we can get that without disturbing users.
> > > > 
> > > > Would you do the same for the NOTRACK target?
> > > 
> > > Yes, but looking through the modules, I see a lot of inconsistencies: in 
> > > listing match names capitalized, some match/target doesn't print its name, 
> > > missing whitespaces, etc.
> > > 
> > > I'm going to fix those, but quite a lot of simplification could be 
> > > achieved if the options at listing and saving could be generated by the 
> > > same function in a match/target. Like instead of
> > > 
> > > 	ttl match TTL == xxx
> > > 
> > > I propose to list the match as
> > > 
> > > 	ttl eq xxx
> > > 
> > > (That is generate listings by striping off the dashes and the match/target 
> > > name prefix from the options.)
> > > 
> > > The question is: do we have a "stable API" in listings, at this level?
> > 
> > I remember that, while discussing nfacct, some people mentioned that
> > they were using scripts to parse iptables -L -n to digest counters.
> 
> The counters part is not affected.
>  
> > I have also found some perl extension [1] that parses `iptables -L -n'
> > output.
> > 
> > [1] http://search.cpan.org/dist/IPTables-Parse/
> 
> Sigh. Why 'iptables -L -n' is used and not 'iptables-save -c'?

Good question :-). I don't have an answer for that, probably the
author.

> Looking at the perl module, the proposed changes would break the parsing 
> of the options of the SNAT/DNAT targets. It'd be not hard to prepare the 
> module to handle current/proposed formats.

Yes. That will fix that module for latest iptables, but would still
break with old iptables versions unless you add some workaround to
that script.

Don't get me wrong, I don't like those inconsistencies either. We have
to decide if we care to likely break existing applications parsing
iptables -L -n.