Netfilter API and libiptc

Netfilter API and libiptc

[Ignacy Gawedzki]

Hi everybody,

I'm currently working on a project that relies on manipulation of iptables in
order to perform fine data packet accounting.  This manipulation is performed
dynamically, so the code initially used libiptc.

Since iptables 1.4.0, libiptc is not distributed anymore, so I resolved to
incorporate the code into our own source distribution, just as people from
collectd seemingly did.  All seemed to work well until yesterday, when we
eventually pinpointed our calls to the (internal) libiptc as a cause of a
kernel freeze.  It only happened on a generic Ubuntu Hardy kernel
(2.6.24-22-generic) on one particular laptop (I didn't succeed in reproducing
the freeze on another hardware with the same distribution).  I suppose it has
something to do with the change of the format of data flowing to kernelspace
(iptables 1.3.8 came distributed on that freezing machine), could anyone here
confirm that this is possible indeed?

Now my question is: how are we supposed to proceed from now on in order to
manipulate iptables?  I read about libxtables and the corresponding libxtc.h
(though these are not yet packaged in the current Ubuntu Intrepid), but it's
not clear to me how the communication with the kernel is actually to be done.

Thanks for any information that could help me making this work properly.

Ignacy

-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: Netfilter API and libiptc

[Patrick McHardy]

Ignacy Gawedzki wrote:
> Hi everybody,
> 
> I'm currently working on a project that relies on manipulation of iptables in
> order to perform fine data packet accounting.  This manipulation is performed
> dynamically, so the code initially used libiptc.
> 
> Since iptables 1.4.0, libiptc is not distributed anymore, so I resolved to
> incorporate the code into our own source distribution, just as people from
> collectd seemingly did.  All seemed to work well until yesterday, when we
> eventually pinpointed our calls to the (internal) libiptc as a cause of a
> kernel freeze.  It only happened on a generic Ubuntu Hardy kernel
> (2.6.24-22-generic) on one particular laptop (I didn't succeed in reproducing
> the freeze on another hardware with the same distribution).  I suppose it has
> something to do with the change of the format of data flowing to kernelspace
> (iptables 1.3.8 came distributed on that freezing machine), could anyone here
> confirm that this is possible indeed?

It should never crash the kernel, and the ABI is supposed to be
compatible.

> 
> Now my question is: how are we supposed to proceed from now on in order to
> manipulate iptables?  I read about libxtables and the corresponding libxtc.h
> (though these are not yet packaged in the current Ubuntu Intrepid), but it's
> not clear to me how the communication with the kernel is actually to be done.
> 
> Thanks for any information that could help me making this work properly.

Hard to tell without seeing the exact crash you're getting.

Re: Netfilter API and libiptc

[Ignacy Gawedzki]

On Mon, Feb 09, 2009 at 06:10:03PM +0100, thus spake Patrick McHardy:
> Ignacy Gawedzki wrote:
>> Hi everybody,
>>
>> I'm currently working on a project that relies on manipulation of iptables in
>> order to perform fine data packet accounting.  This manipulation is performed
>> dynamically, so the code initially used libiptc.
>>
>> Since iptables 1.4.0, libiptc is not distributed anymore, so I resolved to
>> incorporate the code into our own source distribution, just as people from
>> collectd seemingly did.  All seemed to work well until yesterday, when we
>> eventually pinpointed our calls to the (internal) libiptc as a cause of a
>> kernel freeze.  It only happened on a generic Ubuntu Hardy kernel
>> (2.6.24-22-generic) on one particular laptop (I didn't succeed in reproducing
>> the freeze on another hardware with the same distribution).  I suppose it has
>> something to do with the change of the format of data flowing to kernelspace
>> (iptables 1.3.8 came distributed on that freezing machine), could anyone here
>> confirm that this is possible indeed?
>
> It should never crash the kernel, and the ABI is supposed to be
> compatible.

Good to know, thanks.

>
>>
>> Now my question is: how are we supposed to proceed from now on in order to
>> manipulate iptables?  I read about libxtables and the corresponding libxtc.h
>> (though these are not yet packaged in the current Ubuntu Intrepid), but it's
>> not clear to me how the communication with the kernel is actually to be done.
>>
>> Thanks for any information that could help me making this work properly.
>
> Hard to tell without seeing the exact crash you're getting.

As far as I know, the crash is a complete freeze.  I don't know whether there
are any console messages to recover (using netconsole for instance).

My question was not about how to prevent the machine from crashing, but rather
how are we supposed to manipulate iptables, now that libiptc is not available.

As for the kernel crash itself, it is right now pretty difficult for me to
analyze, since I don't have the machine at hand and the person using it is too
busy at the moment.  So maybe I'll be able to take a look at some later time.

Thanks for your reply.

-- 
:wq!

Re: Netfilter API and libiptc

[Jesper Dangaard Brouer]

On Mon, 9 Feb 2009, Ignacy Gawedzki wrote:
> On Mon, Feb 09, 2009 at 06:10:03PM +0100, thus spake Patrick McHardy:
>> Ignacy Gawedzki wrote:
>>> Hi everybody,
>>>
>>> I'm currently working on a project that relies on manipulation of iptables in
>>> order to perform fine data packet accounting.  This manipulation is performed
>>> dynamically, so the code initially used libiptc.
>>>
>>> Since iptables 1.4.0, libiptc is not distributed anymore, so I resolved to
>>> incorporate the code into our own source distribution, just as people from
>>> collectd seemingly did.
>>> <cut>

> My question was not about how to prevent the machine from crashing, but rather
> how are we supposed to manipulate iptables, now that libiptc is not available.
> <cut>

I would propose that we add libiptc again.

Possibly as a shared library, like we have libxtables.so?

Controlling API/ABI changes is going to be a lot harder when people starts 
to incorporate the libiptc code into their own source distributions. (I'm 
also guildy with the Perl IPTables::libiptc package...)

Patrick, what do you say?

And Jan, you seems to be the one that removed libiptc... pro vs. cons?


Cheers,
   Jesper Brouer

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

Re: Netfilter API and libiptc

[Patrick McHardy]

Jesper Dangaard Brouer wrote:
> On Mon, 9 Feb 2009, Ignacy Gawedzki wrote:
>> My question was not about how to prevent the machine from crashing, 
>> but rather
>> how are we supposed to manipulate iptables, now that libiptc is not 
>> available.
>> <cut>
> 
> I would propose that we add libiptc again.
> 
> Possibly as a shared library, like we have libxtables.so?
> 
> Controlling API/ABI changes is going to be a lot harder when people 
> starts to incorporate the libiptc code into their own source 
> distributions. (I'm also guildy with the Perl IPTables::libiptc package...)
> 
> Patrick, what do you say?

Agreed on your reasoning. I don't have much of an opinion, we
mainly tried to hide it because it was never suitable for anything
else than a short "iptables ..." command because of memory leaks
etc. I think we're a lot better with this nowadays, if we can
get the worst remaining ones plugged and somewhat of a usable
API we can certainly add it as a library.

Re: Netfilter API and libiptc

[Jan Engelhardt]

On Wednesday 2009-02-11 15:37, Patrick McHardy wrote:

> Jesper Dangaard Brouer wrote:
>> On Mon, 9 Feb 2009, Ignacy Gawedzki wrote:
>>> My question was not about how to prevent the machine from crashing, but
>>> rather
>>> how are we supposed to manipulate iptables, now that libiptc is not
>>> available.
>>> <cut>
>>
>> I would propose that we add libiptc again.
>>
>> Possibly as a shared library, like we have libxtables.so?
>>
>> Controlling API/ABI changes is going to be a lot harder when people starts to
>> incorporate the libiptc code into their own source distributions. (I'm also
>> guildy with the Perl IPTables::libiptc package...)
>>
>> Patrick, what do you say?
>
> Agreed on your reasoning. I don't have much of an opinion, we
> mainly tried to hide it because it was never suitable for anything
> else than a short "iptables ..." command because of memory leaks
> etc. I think we're a lot better with this nowadays, if we can
> get the worst remaining ones plugged and somewhat of a usable
> API we can certainly add it as a library.
>
I have the code ready, it is easily mergeable-and-revertible(*) too, but 
let's wait with that because it currently relies on a certain revision 
of Makefile.am (IOW: merge conflicts with nf).

(*) That is, changing it from 'lib_LTLIBRARIES' to 'noinst_LTLIBARIES' 
and it automatically becomes static wrt. the executables again. Oh I 
love automake :)

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

Re: Netfilter API and libiptc

[Patrick McHardy]

Jan Engelhardt wrote:
> On Wednesday 2009-02-11 15:37, Patrick McHardy wrote:
> 
>> Jesper Dangaard Brouer wrote:
>>>
>>> Patrick, what do you say?
>> Agreed on your reasoning. I don't have much of an opinion, we
>> mainly tried to hide it because it was never suitable for anything
>> else than a short "iptables ..." command because of memory leaks
>> etc. I think we're a lot better with this nowadays, if we can
>> get the worst remaining ones plugged and somewhat of a usable
>> API we can certainly add it as a library.
>>
> I have the code ready, it is easily mergeable-and-revertible(*) too, but 
> let's wait with that because it currently relies on a certain revision 
> of Makefile.am (IOW: merge conflicts with nf).
> 
> (*) That is, changing it from 'lib_LTLIBRARIES' to 'noinst_LTLIBARIES' 
> and it automatically becomes static wrt. the executables again. Oh I 
> love automake :)

I'd prefer to wait until after the next release with this. We already
have quite a few changes and missed the last release, so I want to
start stabilizing a nice new release for 2.6.29 soon.

Re: Netfilter API and libiptc

[Jan Engelhardt]

On Thursday 2009-02-12 06:13, Patrick McHardy wrote:
>>>
>> I have the code ready, it is easily mergeable-and-revertible(*) too, but let's
>> wait with that because it currently relies on a certain revision of
>> Makefile.am (IOW: merge conflicts with nf).
>>
>> (*) That is, changing it from 'lib_LTLIBRARIES' to 'noinst_LTLIBARIES' and it
>> automatically becomes static wrt. the executables again. Oh I love automake :)
>
> I'd prefer to wait until after the next release with this.

