Re: next iptables release

Re: next iptables release

[Jan Engelhardt]

The following changes since commit 596c69007acb569843391e4c98dc21d6f2336e7b:
  Patrick McHardy (1):
        DNAT: fix incorrect check during parsing

are available in the git repository at:

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

Jan Engelhardt (3):
      iptables: take masks into consideration for replace command
      doc: explain experienced --hitcount limit
      doc: name resolution clarification

 extensions/libxt_recent.man |    4 +++-
 ip6tables.8.in              |   10 ++++++----
 ip6tables.c                 |   10 ++++++----
 iptables.8.in               |    8 +++++---
 iptables.c                  |   10 ++++++----
 5 files changed, 26 insertions(+), 16 deletions(-)

[PATCH 1/3] iptables: take masks into consideration for replace command

[Jan Engelhardt]

The two commands:

-A OUPUT -d 10.11.12.13/32 -j LOG
-R OUTPUT 1 -j LOG -d 10.11.12.13

will replace 10.11.12.13/32 by 10.11.12.13/0, which is not right.
(No regression, this problem was there forever.)

Reported-by: Werner Pawlitschko <werner.pawlitschko@arcor.de>
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
---
 ip6tables.c |   10 ++++++----
 iptables.c  |   10 ++++++----
 2 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/ip6tables.c b/ip6tables.c
index f6daa51..e2359df 100644
--- a/ip6tables.c
+++ b/ip6tables.c
@@ -758,13 +758,15 @@ static int
 replace_entry(const ip6t_chainlabel chain,
 	      struct ip6t_entry *fw,
 	      unsigned int rulenum,
-	      const struct in6_addr *saddr,
-	      const struct in6_addr *daddr,
+	      const struct in6_addr *saddr, const struct in6_addr *smask,
+	      const struct in6_addr *daddr, const struct in6_addr *dmask,
 	      int verbose,
 	      struct ip6tc_handle *handle)
 {
 	fw->ipv6.src = *saddr;
 	fw->ipv6.dst = *daddr;
+	fw->ipv6.smsk = *smask;
+	fw->ipv6.dmsk = *dmask;
 
 	if (verbose)
 		print_firewall_line(fw, handle);
@@ -1947,8 +1949,8 @@ int do_command6(int argc, char *argv[], char **table, struct ip6tc_handle **hand
 		break;
 	case CMD_REPLACE:
 		ret = replace_entry(chain, e, rulenum - 1,
-				    saddrs, daddrs, options&OPT_VERBOSE,
-				    *handle);
+				    saddrs, smasks, daddrs, dmasks,
+				    options&OPT_VERBOSE, *handle);
 		break;
 	case CMD_INSERT:
 		ret = insert_entry(chain, e, rulenum - 1,
diff --git a/iptables.c b/iptables.c
index a69aab3..08eb134 100644
--- a/iptables.c
+++ b/iptables.c
@@ -760,13 +760,15 @@ static int
 replace_entry(const ipt_chainlabel chain,
 	      struct ipt_entry *fw,
 	      unsigned int rulenum,
-	      const struct in_addr *saddr,
-	      const struct in_addr *daddr,
+	      const struct in_addr *saddr, const struct in_addr *smask,
+	      const struct in_addr *daddr, const struct in_addr *dmask,
 	      int verbose,
 	      struct iptc_handle *handle)
 {
 	fw->ip.src.s_addr = saddr->s_addr;
 	fw->ip.dst.s_addr = daddr->s_addr;
+	fw->ip.smsk.s_addr = smask->s_addr;
+	fw->ip.dmsk.s_addr = dmask->s_addr;
 
 	if (verbose)
 		print_firewall_line(fw, handle);
@@ -1988,8 +1990,8 @@ int do_command(int argc, char *argv[], char **table, struct iptc_handle **handle
 		break;
 	case CMD_REPLACE:
 		ret = replace_entry(chain, e, rulenum - 1,
-				    saddrs, daddrs, options&OPT_VERBOSE,
-				    *handle);
+				    saddrs, smasks, daddrs, dmasks,
+				    options&OPT_VERBOSE, *handle);
 		break;
 	case CMD_INSERT:
 		ret = insert_entry(chain, e, rulenum - 1,
-- 
1.6.5.2

[PATCH 2/3] doc: explain experienced --hitcount limit

[Jan Engelhardt]

Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
---
 extensions/libxt_recent.man |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/extensions/libxt_recent.man b/extensions/libxt_recent.man
index 9d5a64e..aa138df 100644
--- a/extensions/libxt_recent.man
+++ b/extensions/libxt_recent.man
@@ -44,7 +44,9 @@ This option must be used in conjunction with one of \fB\-\-rcheck\fP or
 address is in the list and packets had been received greater than or equal to
 the given value. This option may be used along with \fB\-\-seconds\fP to create
 an even narrower match requiring a certain number of hits within a specific
-time frame.
+time frame. The maximum value for the hitcount parameter is given by the
+"ip_pkt_list_tot" parameter of the xt_recent kernel module. Exceeding this
+value on the command line will cause the rule to be rejected.
 .TP
 \fB\-\-rttl\fP
 This option may only be used in conjunction with one of \fB\-\-rcheck\fP or
-- 
1.6.5.2

[PATCH 3/3] doc: name resolution clarification

[Jan Engelhardt]

Sometimes there are users who wonder about when name resolutions/DNS
queries are done, so let's add that for completeness.

Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
---
 ip6tables.8.in |   10 ++++++----
 iptables.8.in  |    8 +++++---
 2 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/ip6tables.8.in b/ip6tables.8.in
index 66d8543..5688133 100644
--- a/ip6tables.8.in
+++ b/ip6tables.8.in
@@ -240,10 +240,12 @@ option is omitted.
 .TP
 [\fB!\fP] \fB\-s\fP, \fB\-\-source\fP \fIaddress\fP[\fB/\fP\fImask\fP]
 Source specification.
-\fIAddress\fP can be either a hostname (please note that specifying
-any name to be resolved with a remote query such as DNS is a really bad idea),
-a network IPv6 address (with \fB/\fP\fImask\fP), or a plain IPv6 address.
-(the network name isn't supported now).
+\fIAddress\fP can be either be a hostname,
+a network IP address (with \fB/\fP\fImask\fP), or a plain IP address.
+Names will be resolved once only, before the rule is submitted to the kernel.
+Please note that specifying any name to be resolved with a remote query such as
+DNS is a really bad idea.
+(Resolving network names is not supported at this time.)
 The \fImask\fP is a plain number,
 specifying the number of 1's at the left side of the network mask.
 A "!" argument before the address specification inverts the sense of
diff --git a/iptables.8.in b/iptables.8.in
index 928f46a..d29deb2 100644
--- a/iptables.8.in
+++ b/iptables.8.in
@@ -239,9 +239,11 @@ option is omitted.
 .TP
 [\fB!\fP] \fB\-s\fP, \fB\-\-source\fP \fIaddress\fP[\fB/\fP\fImask\fP][\fB,\fP\fI...\fP]
 Source specification. \fIAddress\fP
-can be either a network name, a hostname (please note that specifying
-any name to be resolved with a remote query such as DNS is a really bad idea),
-a network IP address (with \fB/\fP\fImask\fP), or a plain IP address.
+can be either a network name, a hostname, a network IP address (with
+\fB/\fP\fImask\fP), or a plain IP address. Hostnames will
+be resolved once only, before the rule is submitted to the kernel.
+Please note that specifying any name to be resolved with a remote query such as
+DNS is a really bad idea.
 The \fImask\fP
 can be either a network mask or a plain number,
 specifying the number of 1's at the left side of the network mask.
-- 
1.6.5.2

Re: next iptables release

[Patrick McHardy]

Jan Engelhardt wrote:
> The following changes since commit 596c69007acb569843391e4c98dc21d6f2336e7b:
>   Patrick McHardy (1):
>         DNAT: fix incorrect check during parsing
> 
> are available in the git repository at:
> 
>   git://dev.medozas.de/iptables master
> 
> Jan Engelhardt (3):
>       iptables: take masks into consideration for replace command
>       doc: explain experienced --hitcount limit
>       doc: name resolution clarification

Looks good, pulled and pushed out again. Thanks Jan.

next iptables release

[Patrick McHardy]

The next iptables version (1.4.6) will be released shortly (an
estimated week or something like that). Please send any fixes
you would like to get in soon. Test results are also welcome :)

Thanks.

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 :)

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 :)