From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Eric Leblond <eric@inl.fr>
Cc: laforge@netfilter.org, netfilter-devel@lists.netfilter.org,
Patrick McHardy <kaber@trash.net>,
vincent@inl.fr
Subject: Re: [PATCH] Set mark to 0 from libnetfilter_conntrack
Date: Fri, 27 Oct 2006 15:53:31 +0200 [thread overview]
Message-ID: <45420F5B.8090504@netfilter.org> (raw)
In-Reply-To: <1161898638.7358.22.camel@localhost.localdomain>
Eric Leblond wrote:
> Hello,
>
> Le jeudi 26 octobre 2006 à 01:37 +0200, Patrick McHardy a écrit :
>> The idea is still the right one, I think the library
>> should take care of adding a CTA_MARK attribute without any user bitmask
>> fiddling by including it if the value differs from the mark contained in
>> the received conntrack. I think Pablo's new API will allow this.
>
> What's the status of this new API ? Current status of
> libnetfilter_conntrack code is really disappointing.
Indeed, you can blame me for that. I'm working on the new API that I'll
try to release asap. I'm going to put this in my high priority queue.
> We at INL are currently working on using libnetfilter_conntrack to
> provide tools for firewall administrators. The first one
> pynetfilter_conntrack is already available and a web management
> interface will soon be released. By doing this we are trying to improve
> the usability of this new system.
I'd like to see your python binding in the libnetfilter_conntrack tree
but I have to fix some stuff before, please consider that this would
require some extra work from your part.
> We are doing this because we think the new features provided by
> libnetfilter_conntrack really improve a lot the way we use and "live"
> with a Netfilter firewall.
>
> Sadly, the uncertainty on code evolution and the lack of frequent
> releases are wounding the expansion of these ideas.
We are working to improve the release process, expect changes soon.
> From my point of view, a decision on libnetfilter_conntrack
> developpement should be made quickly :
> * Should pablo's version become the next step in this branch ? or
> * Is it necessary to create a new branch to keep a stable version
> and have compatibility with the few existing applications ?
I already commented what my intentions are: add more new API, do not
remove the old one but mark it as deprecated, strongly recommend people
to move to the new API. The deprecated API will be removed after quite
some time.
--
The dawn of the fourth age of Linux firewalling is coming; a time of
great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris
next prev parent reply other threads:[~2006-10-27 13:53 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-25 18:38 [PATCH] Set mark to 0 from libnetfilter_conntrack Eric Leblond
2006-10-25 23:37 ` Patrick McHardy
2006-10-26 21:37 ` Eric Leblond
2006-10-27 13:53 ` Pablo Neira Ayuso [this message]
2006-10-27 21:17 ` Eric Leblond
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=45420F5B.8090504@netfilter.org \
--to=pablo@netfilter.org \
--cc=eric@inl.fr \
--cc=kaber@trash.net \
--cc=laforge@netfilter.org \
--cc=netfilter-devel@lists.netfilter.org \
--cc=vincent@inl.fr \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.