[PATCH] configure: Show support for connlabel

[PATCH] configure: Show support for connlabel

[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 <shivanib134@gmail.com>
---
 configure.ac | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/configure.ac b/configure.ac
index 33a8f2d..c946d69 100644
--- a/configure.ac
+++ b/configure.ac
@@ -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}
-- 
1.9.1

Re: [PATCH] configure: Show support for connlabel

[Pablo Neira Ayuso]

On Mon, Mar 07, 2016 at 02:44:47PM +0530, Shivani Bhardwaj wrote:
> 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 <shivanib134@gmail.com>
> ---
>  configure.ac | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/configure.ac b/configure.ac
> index 33a8f2d..c946d69 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -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.

>  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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] configure: Show support for connlabel

[Shivani Bhardwaj]

On Mon, Mar 7, 2016 at 7:39 PM, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> On Mon, Mar 07, 2016 at 02:44:47PM +0530, Shivani Bhardwaj wrote:
>> 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 <shivanib134@gmail.com>
>> ---
>>  configure.ac | 5 +++++
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/configure.ac b/configure.ac
>> index 33a8f2d..c946d69 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -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.
>
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.

>>  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 majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] configure: Show support for connlabel

[Pablo Neira Ayuso]

On Mon, Mar 07, 2016 at 11:05:15PM +0530, Shivani Bhardwaj wrote:
> On Mon, Mar 7, 2016 at 7:39 PM, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > On Mon, Mar 07, 2016 at 02:44:47PM +0530, Shivani Bhardwaj wrote:
> >> 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 <shivanib134@gmail.com>
> >> ---
> >>  configure.ac | 5 +++++
> >>  1 file changed, 5 insertions(+)
> >>
> >> diff --git a/configure.ac b/configure.ac
> >> index 33a8f2d..c946d69 100644
> >> --- a/configure.ac
> >> +++ b/configure.ac
> >> @@ -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.
> >
> 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?

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 <pablo@netfilter.org>
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.

Re: [PATCH] configure: Show support for connlabel

[Pablo Neira Ayuso]

On Mon, Mar 07, 2016 at 06:56:46PM +0100, Pablo Neira Ayuso wrote:
> On Mon, Mar 07, 2016 at 11:05:15PM +0530, Shivani Bhardwaj wrote:
> > 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?
> 
> 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 <pablo@netfilter.org>
> 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.

Re: [PATCH] configure: Show support for connlabel

[Shivani Bhardwaj]

On Mon, Mar 7, 2016 at 11:30 PM, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> On Mon, Mar 07, 2016 at 06:56:46PM +0100, Pablo Neira Ayuso wrote:
>> On Mon, Mar 07, 2016 at 11:05:15PM +0530, Shivani Bhardwaj wrote:
>> > 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?
>>
>> 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 <pablo@netfilter.org>
>> 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.

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.

Re: [PATCH] configure: Show support for connlabel

[Pablo Neira Ayuso]

On Mon, Mar 07, 2016 at 11:36:33PM +0530, Shivani Bhardwaj wrote:
> On Mon, Mar 7, 2016 at 11:30 PM, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > On Mon, Mar 07, 2016 at 06:56:46PM +0100, Pablo Neira Ayuso wrote:
> >> On Mon, Mar 07, 2016 at 11:05:15PM +0530, Shivani Bhardwaj wrote:
> >> > 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?
> >>
> >> 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 <pablo@netfilter.org>
> >> 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.
> 
> 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.

Re: [PATCH] configure: Show support for connlabel

[Jan Engelhardt]

On Tuesday 2016-03-08 14:37, Pablo Neira Ayuso wrote:
>>>> 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.

>> 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.

Re: [PATCH] configure: Show support for connlabel

[Pablo Neira Ayuso]

On Tue, Mar 08, 2016 at 02:47:13PM +0100, Jan Engelhardt wrote:
> 
> On Tuesday 2016-03-08 14:37, Pablo Neira Ayuso wrote:
> >>>> 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.

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

> AS_HELP_STRING([--enable-libipq], [Build and install libipq])
> in configure.ac is also right, since ipq is build-disabled by default.
> 
> >> 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.

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

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