next iptables release

next iptables release

[Patrick McHardy]

I've planned to release the next iptables version sometime (late)
this weekend. We've had quite a lot of changes since the last
version, please test the latest version from git and report any
issues.

Thanks!

Re: next iptables release

[Jan Engelhardt]

On Thursday 2009-03-19 09:31, Patrick McHardy wrote:

> I've planned to release the next iptables version sometime (late)
> this weekend. We've had quite a lot of changes since the last
> version, please test the latest version from git and report any
> issues.

    libxtables: add -I/-L flags to pkgconfig files
    
    These are needed in case iptables gets installed into a non-standard
    path. It also enables automatic detection of these locations from 3rd
    party programs via pkgconfig.


Patch pullable from  git://dev.medozas.de/iptables master

Updating 71bc61f..467e72c
Fast forward
 xtables.pc.in |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

Re: next iptables release

[Patrick McHardy]

Jan Engelhardt wrote:
> On Thursday 2009-03-19 09:31, Patrick McHardy wrote:
> 
>> I've planned to release the next iptables version sometime (late)
>> this weekend. We've had quite a lot of changes since the last
>> version, please test the latest version from git and report any
>> issues.
> 
>     libxtables: add -I/-L flags to pkgconfig files
>     
>     These are needed in case iptables gets installed into a non-standard
>     path. It also enables automatic detection of these locations from 3rd
>     party programs via pkgconfig.
> 
> 
> Patch pullable from  git://dev.medozas.de/iptables master

Pulled, thanks Jan.

Re: next iptables release

[Jan Engelhardt]

On Thursday 2009-03-19 09:31, Patrick McHardy wrote:

> I've planned to release the next iptables version sometime (late)
> this weekend. We've had quite a lot of changes since the last
> version, please test the latest version from git and report any
> issues.

FYI readers,

I have been asked before for this, and here is now the Xt-a tree
testing branch for the iptables 1.4.3 API (to be merged into master 
soon), available from

 git://xtables-addons.git.sf.net/gitroot/xtables-addons iptables143

Re: next iptables release

[Jan Engelhardt]

On Thursday 2009-03-19 09:31, Patrick McHardy wrote:

> I've planned to release the next iptables version sometime (late)
> this weekend. We've had quite a lot of changes since the last
> version, please test the latest version from git and report any
> issues.

Another bugfix here, which was reported on Friday on BTS.

    libxt_comment: output quotes must be escaped in

Pullable from git://dev.medozas.de/iptables master

Updating 467e72c..4211579
 extensions/libxt_comment.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

Re: next iptables release

[Patrick McHardy]

Jan Engelhardt wrote:
> On Thursday 2009-03-19 09:31, Patrick McHardy wrote:
> 
>> I've planned to release the next iptables version sometime (late)
>> this weekend. We've had quite a lot of changes since the last
>> version, please test the latest version from git and report any
>> issues.
> 
> Another bugfix here, which was reported on Friday on BTS.
> 
>     libxt_comment: output quotes must be escaped in
> 
> Pullable from git://dev.medozas.de/iptables master

Pulled, thanks Jan.

Re: next iptables release

[Pablo Neira Ayuso]

Patrick McHardy wrote:
> I've planned to release the next iptables version sometime (late)
> this weekend. We've had quite a lot of changes since the last
> version, please test the latest version from git and report any
> issues.
> 
> Thanks!

Great :). BTW, I'm finishing the cluster match manpage, I'll be done
tonight, I'd like to see it in this iptables release (even if the
feature is expected to appear in 2.6.30).

-- 
"Los honestos son inadaptados sociales" -- Les Luthiers

Re: next iptables release

[Patrick McHardy]

Pablo Neira Ayuso wrote:
> Patrick McHardy wrote:
>> I've planned to release the next iptables version sometime (late)
>> this weekend. We've had quite a lot of changes since the last
>> version, please test the latest version from git and report any
>> issues.
>>
>> Thanks!
> 
> Great :). BTW, I'm finishing the cluster match manpage, I'll be done
> tonight, I'd like to see it in this iptables release (even if the
> feature is expected to appear in 2.6.30).

I have to ask .. why? :)

Besides potentially confusing people (why doesn't it work despite me
doing everything the manpage says), what are the advantages of including
the manpage before the actual implementation?

Re: next iptables release

[Pablo Neira Ayuso]