I'd rather not want to wait another 4 months with this change
[of enabling iptc to be installed].
If Jesper then wants to play with the API, no problem, just
don't forget bumping the so_version correctly.

> We already have quite a few changes and missed the last release,

Maybe releases should be more coordinated. 
I could come up with a big bunch of suggested guidelines upfront.
Release-early-release-often is the one I miss most.
	.oO( and before I know it, I wrote another book )

>so I want to start stabilizing a nice new release for 2.6.29 soon.

Here is your chance to make 1.4.3 nice - it does happen that some
projects seem to use libiptc, and because it's not installed with
distros because it is noinst_ in our happy Makefile.am, projects do a
verbatim copy which a deed worse than having the current API -
cherry-steal commit 1715851e now! :-D

Re: Netfilter API and libiptc

[Patrick McHardy]

Jan Engelhardt wrote:
> On Thursday 2009-02-12 06:13, Patrick McHardy wrote:
>>> I have the code ready, it is easily mergeable-and-revertible(*) too, but let's
>>> wait with that because it currently relies on a certain revision of
>>> Makefile.am (IOW: merge conflicts with nf).
>>>
>>> (*) That is, changing it from 'lib_LTLIBRARIES' to 'noinst_LTLIBARIES' and it
>>> automatically becomes static wrt. the executables again. Oh I love automake :)
>> I'd prefer to wait until after the next release with this.
> 
> I'd rather not want to wait another 4 months with this change
> [of enabling iptc to be installed].
> If Jesper then wants to play with the API, no problem, just
> don't forget bumping the so_version correctly.
> 
>> We already have quite a few changes and missed the last release,
> 
> Maybe releases should be more coordinated. 
> I could come up with a big bunch of suggested guidelines upfront.
> Release-early-release-often is the one I miss most.
> 	.oO( and before I know it, I wrote another book )

If you write me a script to take care of all the website crap,
I'll happily release more often :) Its just a major PITA currently.

>> so I want to start stabilizing a nice new release for 2.6.29 soon.
> 
> Here is your chance to make 1.4.3 nice - it does happen that some
> projects seem to use libiptc, and because it's not installed with
> distros because it is noinst_ in our happy Makefile.am, projects do a
> verbatim copy which a deed worse than having the current API -
> cherry-steal commit 1715851e now! :-D

I know. We've told them that this is a bad idea. Anyways, lets
see how intrusive these changes get.

Re: Netfilter API and libiptc

[Jan Engelhardt]

On Thursday 2009-02-12 06:58, Patrick McHardy wrote:
>>
>> Maybe releases should be more coordinated. I could come up with a big bunch of
>> suggested guidelines upfront.
>> Release-early-release-often is the one I miss most.
>> 	.oO( and before I know it, I wrote another book )
>
> If you write me a script to take care of all the website crap,
> I'll happily release more often :) Its just a major PITA currently.

I'd rather put up some CMS, wordpress or blogger style than writing
scripts. In case of Sourceforge, I use the RSS stuff - and they got
to do storing the news items.
And for some projects I only even have a Freshmeat entry
because I can't be bothered to update the master site.

Re: Netfilter API and libiptc

[Patrick McHardy]

Jan Engelhardt wrote:
> On Thursday 2009-02-12 06:58, Patrick McHardy wrote:
>>> Maybe releases should be more coordinated. I could come up with a big bunch of
>>> suggested guidelines upfront.
>>> Release-early-release-often is the one I miss most.
>>> 	.oO( and before I know it, I wrote another book )
>> If you write me a script to take care of all the website crap,
>> I'll happily release more often :) Its just a major PITA currently.
> 
> I'd rather put up some CMS, wordpress or blogger style than writing
> scripts. In case of Sourceforge, I use the RSS stuff - and they got
> to do storing the news items.

We talked about that, Harald is not feeling comfortable using these
on the netfilter servers, and I can understand why. Ideally we'll
find a new webmaster to take care of these things.

Re: Netfilter API and libiptc

[Jan Engelhardt]

On Thursday 2009-02-12 07:18, Patrick McHardy wrote:
>>> If you write me a script to take care of all the website crap,
>>> I'll happily release more often :) Its just a major PITA currently.
>>
>> I'd rather put up some CMS, wordpress or blogger style than writing
>> scripts. In case of Sourceforge, I use the RSS stuff - and they got
>> to do storing the news items.
>
> We talked about that, Harald is not feeling comfortable using these
> on the netfilter servers, and I can understand why.

So do I.
Even in that case, I'd just skip announcing on netfilter.org.
People probably do not visit netfilter.org just to read
"We released v[x.y.z(+n)]" three times in a row.

Re: Netfilter API and libiptc

[Patrick McHardy]

Jan Engelhardt wrote:
> On Thursday 2009-02-12 07:18, Patrick McHardy wrote:
>>>> If you write me a script to take care of all the website crap,
>>>> I'll happily release more often :) Its just a major PITA currently.
>>> I'd rather put up some CMS, wordpress or blogger style than writing
>>> scripts. In case of Sourceforge, I use the RSS stuff - and they got
>>> to do storing the news items.
>> We talked about that, Harald is not feeling comfortable using these
>> on the netfilter servers, and I can understand why.
> 
> So do I.
> Even in that case, I'd just skip announcing on netfilter.org.
> People probably do not visit netfilter.org just to read
> "We released v[x.y.z(+n)]" three times in a row.

Good point, the remaining website is also practically dead for
years now :)

Re: Netfilter API and libiptc

[Jesper Dangaard Brouer]

On Thu, 12 Feb 2009, Jan Engelhardt wrote:

> If Jesper then wants to play with the API, no problem, just
> don't forget bumping the so_version correctly.

I'll try it out today... lets see how intrusive it is...

Hilsen
   Jesper Brouer

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

Re: Netfilter API and libiptc

[Jesper Dangaard Brouer]

On Thu, 12 Feb 2009, Jesper Dangaard Brouer wrote:

> On Thu, 12 Feb 2009, Jan Engelhardt wrote:
>
>>  If Jesper then wants to play with the API, no problem, just
>>  don't forget bumping the so_version correctly.
>
> I'll try it out today... lets see how intrusive it is...

That was almost too easy...

Although, Jan has priviously introduced some libiptc API changes, so I had 
to adjust my old example/test libiptc programs a bit. e.g. removed the 
typedef iptc_handle_t.

Whats missing is that the libiptc.h header file should be installed.
My patch below is not doing the right thing. I don't know automake well 
enough, to make it create a directory libiptc/ under include/ where it 
should install libiptc.h.

Cheers,
   Jesper Brouer

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

commit af01026f992347b70bcad05eda750b3808d7e970
Author: Jesper Dangaard Brouer <hawk@comx.dk>
Date:   Thu Feb 12 11:32:09 2009 +0100

     Install the libiptc.h header file.

     This patch is not what I really want, as it installs libiptc.h directly in
     include/ where is should be placed in include/libiptc/ to comply with the
     old standard.  The problem is that I don't know automake well enough...

diff --git a/Makefile.am b/Makefile.am
index 274b015..85dd1c7 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -81,7 +81,7 @@ man_MANS         = iptables.8 iptables-restore.8 iptables-save.8 \
                     ip6tables-save.8
  CLEANFILES       = iptables.8 ip6tables.8
  if ENABLE_DEVEL
-include_HEADERS  = include/xtables.h
+include_HEADERS  = include/xtables.h include/libiptc/libiptc.h
  endif

  if ENABLE_STATIC

Re: Netfilter API and libiptc

[Ignacy Gawedzki]

