conntrack-tools 0.9.11 released

ANNOUNCE Pablo Neira Ayuso 3 participants 10 messages Feb 21, 2009 – Feb 24, 2009 netfilter

Share & tools

Pablo Neira Ayuso

author maintainer

2009-02-21 17:40 UTC #0 lore raw

Hi!

The netfilter project presents another development release of the conntrack-tools that includes accumulated fixes, one improvement for the polling approach and a couple of new features, mainly:

= command line interface: conntrack =

* Allow use of -D with -p proto --state to delete entries in a certain protocol state.

= userspace daemon: conntrackd =

* Fix endianess issue in the network header used in the synchronization
messages: this fix breaks backward protocol compatibility. Thus, you cannot use conntrackd 0.9.11 with a different daemon version <= 0.9.10.

* Add Nice clause to set the nice value of the daemon: setting a lower nice value reduces the chance to lose state-change events over netlink.

* Improved polling (or batch-based) synchronization: this feature was introduced in the previous release, you can configure the daemon to send batches periodically instead of the soft real-time state synchronization. This allows you to set up a relaxed replication while consuming less computational resources. See `PollSecs' clause.

* Add NetlinkOverrunResync clause: this feature allows disabling/enabling the automatic re-synchronization when the daemon notices that is losing state-change events.

Q: How stable are the conntrack-tools?
A: This software is under development. Nevertheless, it has been tested in a cluster environment composed of two stateful firewalls running Debian 4.0 (Etch) with a Linux kernel 2.6.28, keepalived 1.1.15, using conntrackd in FT-FW mode, randomly (in periods of 10 seconds) setting links down to force the fail-over between the nodes. The results has shown no hangs/closure in any TCP connection.

Q: What are the conntrack-tools?
A: The conntrack-tools are:

- The userspace daemon so-called conntrackd that covers the specific aspects of stateful Linux firewalls to enable high availability solutions. It can be used as statistics collector of the firewall use as well. The daemon is highly configurable and easily extensible.

- The command line interface (CLI) conntrack that provides an interface to add, delete and update flow entries, list current active flows in plain text/XML, current IPv4 NAT'ed flows, reset counters, and flush the complete connection tracking table among many other.

Q: Where can I download it from?
A: http://www.netfilter.org/projects/conntrack-tools/downloads.html

Q: Where can I get more information about them?
A: http://conntrack-tools.netfilter.org

Q: Where can I have a look at the user manual?
A: http://conntrack-tools.netfilter.org/manual.html

On behalf of the Netfilter Project,
Pablo.

Signature · 1 line

"Los honestos son inadaptados sociales" -- Les Luthiers

Jan Engelhardt (1):
build: upgrade build system

Pablo Neira Ayuso (26):
build: replace INCLUDES by AM_CPPFLAGS according to autoreconf
configure: conntrack-tools >= 0.9.10 requires libnfnetlink >= 0.0.40
netlink: refactorize several nl_init_*_handler() functions
src: re-work polling strategy
netlink: add new option NetlinkOverrunResync
sync-mode: flush also internal cache after reset PurgeTimeout
conntrack: allow use of --state with -D
src: add Nice clause to set the nice value
config: nl_overrun must be signed int instead of unsigned
cache_iterators: fix wrong printf format in commit-time message
src: use resync handler for polling instead of dump handler
stats-mode: fix polling based logging
conntrackd: add -f internal' and -f external' options
conntrackd: display help information with `-h'
conntrackd: don't initialize logging for client request
doc: unset ACKWindowSize in example configuration files
doc: add bulk update to primary-script.sh script
headers: don't use NFCT_DIR_MAX in statistics structure
network: fix endianess issue in synchronization network header
network: fix endianess issue in acknowledgment network header
sync-mode: change current link if message is correct
src: remove obsolete debug() and debug_ct() calls
mcast: fix compilation warning due missing header
config: add NetlinkBufferSize and NetlinkBufferSizeMaxGrowth
netlink: use u8 getter for TCP states
build: bump version to 0.9.11

Robby Workman

2009-02-23 05:34 UTC #1 lore raw

Quoted 2 lines · On Sat, 21 Feb 2009 18:40:03 +0100 Pablo Neira Ayuso <[email protected]>…

The netfilter project presents another development release of the conntrack-tools...

Hi Pablo,

I thought I recalled seeing discussion about this already, but I don't
see it in my archives, so maybe not. With glibc-2.7, this release
builds fine; however, with glibc-2.9, both src/mcast.c and src/sync-mode.c need limits.h included, or else INT_MAX is undefined.

-RW

Jan Engelhardt

2009-02-23 07:17 UTC #2 lore raw

Quoted 10 lines · Robby Workman

Quoted 2 lines · On Sat, 21 Feb 2009 18:40:03 +0100 Pablo Neira Ayuso <[email protected]>…
The netfilter project presents another development release of the conntrack-tools...
I thought I recalled seeing discussion about this already, but I don't
see it in my archives, so maybe not. With glibc-2.7, this release
builds fine; however, with glibc-2.9, both src/mcast.c and src/sync-mode.c need limits.h included, or else INT_MAX is undefined.

This builds fine for me - and I am on glibc 2.9. Just *what* is it in (which distro? Debian/Ubuntu again?) again to constantly fail on INT_MAX?

Pablo Neira Ayuso

author maintainer

2009-02-23 09:19 UTC #3 lore raw

Quoted 6 lines · Jan Engelhardt

Quoted 5 lines · Robby Workman
Quoted 2 lines · On Sat, 21 Feb 2009 18:40:03 +0100 Pablo Neira Ayuso <[email protected]>…
The netfilter project presents another development release of the conntrack-tools...

Quoted 8 lines

Quoted 4 lines
I thought I recalled seeing discussion about this already, but I don't
see it in my archives, so maybe not. With glibc-2.7, this release
builds fine; however, with glibc-2.9, both src/mcast.c and src/sync-mode.c need limits.h included, or else INT_MAX is undefined.
This builds fine for me - and I am on glibc 2.9. Just *what* is it in (which distro? Debian/Ubuntu again?) again to constantly fail on INT_MAX?

Indeed. This also compiles fine for me in debian. I have committed a patch for this [1]. This issue is unfortunate. Gentoo bugzilla on conntrack-tools had a patch but nobody has sent it to me. I notice it after the release.

[1]
http://git.netfilter.org/cgi-bin/gitweb.cgi?p=conntrack-tools.git;a=commit;h=9bf002ff7935e7dff625683787fc3a06ac2ef2cb

Signature · 1 line

"Los honestos son inadaptados sociales" -- Les Luthiers

Robby Workman

2009-02-23 15:34 UTC #4 lore raw

Quoted 17 lines · On Mon, 23 Feb 2009 10:19:58 +0100 Pablo Neira Ayuso <[email protected]>…

Quoted 12 lines · Jan Engelhardt
Quoted 10 lines · Robby Workman
Quoted 2 lines · On Sat, 21 Feb 2009 18:40:03 +0100 Pablo Neira Ayuso <[email protected]>…
The netfilter project presents another development release of the conntrack-tools...
I thought I recalled seeing discussion about this already, but I
don't see it in my archives, so maybe not. With glibc-2.7, this
release builds fine; however, with glibc-2.9, both src/mcast.c and src/sync-mode.c need limits.h included, or else INT_MAX is undefined.
Quoted 3 lines
This builds fine for me - and I am on glibc 2.9. Just *what* is it in (which distro? Debian/Ubuntu again?) again to constantly fail on INT_MAX?

Quoted 7 lines

Indeed. This also compiles fine for me in debian. I have committed a patch for this [1]. This issue is unfortunate. Gentoo bugzilla on conntrack-tools had a patch but nobody has sent it to me. I notice it after the release.
[1]
http://git.netfilter.org/cgi-bin/gitweb.cgi?p=conntrack-tools.git;a=commit;h=9bf002ff7935e7dff625683787fc3a06ac2ef2cb