Patrick McHardy wrote:
> Pablo Neira Ayuso wrote:
>> Patrick McHardy wrote:
>>> I've planned to release the next iptables version sometime (late)
>>> this weekend. We've had quite a lot of changes since the last
>>> version, please test the latest version from git and report any
>>> issues.
>>>
>>> Thanks!
>>
>> Great :). BTW, I'm finishing the cluster match manpage, I'll be done
>> tonight, I'd like to see it in this iptables release (even if the
>> feature is expected to appear in 2.6.30).
> 
> I have to ask .. why? :)
>
> Besides potentially confusing people (why doesn't it work despite me
> doing everything the manpage says), what are the advantages of including
> the manpage before the actual implementation?

I planned to distribute the kernel module separately until 2.6.30
arrives, add a page to conntrack-tools.netfilter.org, document this in
the conntrack-tools manual [1] to describe the active-active setup, and
so on. Basically, my motivation is to get some feedback from people as
soon as possible without waiting the whole kernel cycle release.

I know that this seems something exceptional and it may confuse people.
Another choice is to keep it in pom-ng in the meantime, or perhaps
simply be a little bit patient :).

[1] http://conntrack-tools.netfilter.org/manual.html

-- 
"Los honestos son inadaptados sociales" -- Les Luthiers

Re: next iptables release

[Patrick McHardy]

Pablo Neira Ayuso wrote:
> Patrick McHardy wrote:
>>> Great :). BTW, I'm finishing the cluster match manpage, I'll be done
>>> tonight, I'd like to see it in this iptables release (even if the
>>> feature is expected to appear in 2.6.30).
>> I have to ask .. why? :)
>>
>> Besides potentially confusing people (why doesn't it work despite me
>> doing everything the manpage says), what are the advantages of including
>> the manpage before the actual implementation?
> 
> I planned to distribute the kernel module separately until 2.6.30
> arrives, add a page to conntrack-tools.netfilter.org, document this in
> the conntrack-tools manual [1] to describe the active-active setup, and
> so on. Basically, my motivation is to get some feedback from people as
> soon as possible without waiting the whole kernel cycle release.
> 
> I know that this seems something exceptional and it may confuse people.
> Another choice is to keep it in pom-ng in the meantime, or perhaps
> simply be a little bit patient :).
> 
> [1] http://conntrack-tools.netfilter.org/manual.html

How about just adding it as first commit after the release? That way
people can get the latest stable version, including support for the
cluster match. Otherwise they'd have to patch in the the extension
anyways.

Re: next iptables release

[Jan Engelhardt]

On Thursday 2009-03-19 14:16, Patrick McHardy wrote:
>>
>> I planned to distribute the kernel module separately until 2.6.30
>> arrives, add a page to conntrack-tools.netfilter.org, document this in
>> the conntrack-tools manual [1] to describe the active-active setup, and
>> so on. Basically, my motivation is to get some feedback from people as
>> soon as possible without waiting the whole kernel cycle release.
>>
>> I know that this seems something exceptional and it may confuse people.
>> Another choice is to keep it in pom-ng in the meantime, or perhaps
>> simply be a little bit patient :).
>>
>> [1] http://conntrack-tools.netfilter.org/manual.html
>
> How about just adding it as first commit after the release? That way
> people can get the latest stable version, including support for the
> cluster match. Otherwise they'd have to patch in the the extension
> anyways.

I am all for including it now. Distributions are known to forget
updating iptables, so the earlier it gets included, the higher is the
chance distros pick it [a new iptables release] up. Users (or these
days, too, Debian) often upgrading their kernel yet not dare to
manually install anything outside the package manager's realm, that
is my impression. For example etchnhalf — nice kernel, but it is
hopeless with the iptables version to get the new goodies.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: next iptables release

[Patrick McHardy]

Jan Engelhardt wrote:
>
>> How about just adding it as first commit after the release? That way
>> people can get the latest stable version, including support for the
>> cluster match. Otherwise they'd have to patch in the the extension
>> anyways.
>>     
>
> I am all for including it now. Distributions are known to forget
> updating iptables, so the earlier it gets included, the higher is the
> chance distros pick it [a new iptables release] up. Users (or these
> days, too, Debian) often upgrading their kernel yet not dare to
> manually install anything outside the package manager's realm, that
> is my impression. For example etchnhalf — nice kernel, but it is
> hopeless with the iptables version to get the new goodies.
>   

Sorry, no way. I'm not going back to the random-crap model.

--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: next iptables release

[Jan Engelhardt]

On Thursday 2009-03-19 13:55, Patrick McHardy wrote:
> Pablo Neira Ayuso wrote:
>> Patrick McHardy wrote:
>>> I've planned to release the next iptables version sometime (late)
>>> this weekend. We've had quite a lot of changes since the last
>>> version, please test the latest version from git and report any
>>> issues.
>>>
>>> Thanks!
>>
>> Great :). BTW, I'm finishing the cluster match manpage, I'll be done
>> tonight, I'd like to see it in this iptables release (even if the
>> feature is expected to appear in 2.6.30).
>
> I have to ask .. why? :)
>
> Besides potentially confusing people (why doesn't it work despite me
> doing everything the manpage says), what are the advantages of including
> the manpage before the actual implementation?

It does not confuse people as much as you think, I would say.
Since iptables runs with kernels so old the dust could kill,
the scenarios where iptables has an .so file for a kernel piece
that did not exist yet back then are numerous.

Re: next iptables release

[Patrick McHardy]

Jan Engelhardt wrote:
> On Thursday 2009-03-19 13:55, Patrick McHardy wrote:
>> Besides potentially confusing people (why doesn't it work despite me
>> doing everything the manpage says), what are the advantages of including
>> the manpage before the actual implementation?
>>     
>
> It does not confuse people as much as you think, I would say.
> Since iptables runs with kernels so old the dust could kill,
> the scenarios where iptables has an .so file for a kernel piece
> that did not exist yet back then are numerous.
>   

Object files are a completely different questions. We've had tons of crap
in there for unmerged patches that we did later merge and had to change
the API, which caused "breakage" for people.

So that is out of the question anyways. And a manpage for something that
isn't even present will either not get noticed or confuse people. Its not
useful.

Re: next iptables release

[Jan Engelhardt]

On Thursday 2009-03-19 14:55, Patrick McHardy wrote:
>Jan Engelhardt wrote:
>> On Thursday 2009-03-19 13:55, Patrick McHardy wrote:
>>> Besides potentially confusing people (why doesn't it work despite me
>>> doing everything the manpage says), what are the advantages of including
>>> the manpage before the actual implementation?
>>
>> It does not confuse people as much as you think, I would say.
>> Since iptables runs with kernels so old the dust could kill,
>> the scenarios where iptables has an .so file for a kernel piece
>> that did not exist yet back then are numerous.
>
>[...]a manpage for something that
>isn't even present will either not get noticed or confuse people. Its not
>useful.

I agree with that. Manpages for non-existant .so files seems
cloven/incomplete [zerhackt].

>Object files are a completely different questions. We've had tons of crap
>in there for unmerged patches that we did later merge and had to change
>the API, which caused "breakage" for people.

Yes, but we can, and specifically I do, expect Pablo to fabricate
something better, more consistent, and which has been reviewed with
regard to the 'guideline checklist' than the unreviewed rotting
bits that used to be in the past POM tree.

Re: next iptables release

[Patrick McHardy]

Jan Engelhardt wrote:
> On Thursday 2009-03-19 14:55, Patrick McHardy wrote:
>   
>
>> Object files are a completely different questions. We've had tons of crap
>> in there for unmerged patches that we did later merge and had to change
>> the API, which caused "breakage" for people.
>>     
>
> Yes, but we can, and specifically I do, expect Pablo to fabricate
> something better, more consistent, and which has been reviewed with
> regard to the 'guideline checklist' than the unreviewed rotting
> bits that used to be in the past POM tree.
>   

I do to, but I don't see why we should risk it. Its just as well possible
that someone testing it thinks of a great feature that would perfectly fit
in, but needs ABI changes. The -rc phase is for testing and also fixing
and changing things, releasing userspace before the kernel part is set in
stone is unnecessarily reducing the short amount of time we have for this.

Re: next iptables release

[Pablo Neira Ayuso]

Patrick McHardy wrote:
> I do to, but I don't see why we should risk it. Its just as well possible
> that someone testing it thinks of a great feature that would perfectly fit
> in, but needs ABI changes. The -rc phase is for testing and also fixing
> and changing things, releasing userspace before the kernel part is set in
> stone is unnecessarily reducing the short amount of time we have for this.

Indeed. I'll apply the patch once iptables is released. Let me know if I
can give you a hand with the releasing process.