[-- Attachment #1: Type: text/plain, Size: 557 bytes --]

On Thu, Feb 12, 2009 at 11:42:08AM +0100, thus spake Jesper Dangaard Brouer:
> Whats missing is that the libiptc.h header file should be installed.
> My patch below is not doing the right thing. I don't know automake well  
> enough, to make it create a directory libiptc/ under include/ where it  
> should install libiptc.h.

See the attached patch.  The idea is to add a Makefile.am into include/ and
then use the nobase_ prefix to prevent automake from stripping the
subdirectory name from the files.

-- 
Sex on TV doesn't hurt....unless you fall off.

[-- Attachment #2: iptables-headers.patch --]
[-- Type: text/x-diff, Size: 1125 bytes --]

diff --git a/Makefile.am b/Makefile.am
index dbdfa97..3ea4a69 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -79,7 +79,8 @@ man_MANS         = iptables.8 iptables-restore.8 iptables-save.8 \
                    ip6tables-save.8
 CLEANFILES       = iptables.8 ip6tables.8
 if ENABLE_DEVEL
-include_HEADERS  = include/xtables.h
+SUBDIRS += include
+#nobase_include_HEADERS  = include/xtables.h include/libiptc/libiptc.h
 endif
 
 if ENABLE_STATIC
diff --git a/configure.ac b/configure.ac
index 888ba42..96a2c8d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -78,6 +78,6 @@ AC_SUBST([libxtables_vage])
 libxtables_vmajor=$(($libxtables_vcurrent - $libxtables_vage));
 AC_SUBST([libxtables_vmajor])
 
-AC_CONFIG_FILES([Makefile extensions/GNUmakefile libipq/Makefile
+AC_CONFIG_FILES([Makefile extensions/GNUmakefile include/Makefile libipq/Makefile
 	include/xtables.h include/iptables/internal.h xtables.pc])
 AC_OUTPUT
diff --git a/include/Makefile.am b/include/Makefile.am
new file mode 100644
index 0000000..7564466
--- /dev/null
+++ b/include/Makefile.am
@@ -0,0 +1 @@
+nobase_include_HEADERS = xtables.h libiptc/libiptc.h

Re: Netfilter API and libiptc

[Jan Engelhardt]

On Thursday 2009-02-12 11:42, Jesper Dangaard Brouer wrote:
> On Thu, 12 Feb 2009, Jesper Dangaard Brouer wrote:
>> On Thu, 12 Feb 2009, Jan Engelhardt wrote:
>>
>>> If Jesper then wants to play with the API, no problem, just
>>> don't forget bumping the so_version correctly.
>>
>> I'll try it out today... lets see how intrusive it is...
>
> That was almost too easy...
>
> Whats missing is that the libiptc.h header file should be installed.
> My patch below is not doing the right thing. I don't know automake well enough,
> to make it create a directory libiptc/ under include/ where it should install
> libiptc.h.

Fixed now.

Re: Netfilter API and libiptc

[Jesper Dangaard Brouer]

On Thu, 12 Feb 2009, Jan Engelhardt wrote:

>
> On Thursday 2009-02-12 11:42, Jesper Dangaard Brouer wrote:
>> On Thu, 12 Feb 2009, Jesper Dangaard Brouer wrote:
>>> On Thu, 12 Feb 2009, Jan Engelhardt wrote:
>>>
>>>> If Jesper then wants to play with the API, no problem, just
>>>> don't forget bumping the so_version correctly.
>>>
>>> I'll try it out today... lets see how intrusive it is...
>>
>> That was almost too easy...
>>
>> Whats missing is that the libiptc.h header file should be installed.
>> My patch below is not doing the right thing. I don't know automake well enough,
>> to make it create a directory libiptc/ under include/ where it should install
>> libiptc.h.
>
> Fixed now.

Thanks, that did the trick.

You changed the iptc branch commit a bit, so now its commit c102d69b8d1 
(and not f9eab59c61), that confused me a bit...  And you general commit 
f567ac9193b "build: restructure Makefile for include/ directory" was part 
of the solution.

Thanks, nice work!

Hilsen
   Jesper Brouer

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

Re: Netfilter API and libiptc

[Jesper Dangaard Brouer]

On Thu, 12 Feb 2009, Patrick McHardy wrote:

> Jan Engelhardt wrote:
>>  On Thursday 2009-02-12 06:13, Patrick McHardy wrote:
>> > >  I have the code ready, it is easily mergeable-and-revertible(*) 
>> > >  too, but let's wait with that because it currently relies on a 
>> > >  certain revision of Makefile.am (IOW: merge conflicts with nf).
>> > > 
>> > >  (*) That is, changing it from 'lib_LTLIBRARIES' to 
>> > >  'noinst_LTLIBARIES' and it automatically becomes static wrt. the 
>> > >  executables again. Oh I love automake :)
<cut>

>>  Here is your chance to make 1.4.3 nice - it does happen that some
>>  projects seem to use libiptc, and because it's not installed with
>>  distros because it is noinst_ in our happy Makefile.am, projects do a
>>  verbatim copy which a deed worse than having the current API -
>
> I know. We've told them that this is a bad idea. Anyways, lets
> see how intrusive these changes get.

Hi Patrick,

Would you please consider the libiptc shared library patch for inclusion?

I don't find the patch intrusive.  I have tested it and it works.

See patch below...

Cheers
   Jesper Brouer

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


>From c102d69b8d12b513b407bda840f05d1ae9aa3e30 Mon Sep 17 00:00:00 2001
From: Jan Engelhardt <jengelh@medozas.de>
Date: Wed, 11 Feb 2009 16:40:29 +0100
Subject: [PATCH 1/1] libiptc: make library available as a shared library

Tested-by: Jesper Dangaard Brouer <hawk@comx.dk>
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
---
  .gitignore          |    1 +
  Makefile.am         |   18 ++++++++++--------
  configure.ac        |    2 +-
  include/Makefile.am |    4 ++++
  libiptc.pc.in       |   11 +++++++++++
  5 files changed, 27 insertions(+), 9 deletions(-)
  create mode 100644 libiptc.pc.in

diff --git a/.gitignore b/.gitignore
index 97c3004..e5d3099 100644
--- a/.gitignore
+++ b/.gitignore
@@ -35,6 +35,7 @@ Makefile.in
  /ltmain.sh
  /missing
  /stamp-h1
+/libiptc.pc
  /xtables.pc

  /ip6tables
diff --git a/Makefile.am b/Makefile.am
index be3f55e..69fa903 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -11,11 +11,14 @@ endif
  if ENABLE_LIBIPQ
  SUBDIRS         += libipq
  endif
+lib_LTLIBRARIES =

  # libiptc
-libiptc_libiptc_a_SOURCES = libiptc/libip4tc.c libiptc/libip6tc.c
+lib_LTLIBRARIES           += libiptc/libiptc.la
+libiptc_libiptc_la_SOURCES = libiptc/libip4tc.c libiptc/libip6tc.c
+libiptc_libiptc_la_LDFLAGS = -version-info 0:0:0

-lib_LTLIBRARIES       = libxtables.la
+lib_LTLIBRARIES      += libxtables.la
  libxtables_la_SOURCES = xtables.c
  libxtables_la_LDFLAGS = -version-info ${libxtables_vcurrent}:0:${libxtables_vage}
  libxtables_la_LIBADD  = -ldl
@@ -23,7 +26,7 @@ libxtables_la_LIBADD  = -ldl
  # iptables, dynamic
  iptables_SOURCES          = iptables-standalone.c iptables.c
  iptables_LDFLAGS          = -rdynamic
-iptables_LDADD            = -lm libiptc/libiptc.a extensions/libext4.a libxtables.la
+iptables_LDADD            = -lm libiptc/libiptc.la extensions/libext4.a libxtables.la

  iptables_xml_LDADD        = -ldl libxtables.la
  iptables_multi_SOURCES    = iptables-multi.c iptables-save.c \
@@ -44,14 +47,14 @@ iptables_save_LDADD       = ${iptables_LDADD}
  # iptables-multi, semi-static
  iptables_static_SOURCES   = ${iptables_multi_SOURCES} xtables.c
  iptables_static_CFLAGS    = ${iptables_multi_CFLAGS} -DNO_SHARED_LIBS=1
-iptables_static_LDADD     = -lm libiptc/libiptc.a extensions/libext4.a
+iptables_static_LDADD     = -lm libiptc/libiptc.la extensions/libext4.a

  iptables_xml_SOURCES      = iptables-xml.c

  # ip6tables, dynamic
  ip6tables_SOURCES         = ip6tables-standalone.c ip6tables.c
  ip6tables_LDFLAGS         = -rdynamic
-ip6tables_LDADD           = -lm libiptc/libiptc.a extensions/libext6.a libxtables.la
+ip6tables_LDADD           = -lm libiptc/libiptc.la extensions/libext6.a libxtables.la

  ip6tables_multi_SOURCES   = ip6tables-multi.c ip6tables-save.c \
                              ip6tables-restore.c ip6tables-standalone.c \
@@ -71,9 +74,8 @@ ip6tables_save_LDADD      = ${ip6tables_LDADD}
  # iptables-multi, semi-static
  ip6tables_static_SOURCES    = ${ip6tables_multi_SOURCES} xtables.c
  ip6tables_static_CFLAGS     = ${ip6tables_multi_CFLAGS} -DNO_SHARED_LIBS=1
-ip6tables_static_LDADD      = -lm libiptc/libiptc.a extensions/libext6.a
+ip6tables_static_LDADD      = -lm libiptc/libiptc.la extensions/libext6.a

-noinst_LIBRARIES = libiptc/libiptc.a
  bin_PROGRAMS     = iptables-xml
  sbin_PROGRAMS    =
  noinst_PROGRAMS  =
@@ -96,7 +98,7 @@ iptables.8: ${srcdir}/iptables.8.in extensions/matches4.man extensions/targets4.
  ip6tables.8: ${srcdir}/ip6tables.8.in extensions/matches6.man extensions/targets6.man
  	${AM_VERBOSE_GEN} sed -e 's/@PACKAGE_AND_VERSION@/${PACKAGE} ${PACKAGE_VERSION}/g' -e '/@MATCH@/ r extensions/matches6.man' -e '/@TARGET@/ r extensions/targets6.man' $< >$@;

-pkgconfig_DATA = xtables.pc
+pkgconfig_DATA = libiptc.pc xtables.pc

  .PHONY: tarball
  tarball:
diff --git a/configure.ac b/configure.ac
index 3277666..55569bd 100644
--- a/configure.ac
+++ b/configure.ac
@@ -80,5 +80,5 @@ AC_SUBST([libxtables_vmajor])

  AC_CONFIG_FILES([Makefile extensions/GNUmakefile include/Makefile
  	libipq/Makefile
-	include/xtables.h include/iptables/internal.h xtables.pc])
+	include/xtables.h include/iptables/internal.h libiptc.pc xtables.pc])
  AC_OUTPUT
diff --git a/include/Makefile.am b/include/Makefile.am
index 6206bd2..0a1abea 100644
--- a/include/Makefile.am
+++ b/include/Makefile.am
@@ -6,3 +6,7 @@ nobase_include_HEADERS = xtables.h
  if ENABLE_LIBIPQ
  include_HEADERS += libipq/libipq.h
  endif
+
+nobase_include_HEADERS += \
+	libiptc/ipt_kernel_headers.h libiptc/libiptc.h \
+	libiptc/libip6tc.h libiptc/libxtc.h
diff --git a/libiptc.pc.in b/libiptc.pc.in
new file mode 100644
index 0000000..63a459a
--- /dev/null
+++ b/libiptc.pc.in
@@ -0,0 +1,11 @@
+
+prefix=@prefix@
+exec_prefix=@exec_prefix@
+libdir=@libdir@
+includedir=@includedir@
+
+Name:		libiptc
+Description:	iptables ruleset ADT and kernel interface
+Version:	@PACKAGE_VERSION@
+Libs:		-L${libdir} -liptc
+Cflags:		-I${includedir}
-- 
1.5.6.5

Re: Netfilter API and libiptc

[Jesper Dangaard Brouer]

On Mon, 16 Feb 2009, Jesper Dangaard Brouer wrote:

> Hi Patrick,
>
> Would you please consider the libiptc shared library patch for inclusion?
> I don't find the patch intrusive.  I have tested it and it works.
>
> See patch below...

Ups, that patch would not apply cleanly to the latest git (commit 
5dd19de34380).  Trivial diff conflict on Makefile.am (due to ae19604f 
"build: remove unneeded -ldl from iptables_xml_LDADD")

There is a clean version:

>From 4a1c3f3e56a2039b87636d3d2d8517933c47b517 Mon Sep 17 00:00:00 2001
From: Jan Engelhardt <jengelh@medozas.de>
Date: Wed, 11 Feb 2009 16:40:29 +0100
Subject: [PATCH 1/1] libiptc: make library available as a shared library

Tested-by: Jesper Dangaard Brouer <hawk@comx.dk>
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
---
  .gitignore          |    1 +
  Makefile.am         |   18 ++++++++++--------
  configure.ac        |    2 +-
  include/Makefile.am |    4 ++++
  libiptc.pc.in       |   11 +++++++++++
  5 files changed, 27 insertions(+), 9 deletions(-)
  create mode 100644 libiptc.pc.in

diff --git a/.gitignore b/.gitignore
index 97c3004..e5d3099 100644
--- a/.gitignore
+++ b/.gitignore
@@ -35,6 +35,7 @@ Makefile.in
  /ltmain.sh
  /missing
  /stamp-h1
+/libiptc.pc
  /xtables.pc

  /ip6tables
diff --git a/Makefile.am b/Makefile.am
index a79ff67..41dc280 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -11,11 +11,14 @@ endif
  if ENABLE_LIBIPQ
  SUBDIRS         += libipq
  endif
+lib_LTLIBRARIES =

  # libiptc
-libiptc_libiptc_a_SOURCES = libiptc/libip4tc.c libiptc/libip6tc.c
+lib_LTLIBRARIES           += libiptc/libiptc.la
+libiptc_libiptc_la_SOURCES = libiptc/libip4tc.c libiptc/libip6tc.c
+libiptc_libiptc_la_LDFLAGS = -version-info 0:0:0

-lib_LTLIBRARIES       = libxtables.la
+lib_LTLIBRARIES      += libxtables.la
  libxtables_la_SOURCES = xtables.c
  libxtables_la_LDFLAGS = -version-info ${libxtables_vcurrent}:0:${libxtables_vage}
  libxtables_la_LIBADD  = -ldl
@@ -23,7 +26,7 @@ libxtables_la_LIBADD  = -ldl
  # iptables, dynamic
  iptables_SOURCES          = iptables-standalone.c iptables.c
  iptables_LDFLAGS          = -rdynamic
-iptables_LDADD            = -lm libiptc/libiptc.a extensions/libext4.a libxtables.la
+iptables_LDADD            = -lm libiptc/libiptc.la extensions/libext4.a libxtables.la

  iptables_xml_LDADD        = libxtables.la
  iptables_multi_SOURCES    = iptables-multi.c iptables-save.c \
@@ -44,14 +47,14 @@ iptables_save_LDADD       = ${iptables_LDADD}
  # iptables-multi, semi-static
  iptables_static_SOURCES   = ${iptables_multi_SOURCES} xtables.c
  iptables_static_CFLAGS    = ${iptables_multi_CFLAGS} -DNO_SHARED_LIBS=1
-iptables_static_LDADD     = -lm libiptc/libiptc.a extensions/libext4.a
+iptables_static_LDADD     = -lm libiptc/libiptc.la extensions/libext4.a

  iptables_xml_SOURCES      = iptables-xml.c

  # ip6tables, dynamic
  ip6tables_SOURCES         = ip6tables-standalone.c ip6tables.c
  ip6tables_LDFLAGS         = -rdynamic
-ip6tables_LDADD           = -lm libiptc/libiptc.a extensions/libext6.a libxtables.la
+ip6tables_LDADD           = -lm libiptc/libiptc.la extensions/libext6.a libxtables.la

  ip6tables_multi_SOURCES   = ip6tables-multi.c ip6tables-save.c \
                              ip6tables-restore.c ip6tables-standalone.c \
@@ -71,9 +74,8 @@ ip6tables_save_LDADD      = ${ip6tables_LDADD}
  # iptables-multi, semi-static
  ip6tables_static_SOURCES    = ${ip6tables_multi_SOURCES} xtables.c
  ip6tables_static_CFLAGS     = ${ip6tables_multi_CFLAGS} -DNO_SHARED_LIBS=1
-ip6tables_static_LDADD      = -lm libiptc/libiptc.a extensions/libext6.a
+ip6tables_static_LDADD      = -lm libiptc/libiptc.la extensions/libext6.a

-noinst_LIBRARIES = libiptc/libiptc.a
  bin_PROGRAMS     = iptables-xml
  sbin_PROGRAMS    =
  noinst_PROGRAMS  =
@@ -96,7 +98,7 @@ iptables.8: ${srcdir}/iptables.8.in extensions/matches4.man extensions/targets4.
  ip6tables.8: ${srcdir}/ip6tables.8.in extensions/matches6.man extensions/targets6.man
  	${AM_VERBOSE_GEN} sed -e 's/@PACKAGE_AND_VERSION@/${PACKAGE} ${PACKAGE_VERSION}/g' -e '/@MATCH@/ r extensions/matches6.man' -e '/@TARGET@/ r extensions/targets6.man' $< >$@;

-pkgconfig_DATA = xtables.pc
+pkgconfig_DATA = libiptc.pc xtables.pc

  .PHONY: tarball
  tarball:
diff --git a/configure.ac b/configure.ac
index 3277666..55569bd 100644
--- a/configure.ac
+++ b/configure.ac
@@ -80,5 +80,5 @@ AC_SUBST([libxtables_vmajor])

  AC_CONFIG_FILES([Makefile extensions/GNUmakefile include/Makefile
  	libipq/Makefile
-	include/xtables.h include/iptables/internal.h xtables.pc])
+	include/xtables.h include/iptables/internal.h libiptc.pc xtables.pc])
  AC_OUTPUT
diff --git a/include/Makefile.am b/include/Makefile.am
index 6206bd2..0a1abea 100644
--- a/include/Makefile.am
+++ b/include/Makefile.am
@@ -6,3 +6,7 @@ nobase_include_HEADERS = xtables.h
  if ENABLE_LIBIPQ
  include_HEADERS += libipq/libipq.h
  endif
+
+nobase_include_HEADERS += \
+	libiptc/ipt_kernel_headers.h libiptc/libiptc.h \
+	libiptc/libip6tc.h libiptc/libxtc.h
diff --git a/libiptc.pc.in b/libiptc.pc.in
new file mode 100644
index 0000000..63a459a
--- /dev/null
+++ b/libiptc.pc.in
@@ -0,0 +1,11 @@
+
+prefix=@prefix@
+exec_prefix=@exec_prefix@
+libdir=@libdir@
+includedir=@includedir@
+
+Name:		libiptc
+Description:	iptables ruleset ADT and kernel interface
+Version:	@PACKAGE_VERSION@
+Libs:		-L${libdir} -liptc
+Cflags:		-I${includedir}
-- 
1.5.6.5

Re: Netfilter API and libiptc

[Patrick McHardy]

Jesper Dangaard Brouer wrote:
> On Mon, 16 Feb 2009, Jesper Dangaard Brouer wrote:
> 
>> Hi Patrick,
>>
>> Would you please consider the libiptc shared library patch for inclusion?
>> I don't find the patch intrusive.  I have tested it and it works.
>>
>> See patch below...
> 
> Ups, that patch would not apply cleanly to the latest git (commit 
> 5dd19de34380).  Trivial diff conflict on Makefile.am (due to ae19604f 
> "build: remove unneeded -ldl from iptables_xml_LDADD")
> 
> There is a clean version:
> 
>> From 4a1c3f3e56a2039b87636d3d2d8517933c47b517 Mon Sep 17 00:00:00 2001
> From: Jan Engelhardt <jengelh@medozas.de>
> Date: Wed, 11 Feb 2009 16:40:29 +0100
> Subject: [PATCH 1/1] libiptc: make library available as a shared library