Weird that it's not affecting Jan then, because it's definitely something specific to newer glibc (or perhaps gcc, but it's not immediately obvious how that would be the case). I'm on Slackware rather than Gentoo, running quite a bit of prerelease development builds (including gcc-4.3.3 and glibc-2.9 along with 2.6.28.7 kernel).

-RW

Jan Engelhardt

2009-02-23 16:55 UTC #5 lore raw

Quoted 18 lines · Robby Workman

Quoted 6 lines · On Mon, 23 Feb 2009 10:19:58 +0100 Pablo Neira Ayuso <[email protected]>…
Quoted 6 lines
Quoted 5 lines
I thought I recalled seeing discussion about this already, but I
don't see it in my archives, so maybe not. With glibc-2.7, this
release builds fine; however, with glibc-2.9, both src/mcast.c and src/sync-mode.c need limits.h included, or else INT_MAX is undefined.
Quoted 8 lines
Quoted 3 lines
This builds fine for me - and I am on glibc 2.9. Just *what* is it in (which distro? Debian/Ubuntu again?) again to constantly fail on INT_MAX?
Indeed. This also compiles fine for me in debian. I have committed a patch for this [1]. This issue is unfortunate. Gentoo bugzilla on conntrack-tools had a patch but nobody has sent it to me. I notice it after the release.

Quoted 5 lines

Weird that it's not affecting Jan then, because it's definitely something specific to newer glibc (or perhaps gcc, but it's not immediately obvious how that would be the case). I'm on Slackware rather than Gentoo, running quite a bit of prerelease development builds (including gcc-4.3.3 and glibc-2.9 along with 2.6.28.7 kernel).

gcc [long command line as spouted by make] -E mcast.c | grep '^#'

After hand-filtering, the apparent sequence is:

# 5 "../include/mcast.h" 2
# 1 "/usr/include/netinet/in.h" 1 3 4
# 1 "/usr/include/sys/socket.h" 1 3 4
# 31 "/usr/include/bits/socket.h" 2 3 4
# 1 "/usr/lib64/gcc/x86_64-suse-linux/4.3/include-fixed/limits.h" 1 3 4

so <limits.h> is included via <bits/socket.h> is included via <sys/socket.h> etc. How is your stack trace?

Robby Workman

2009-02-24 03:02 UTC #6 lore raw

Quoted 38 lines · On Mon, 23 Feb 2009 17:55:07 +0100 (CET) Jan Engelhardt <[email protected]>…

Quoted 18 lines · Robby Workman
Quoted 6 lines · On Mon, 23 Feb 2009 10:19:58 +0100 Pablo Neira Ayuso <[email protected]>…
Quoted 6 lines
Quoted 5 lines
I thought I recalled seeing discussion about this already, but I
don't see it in my archives, so maybe not. With glibc-2.7,
this release builds fine; however, with glibc-2.9, both src/mcast.c and src/sync-mode.c need limits.h included, or else INT_MAX is undefined.
Quoted 8 lines
Quoted 3 lines
This builds fine for me - and I am on glibc 2.9. Just *what* is it in (which distro? Debian/Ubuntu again?) again to constantly fail on INT_MAX?
Indeed. This also compiles fine for me in debian. I have committed a patch for this [1]. This issue is unfortunate. Gentoo bugzilla on conntrack-tools had a patch but nobody has sent it to me. I notice it after the release.
Quoted 6 lines
Weird that it's not affecting Jan then, because it's definitely something specific to newer glibc (or perhaps gcc, but it's not immediately obvious how that would be the case). I'm on Slackware rather than Gentoo, running quite a bit of prerelease development builds (including gcc-4.3.3 and glibc-2.9 along with 2.6.28.7 kernel).
gcc [long command line as spouted by make] -E mcast.c | grep '^#'
After hand-filtering, the apparent sequence is:
# 5 "../include/mcast.h" 2
# 1 "/usr/include/netinet/in.h" 1 3 4
# 1 "/usr/include/sys/socket.h" 1 3 4
# 31 "/usr/include/bits/socket.h" 2 3 4
# 1 "/usr/lib64/gcc/x86_64-suse-linux/4.3/include-fixed/limits.h" 1 3 4

Quoted 2 lines

so <limits.h> is included via <bits/socket.h> is included via <sys/socket.h> etc. How is your stack trace?

Not happening that way here (and bits.h indeed does not include limits.h) - see attached plaintext...

Jan Engelhardt

2009-02-24 09:59 UTC #7 lore raw

Quoted 2 lines · Robby Workman

Not happening that way here (and bits.h indeed does not include limits.h) - see attached plaintext...

Mystery solved.

[glibc.rpm changelog]
* Thu Apr 10 2008 [email protected]
- Temporarily revert a namespace leakage cleanup in glibc-2.8 since it causes a lot of build failures

unix/sysv/linux/bits/socket.h +2 -0

@@ -26,8 +26,10 @@
 #endif   
 
 #define        __need_size_t  
+#define __need_NULL
 #include <stddef.h>
 
+#include <limits.h>
 #include <sys/types.h>
 
 /* Type for length arguments in socket calls.  */

Pablo Neira Ayuso

author maintainer

2009-02-24 09:55 UTC #8 lore raw

In reply to Robby Workman

Quoted 27 lines · Robby Workman

Quoted 15 lines · On Mon, 23 Feb 2009 10:19:58 +0100 Pablo Neira Ayuso <[email protected]>…
Quoted 6 lines · Jan Engelhardt
Quoted 5 lines · Robby Workman
Quoted 2 lines · On Sat, 21 Feb 2009 18:40:03 +0100 Pablo Neira Ayuso <[email protected]>…
The netfilter project presents another development release of the conntrack-tools...
Quoted 8 lines
Quoted 5 lines
I thought I recalled seeing discussion about this already, but I
don't see it in my archives, so maybe not. With glibc-2.7, this
release builds fine; however, with glibc-2.9, both src/mcast.c and src/sync-mode.c need limits.h included, or else INT_MAX is undefined.
This builds fine for me - and I am on glibc 2.9. Just *what* is it in (which distro? Debian/Ubuntu again?) again to constantly fail on INT_MAX?
Quoted 7 lines
Indeed. This also compiles fine for me in debian. I have committed a patch for this [1]. This issue is unfortunate. Gentoo bugzilla on conntrack-tools had a patch but nobody has sent it to me. I notice it after the release.
[1]
http://git.netfilter.org/cgi-bin/gitweb.cgi?p=conntrack-tools.git;a=commit;h=9bf002ff7935e7dff625683787fc3a06ac2ef2cb

Quoted 5 lines

Weird that it's not affecting Jan then, because it's definitely something specific to newer glibc (or perhaps gcc, but it's not immediately obvious how that would be the case). I'm on Slackware rather than Gentoo, running quite a bit of prerelease development builds (including gcc-4.3.3 and glibc-2.9 along with 2.6.28.7 kernel).

I'm don't mind too much as long as the following patch (which is already in git to fix the gentoo's problem) fixes also yours:

http://git.netfilter.org/cgi-bin/gitweb.cgi?p=conntrack-tools.git;a=commitdiff;h=9bf002ff7935e7dff625683787fc3a06ac2ef2cb;hp=87c8c090e1b64eac27edb968845cb1e8ee65b06b

Please, confirm that the problem is resolved.

Signature · 1 line

"Los honestos son inadaptados sociales" -- Les Luthiers

Robby Workman

2009-02-24 14:10 UTC #9 lore raw

Quoted 9 lines · On Tue, 24 Feb 2009 10:55:10 +0100 Pablo Neira Ayuso <[email protected]>…

Quoted 7 lines · Robby Workman
Weird that it's not affecting Jan then, because it's definitely something specific to newer glibc (or perhaps gcc, but it's not immediately obvious how that would be the case). I'm on Slackware rather than Gentoo, running quite a bit of prerelease development builds (including gcc-4.3.3 and glibc-2.9 along with 2.6.28.7 kernel).

Quoted 6 lines

I'm don't mind too much as long as the following patch (which is already in git to fix the gentoo's problem) fixes also yours:
http://git.netfilter.org/cgi-bin/gitweb.cgi?p=conntrack-tools.git;a=commitdiff;h=9bf002ff7935e7dff625683787fc3a06ac2ef2cb;hp=87c8c090e1b64eac27edb968845cb1e8ee65b06b
Please, confirm that the problem is resolved.

Yes, that's exactly what I did locally to fix it -- confirmed.

-RW