-- 
"Los honestos son inadaptados sociales" -- Les Luthiers

Re: next iptables release

[Patrick McHardy]

Pablo Neira Ayuso wrote:
> Patrick McHardy wrote:
>> I do to, but I don't see why we should risk it. Its just as well possible
>> that someone testing it thinks of a great feature that would perfectly fit
>> in, but needs ABI changes. The -rc phase is for testing and also fixing
>> and changing things, releasing userspace before the kernel part is set in
>> stone is unnecessarily reducing the short amount of time we have for this.
> 
> Indeed. I'll apply the patch once iptables is released. Let me know if I
> can give you a hand with the releasing process.

Thanks, I hope I can manage it :)

[PATCH] iptables: avoid compile warnings for iptc_insert_chain

[Christoph Paasch]

iptc_insert_chain is too big to get inlined and so it generates
a warning while compiling.

Signed-off-by: Christoph Paasch <christoph.paasch@gmail.com>
---
 libiptc/libiptc.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/libiptc/libiptc.c b/libiptc/libiptc.c
index 544a5b2..c3d9bfc 100644
--- a/libiptc/libiptc.c
+++ b/libiptc/libiptc.c
@@ -841,7 +841,7 @@ static int __iptcc_p_del_policy(struct xtc_handle *h, unsigned int num)
 }
 
 /* alphabetically insert a chain into the list */
-static inline void iptc_insert_chain(struct xtc_handle *h, struct chain_head *c)
+static void iptc_insert_chain(struct xtc_handle *h, struct chain_head *c)
 {
 	struct chain_head *tmp;
 	struct list_head  *list_start_pos;
-- 
1.5.6.3

Re: [PATCH] iptables: avoid compile warnings for iptc_insert_chain

[Patrick McHardy]

Christoph Paasch wrote:
> iptc_insert_chain is too big to get inlined and so it generates
> a warning while compiling.

Applied, thanks. But please include the compiler messages in the
changelog when fixing warnings.

Re: next iptables release

[Jesper Dangaard Brouer]

On Thu, 19 Mar 2009, Patrick McHardy wrote:

> I've planned to release the next iptables version sometime (late)
> this weekend. We've had quite a lot of changes since the last
> version, please test the latest version from git and report any
> issues.

I just realized a bug in libiptc.c in func TC_RENAME_CHAIN.
The rename should insert the new chain name sorted, as my binary 
search system / skip-list rely on it.

I don't have time to fix it until monday. Jan, feel free to fix it up 
before I do...

Cheers,
   Jesper Brouer

--
-------------------------------------------------------------------
MSc. Master of Computer Science
Dept. of Computer Science, University of Copenhagen
Author of http://www.adsl-optimizer.dk
-------------------------------------------------------------------

commit 6b7e7cde912a6395cb2a1f5e4b2f50cad2592b17
Author: Jesper Dangaard Brouer <hawk@comx.dk>
Date:   Sat Mar 21 15:40:54 2009 +0100

     I just realized a bug in libiptc.c in func TC_RENAME_CHAIN.
     Due my bsearch/skip-list implementation.

diff --git a/libiptc/libiptc.c b/libiptc/libiptc.c
index 544a5b2..3bcae9c 100644
--- a/libiptc/libiptc.c
+++ b/libiptc/libiptc.c
@@ -2404,6 +2404,8 @@ int TC_RENAME_CHAIN(const IPT_CHAINLABEL oldname,
  		return 0;
  	}

+	/* FIXME: Bug here due to the bsearch system, new chain name
+	   needs to be inserted sorted */
  	strncpy(c->name, newname, sizeof(IPT_CHAINLABEL));

  	set_changed(handle);

Re: next iptables release

[Patrick McHardy]

Jesper Dangaard Brouer wrote:
> On Thu, 19 Mar 2009, Patrick McHardy wrote:
> 
>> I've planned to release the next iptables version sometime (late)
>> this weekend. We've had quite a lot of changes since the last
>> version, please test the latest version from git and report any
>> issues.
> 
> I just realized a bug in libiptc.c in func TC_RENAME_CHAIN.
> The rename should insert the new chain name sorted, as my binary search 
> system / skip-list rely on it.
> 
> I don't have time to fix it until monday. Jan, feel free to fix it up 
> before I do...

I'll wait with the release until someone sends me a patch :)