No objections from my side. Jan, do you consider this patch ready
for inclusion?

Re: Netfilter API and libiptc

[Jan Engelhardt]

On Monday 2009-02-16 15:08, Patrick McHardy wrote:
>>> From 4a1c3f3e56a2039b87636d3d2d8517933c47b517 Mon Sep 17 00:00:00 2001
>> From: Jan Engelhardt <jengelh@medozas.de>
>> Date: Wed, 11 Feb 2009 16:40:29 +0100
>> Subject: [PATCH 1/1] libiptc: make library available as a shared library
>
> No objections from my side. Jan, do you consider this patch ready
> for inclusion?
>
Very much so. You can just grab it from the 'iptc' branch at

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

I added Jesper's tested-by tag and rebased (so it moved,
 + c102d69...51bc836 iptc -> iptc (forced update))

Re: Netfilter API and libiptc

[Patrick McHardy]

Jan Engelhardt wrote:
> On Monday 2009-02-16 15:08, Patrick McHardy wrote:
>>>> From 4a1c3f3e56a2039b87636d3d2d8517933c47b517 Mon Sep 17 00:00:00 2001
>>> From: Jan Engelhardt <jengelh@medozas.de>
>>> Date: Wed, 11 Feb 2009 16:40:29 +0100
>>> Subject: [PATCH 1/1] libiptc: make library available as a shared library
>> No objections from my side. Jan, do you consider this patch ready
>> for inclusion?
>>
> Very much so. You can just grab it from the 'iptc' branch at
> 
> 	git://dev.medozas.de/iptables iptc
> 
> I added Jesper's tested-by tag and rebased (so it moved,
>  + c102d69...51bc836 iptc -> iptc (forced update))

Done, thanks Jan.