Linux Netfilter discussions
 help / color / mirror / Atom feed
From: Derrik Pates <dpates@dsdk12.net>
To: "Bruno Negrão" <vpopmail@engepel.com.br>
Cc: netfilter@lists.netfilter.org, iptperl-general@lists.sourceforge.net
Subject: Re: [Iptperl-general] Is IPTables::IPv4 Perl module trustable?
Date: Fri, 23 Jul 2004 20:35:45 -0400	[thread overview]
Message-ID: <4101AEE1.3050107@dsdk12.net> (raw)
In-Reply-To: <01d101c4710d$8c3c4490$5100a8c0@egp>

Bruno Negrão wrote:
> My question is exactly the one in the e-mail subject: Is IPTables::IPv4
> Perl module trustable?
> 
> This module is a perl interface to the 'libiptc' library, written by,
> Derrik Pates. I'd like to use it in an application.
> But I read in netfilter's FAQ the following:
> 
> "4.5 Is there an C/C++ API for adding/removing rules?
> The answer unfortunately is: No.
> Now you might think 'but what about libiptc?'. As has been pointed out
> numerous times on the mailinglist(s), libiptc was _NEVER_ meant to be used
> as a public interface. We don't guarantee a stable interface, and it is
> planned to remove it in the next incarnation of linux packet filtering.
> libiptc is way too low-layer to be used reasonably anyway.
> We are well aware that there is a fundamental lack for such an API, and we
> are working on improving that situation. Until then, it is recommended to
> either use system() or open a pipe into stdin of iptables-restore. The
> latter will give you a way better performance."

The ways they suggest will work, but not very well, and they're really 
quite ugly. Yes, a whole new userspace tool for managing netfilter rules 
will eventually be written - but that's still a ways off, and until the 
kernel side interface changes, the libiptc code which I'm using from the 
iptables codebase will continue to work just fine, thank you.

> Does someone else already tested it before? Does someone else there knows
> its internals?

I don't really know what you're saying here. But really, you can test it 
any way you need to, or have whoever you want test it for you - the 
source is there for your (or anybody's) perusal. It incorporates a fair 
amount of code on top of libiptc so that you don't have to know the raw 
data structures, and generally makes things a good bit nicer than 
calling libiptc directly, and way cleaner than assembling command lines 
and using system() to call out to iptables (I've tried that before, long 
ago, and it caused me great pain. Or maybe that was just lunch one 
day... I forget now.)

-- 
Derrik Pates
dpates@dsdk12.net


  reply	other threads:[~2004-07-24  0:35 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-23 23:34 Is IPTables::IPv4 Perl module trustable? Bruno Negrão
2004-07-24  0:35 ` Derrik Pates [this message]
2004-07-26  7:31 ` [Iptperl-general] " Alex Ongena

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4101AEE1.3050107@dsdk12.net \
    --to=dpates@dsdk12.net \
    --cc=iptperl-general@lists.sourceforge.net \
    --cc=netfilter@lists.netfilter.org \
    --cc=vpopmail@engepel.com.br \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox