Skip to contentSkip to conversation

configure: Show support for connlabel

PATCH Superseded Shivani Bhardwaj 3 participants 9 messages Mar 7, 2016 – Mar 8, 2016 netfilter

v1 of 4 Superseded Latest is v4 →

lore
Share & tools
lore

Shivani Bhardwaj

author
#0 lore raw

PATCH 1/1 configure: Show support for connlabel

Add the --enable-connlabel option and show whether it is already supported.

After this patch, iptables configuration shows up as:

Iptables Configuration:
IPv4 support: yes
IPv6 support: yes
Devel support: yes
IPQ support: no
Large file support: yes
BPF utils support: no
nfsynproxy util support: no
nftables support: yes
connlabel support: yes

Signed-off-by Shivani Bhardwaj <[email protected]>
---
 configure.ac | 5 +++++
 1 file changed, 5 insertions(+)
configure.ac +5 -0
index 33a8f2d..c946d69 100644
@@ -63,6 +63,9 @@ AC_ARG_WITH([pkgconfigdir], AS_HELP_STRING([--with-pkgconfigdir=PATH],
 AC_ARG_ENABLE([nftables],
 	AS_HELP_STRING([--disable-nftables], [Do not build nftables compat]),
 	[enable_nftables="$enableval"], [enable_nftables="yes"])
+AC_ARG_ENABLE([connlabel],
+	AS_HELP_STRING([--enable-connlabel], [Build libnetfilter_conntrack]),
+	[enable_connlabel="$enableval"], [enable_connlabel="yes"])
 
 libiptc_LDFLAGS2="";
 AX_CHECK_LINKER_FLAGS([-Wl,--no-as-needed],

@@ -114,6 +117,7 @@ AM_CONDITIONAL([ENABLE_LIBIPQ], [test "$enable_libipq" = "yes"])
 AM_CONDITIONAL([ENABLE_BPFC], [test "$enable_bpfc" = "yes"])
 AM_CONDITIONAL([ENABLE_SYNCONF], [test "$enable_nfsynproxy" = "yes"])
 AM_CONDITIONAL([ENABLE_NFTABLES], [test "$enable_nftables" = "yes"])
+AM_CONDITIONAL([ENABLE_CONNLABEL], [test "$enable_connlabel" = "yes"])
 
 if test "x$enable_bpfc" = "xyes" || test "x$enable_nfsynproxy" = "xyes"; then
 	AC_CHECK_LIB(pcap, pcap_compile,, AC_MSG_ERROR(missing libpcap library required by bpf compiler or nfsynproxy tool))

@@ -243,6 +247,7 @@ Iptables Configuration:
   BPF utils support:			${enable_bpfc}
   nfsynproxy util support:		${enable_nfsynproxy}
   nftables support:			${enable_nftables}
+  connlabel support:			${enable_connlabel}
 
 Build parameters:
   Put plugins into executable (static):	${enable_static}
Signature · 1 line
1.9.1
maintainer
#1 lore raw
Quoted 26 lines · Shivani Bhardwaj

Add the --enable-connlabel option and show whether it is already supported.

After this patch, iptables configuration shows up as:

Iptables Configuration:
IPv4 support: yes
IPv6 support: yes
Devel support: yes
IPQ support: no
Large file support: yes
BPF utils support: no
nfsynproxy util support: no
nftables support: yes
connlabel support: yes

Signed-off-by Shivani Bhardwaj <[email protected]>
---
 configure.ac | 5 +++++
 1 file changed, 5 insertions(+)
configure.ac +0 -0
index 33a8f2d..c946d69 100644

configure.ac AC_ARG_WITH([pkgconfigdir], AS_HELP_STRING([--with-pkgconfigdir=PATH], · line 68

Quoted 6 lines
configure.ac +3 -0
@@ -63,6 +63,9 @@ AC_ARG_WITH([pkgconfigdir], AS_HELP_STRING([--with-pkgconfigdir=PATH],
 AC_ARG_ENABLE([nftables],
 	AS_HELP_STRING([--disable-nftables], [Do not build nftables compat]),
 	[enable_nftables="$enableval"], [enable_nftables="yes"])
+AC_ARG_ENABLE([connlabel],
+	AS_HELP_STRING([--enable-connlabel], [Build libnetfilter_conntrack]),
+	[enable_connlabel="$enableval"], [enable_connlabel="yes"])

I think there is still some missing code here. If the user requests connlabel but libnetfilter_conntrack (including the right version) is not available, then I would fail and display an error since the user is explicitly asking for this.

Otherwise, we can fall back on the existing behaviour: just lazy check if it's there and enable it in that case. If the library is not present, just skip this.

The --disable-connlabel should also work, in that case, we should skip adding support for this.

Can you look into fitting this logic into this? Thanks.

Quoted 25 lines
configure.ac +2 -0
 libiptc_LDFLAGS2="";
 AX_CHECK_LINKER_FLAGS([-Wl,--no-as-needed],

@@ -114,6 +117,7 @@ AM_CONDITIONAL([ENABLE_LIBIPQ], [test "$enable_libipq" = "yes"])
 AM_CONDITIONAL([ENABLE_BPFC], [test "$enable_bpfc" = "yes"])
 AM_CONDITIONAL([ENABLE_SYNCONF], [test "$enable_nfsynproxy" = "yes"])
 AM_CONDITIONAL([ENABLE_NFTABLES], [test "$enable_nftables" = "yes"])
+AM_CONDITIONAL([ENABLE_CONNLABEL], [test "$enable_connlabel" = "yes"])
 
 if test "x$enable_bpfc" = "xyes" || test "x$enable_nfsynproxy" = "xyes"; then
 	AC_CHECK_LIB(pcap, pcap_compile,, AC_MSG_ERROR(missing libpcap library required by bpf compiler or nfsynproxy tool))

@@ -243,6 +247,7 @@ Iptables Configuration:
   BPF utils support:			${enable_bpfc}
   nfsynproxy util support:		${enable_nfsynproxy}
   nftables support:			${enable_nftables}
+  connlabel support:			${enable_connlabel}
 
 Build parameters:
   Put plugins into executable (static):	${enable_static}
Signature · 6 lines
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
author
#2 lore raw
Quoted 39 lines · Pablo Neira Ayuso
Quoted 26 lines · Shivani Bhardwaj

Add the --enable-connlabel option and show whether it is already supported.

After this patch, iptables configuration shows up as:

Iptables Configuration:
IPv4 support: yes
IPv6 support: yes
Devel support: yes
IPQ support: no

  Large file support:                 yes
  BPF utils support:                  no
  nfsynproxy util support:            no
  nftables support:                   yes
  connlabel support:                  yes
Signed-off-by Shivani Bhardwaj <[email protected]>
---
 configure.ac | 5 +++++
 1 file changed, 5 insertions(+)
configure.ac +0 -0
index 33a8f2d..c946d69 100644

configure.ac AC_ARG_WITH([pkgconfigdir], AS_HELP_STRING([--with-pkgconfigdir=PATH], · line 68

Quoted 6 lines
configure.ac +3 -0
@@ -63,6 +63,9 @@ AC_ARG_WITH([pkgconfigdir], AS_HELP_STRING([--with-pkgconfigdir=PATH],
 AC_ARG_ENABLE([nftables],
      AS_HELP_STRING([--disable-nftables], [Do not build nftables compat]),
      [enable_nftables="$enableval"], [enable_nftables="yes"])
+AC_ARG_ENABLE([connlabel],
+     AS_HELP_STRING([--enable-connlabel], [Build libnetfilter_conntrack]),
+     [enable_connlabel="$enableval"], [enable_connlabel="yes"])

I think there is still some missing code here. If the user requests connlabel but libnetfilter_conntrack (including the right version) is not available, then I would fail and display an error since the user is explicitly asking for this.

Quoted 9 lines

Otherwise, we can fall back on the existing behaviour: just lazy check if it's there and enable it in that case. If the library is not present, just skip this.

The --disable-connlabel should also work, in that case, we should skip adding support for this.

Can you look into fitting this logic into this? Thanks.

Yes, I'll do that.
I need a bit of help here.
I followed some other modules for which support has been mentioned. For example, libipq
When I first ran the configure script, it turned out
IPQ support: no

I did next time with the option --enable-libipq
As expected,
IPQ support: yes

But, I tried writing the output of both these cases to files and when I looked up for difference between the two, turned out only this IPQ support line was different among them, in any case following was shown

config.status: creating libipq/Makefile
config.status: creating libipq/libipq.pc

(because this is a part of AC_CONFIG_FILES)

I do not see any code associated with libipq in configure.ac. May be I'm not understanding how these options are working, could you please clarify a bit?

Thank you.

Quoted 25 lines
Quoted 25 lines
configure.ac +2 -1
 libiptc_LDFLAGS2="";
 AX_CHECK_LINKER_FLAGS([-Wl,--no-as-needed],

@@ -114,6 +117,7 @@ AM_CONDITIONAL([ENABLE_LIBIPQ], [test "$enable_libipq" = "yes"])
 AM_CONDITIONAL([ENABLE_BPFC], [test "$enable_bpfc" = "yes"])
 AM_CONDITIONAL([ENABLE_SYNCONF], [test "$enable_nfsynproxy" = "yes"])
 AM_CONDITIONAL([ENABLE_NFTABLES], [test "$enable_nftables" = "yes"])
+AM_CONDITIONAL([ENABLE_CONNLABEL], [test "$enable_connlabel" = "yes"])
 
 if test "x$enable_bpfc" = "xyes" || test "x$enable_nfsynproxy" = "xyes"; then
      AC_CHECK_LIB(pcap, pcap_compile,, AC_MSG_ERROR(missing libpcap library required by bpf compiler or nfsynproxy tool))

@@ -243,6 +247,7 @@ Iptables Configuration:
   BPF utils support:                 ${enable_bpfc}
   nfsynproxy util support:           ${enable_nfsynproxy}
   nftables support:                  ${enable_nftables}
+  connlabel support:                 ${enable_connlabel}
 
 Build parameters:
   Put plugins into executable (static):      ${enable_static}
--

1.9.1

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

maintainer
#3 lore raw
Quoted 64 lines · Shivani Bhardwaj
Quoted 39 lines · Pablo Neira Ayuso
Quoted 26 lines · Shivani Bhardwaj

Add the --enable-connlabel option and show whether it is already supported.

After this patch, iptables configuration shows up as:

Iptables Configuration:
IPv4 support: yes
IPv6 support: yes
Devel support: yes
IPQ support: no

  Large file support:                 yes
  BPF utils support:                  no
  nfsynproxy util support:            no
  nftables support:                   yes
  connlabel support:                  yes
Signed-off-by Shivani Bhardwaj <[email protected]>
---
 configure.ac | 5 +++++
 1 file changed, 5 insertions(+)
configure.ac +0 -0
index 33a8f2d..c946d69 100644

configure.ac AC_ARG_WITH([pkgconfigdir], AS_HELP_STRING([--with-pkgconfigdir=PATH], · line 68

Quoted 6 lines
configure.ac +3 -0
@@ -63,6 +63,9 @@ AC_ARG_WITH([pkgconfigdir], AS_HELP_STRING([--with-pkgconfigdir=PATH],
 AC_ARG_ENABLE([nftables],
      AS_HELP_STRING([--disable-nftables], [Do not build nftables compat]),
      [enable_nftables="$enableval"], [enable_nftables="yes"])
+AC_ARG_ENABLE([connlabel],
+     AS_HELP_STRING([--enable-connlabel], [Build libnetfilter_conntrack]),
+     [enable_connlabel="$enableval"], [enable_connlabel="yes"])

I think there is still some missing code here. If the user requests connlabel but libnetfilter_conntrack (including the right version) is not available, then I would fail and display an error since the user is explicitly asking for this.

Quoted 9 lines

Otherwise, we can fall back on the existing behaviour: just lazy check if it's there and enable it in that case. If the library is not present, just skip this.

The --disable-connlabel should also work, in that case, we should skip adding support for this.

Can you look into fitting this logic into this? Thanks.

Yes, I'll do that.
I need a bit of help here.
I followed some other modules for which support has been mentioned. For example, libipq
When I first ran the configure script, it turned out
IPQ support: no

I did next time with the option --enable-libipq
As expected,
IPQ support: yes

But, I tried writing the output of both these cases to files and when I looked up for difference between the two, turned out only this IPQ support line was different among them, in any case following was shown

Quoted 8 lines

config.status: creating libipq/Makefile
config.status: creating libipq/libipq.pc

(because this is a part of AC_CONFIG_FILES)

I do not see any code associated with libipq in configure.ac. May be I'm not understanding how these options are working, could you please clarify a bit?

Those are the userspace bits for the old ip_queue support that was removed years ago, since NFQUEUE superseded for many years.

commit d16cf20e2f2f13411eece7f7fb72c17d141c4a84

Author: Pablo Neira Ayuso <[email protected]>
Date:   Tue May 8 19:45:28 2012 +0200

netfilter: remove ip_queue support

You can still cd iptables/libipq and type 'make' to compile the this small userspace library since we have to keep new iptables releases running with old kernels.

maintainer
#4 lore raw
Quoted 29 lines · Pablo Neira Ayuso
Quoted 15 lines · Shivani Bhardwaj

Yes, I'll do that.
I need a bit of help here.
I followed some other modules for which support has been mentioned. For example, libipq
When I first ran the configure script, it turned out
IPQ support: no

I did next time with the option --enable-libipq
As expected,
IPQ support: yes

But, I tried writing the output of both these cases to files and when I looked up for difference between the two, turned out only this IPQ support line was different among them, in any case following was shown

Quoted 8 lines

config.status: creating libipq/Makefile
config.status: creating libipq/libipq.pc

(because this is a part of AC_CONFIG_FILES)

I do not see any code associated with libipq in configure.ac. May be I'm not understanding how these options are working, could you please clarify a bit?

Those are the userspace bits for the old ip_queue support that was removed years ago, since NFQUEUE superseded for many years.

commit d16cf20e2f2f13411eece7f7fb72c17d141c4a84

Quoted 8 lines
Author: Pablo Neira Ayuso <[email protected]>
Date:   Tue May 8 19:45:28 2012 +0200

netfilter: remove ip_queue support

You can still cd iptables/libipq and type 'make' to compile the this small userspace library since we have to keep new iptables releases running with old kernels.

Oh sorry, now I see.

This is always compiling libipq even with --disable-libipq, this looks like a bug in our build infrastructure.

author
#5 lore raw
Quoted 35 lines · Pablo Neira Ayuso
Quoted 34 lines · Pablo Neira Ayuso
Quoted 15 lines · Shivani Bhardwaj

Yes, I'll do that.
I need a bit of help here.
I followed some other modules for which support has been mentioned. For example, libipq
When I first ran the configure script, it turned out
IPQ support: no

I did next time with the option --enable-libipq
As expected,
IPQ support: yes

But, I tried writing the output of both these cases to files and when I looked up for difference between the two, turned out only this IPQ support line was different among them, in any case following was shown

Quoted 8 lines

config.status: creating libipq/Makefile
config.status: creating libipq/libipq.pc

(because this is a part of AC_CONFIG_FILES)

I do not see any code associated with libipq in configure.ac. May be I'm not understanding how these options are working, could you please clarify a bit?

Those are the userspace bits for the old ip_queue support that was removed years ago, since NFQUEUE superseded for many years.

commit d16cf20e2f2f13411eece7f7fb72c17d141c4a84

Author: Pablo Neira Ayuso <[email protected]>
Date:   Tue May 8 19:45:28 2012 +0200

netfilter: remove ip_queue support

Quoted 8 lines
Quoted 3 lines

You can still cd iptables/libipq and type 'make' to compile the this small userspace library since we have to keep new iptables releases running with old kernels.

Oh sorry, now I see.

This is always compiling libipq even with --disable-libipq, this looks like a bug in our build infrastructure.

Yes. Also, I see that devel should have --disable-devel instead of --enable-devel option and the appropriate functionality associated with it. Please correct me if I am wrong here.

maintainer
#6 lore raw
Quoted 40 lines · Shivani Bhardwaj
Quoted 39 lines · Pablo Neira Ayuso
Quoted 37 lines · Pablo Neira Ayuso
Quoted 15 lines · Shivani Bhardwaj

Yes, I'll do that.
I need a bit of help here.
I followed some other modules for which support has been mentioned. For example, libipq
When I first ran the configure script, it turned out
IPQ support: no

I did next time with the option --enable-libipq
As expected,
IPQ support: yes

But, I tried writing the output of both these cases to files and when I looked up for difference between the two, turned out only this IPQ support line was different among them, in any case following was shown

Quoted 8 lines

config.status: creating libipq/Makefile
config.status: creating libipq/libipq.pc

(because this is a part of AC_CONFIG_FILES)

I do not see any code associated with libipq in configure.ac. May be I'm not understanding how these options are working, could you please clarify a bit?

Those are the userspace bits for the old ip_queue support that was removed years ago, since NFQUEUE superseded for many years.

commit d16cf20e2f2f13411eece7f7fb72c17d141c4a84

Author: Pablo Neira Ayuso <[email protected]>
Date:   Tue May 8 19:45:28 2012 +0200

netfilter: remove ip_queue support

You can still cd iptables/libipq and type 'make' to compile the this small userspace library since we have to keep new iptables releases running with old kernels.

Quoted 8 lines
Quoted 4 lines

Oh sorry, now I see.

This is always compiling libipq even with --disable-libipq, this looks like a bug in our build infrastructure.

Yes. Also, I see that devel should have --disable-devel instead of --enable-devel option and the appropriate functionality associated with it. Please correct me if I am wrong here.

So is --disable-devel also broken / being ignored? If so, that also needs a fix, yes.

#7 lore raw
Quoted 8 lines · Pablo Neira Ayuso
Quoted 8 lines
Quoted 8 lines
Quoted 5 lines

Those are the userspace bits for the old ip_queue support that was removed years ago, since NFQUEUE superseded for many years. You can still cd iptables/libipq and type 'make' to compile the this small userspace library since we have to keep new iptables releases running with old kernels.

This is always compiling libipq even with --disable-libipq, this looks like a bug in our build infrastructure.

If you manually and intentionally chdir to libipq and attempt to built it, why forbid it? Having "if ENABLE_LIBIPQ" in the toplevel Makefile.am seems sufficient.

AS_HELP_STRING([--enable-libipq], [Build and install libipq]) in configure.ac is also right, since ipq is build-disabled by default.

Quoted 3 lines
Quoted 3 lines

Yes. Also, I see that devel should have --disable-devel instead of --enable-devel option and the appropriate functionality associated with it. Please correct me if I am wrong here.

The help texts:
AS_HELP_STRING([--enable-devel], [Install Xtables development headers]) should indeed read
AS_HELP_STRING([--disable-devel], [Avoid installation of Xtables development headers]) because headers are build-*enabled* by default.

But the actual option parsing (--enable-devel, --enable-devel=no, --disable-devel) that AC_ARG_ENABLE provides needs no change AFAICS.

maintainer
#8 lore raw
Quoted 8 lines · Jan Engelhardt
Quoted 6 lines · Pablo Neira Ayuso
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines

Those are the userspace bits for the old ip_queue support that was removed years ago, since NFQUEUE superseded for many years. You can still cd iptables/libipq and type 'make' to compile the this small userspace library since we have to keep new iptables releases running with old kernels.

Quoted 6 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines

This is always compiling libipq even with --disable-libipq, this looks like a bug in our build infrastructure.

If you manually and intentionally chdir to libipq and attempt to built it, why forbid it? Having "if ENABLE_LIBIPQ" in the toplevel Makefile.am seems sufficient.

That top level "if ENABLE_LIBIPQ" seems fine, I overlooked this.

Quoted 7 lines

AS_HELP_STRING([--enable-libipq], [Build and install libipq]) in configure.ac is also right, since ipq is build-disabled by default.

Quoted 3 lines
Quoted 3 lines

Yes. Also, I see that devel should have --disable-devel instead of --enable-devel option and the appropriate functionality associated with it. Please correct me if I am wrong here.

Quoted 8 lines

The help texts:
AS_HELP_STRING([--enable-devel], [Install Xtables development headers]) should indeed read
AS_HELP_STRING([--disable-devel], [Avoid installation of Xtables development headers]) because headers are build-*enabled* by default.

But the actual option parsing (--enable-devel, --enable-devel=no, --disable-devel) that AC_ARG_ENABLE provides needs no change AFAICS.

Right, this is also controled via top level Makefile.am.

@Shivani, please focus on improving connlabel integration into our configure thing.