From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Chris Taylor <chtaylo4@gmail.com>
Cc: netfilter-devel@lists.netfilter.org
Subject: Re: Notification of new/destroyed connection
Date: Wed, 28 Feb 2007 13:39:15 +0100 [thread overview]
Message-ID: <45E577F3.1070003@netfilter.org> (raw)
In-Reply-To: <ba7529fb0702271449p460843fag8528aab89261ee84@mail.gmail.com>
Chris Taylor wrote:
> Then I saw the notification chains and I thought about makeing a
> notification block and registering it with
> nf_conntrack_register_notifier(struct notifier_block *nb). I couldn't
> find the initial listing of the anticiapted values for the events and
> the void* p, but I saw examples in
> net/netfilter/nf_conntrack_netlink.c So I then turned my attention to
> include/linux/netfilter/nf_conntrack_common.h and saw the difference
> b/n ip_conntrack_expect_events and ip_conntrack_events, namely that
> ip_conntrack_expect_events only has IPEXP_NEW.
If you have to check for new and destroyed connections, just register a
module that listens to IPCT_NEW and IPCT_DESTROY events,
ip_conntrack_events in nf_conntrack_netlink is a good example. Forget
about ip_conntrack_expect_events since that functions handles
expectation events, AFAICS this is not what you want.
> Am I correct to assume that if I need to do some setup in advance of a
> connection establishment, then I should subscribe via the
> nf_conntrack_register_expect_notifier and wait for a IPEXP_NEW event?
No, this is for expectations. I suggest you to have a look at [1].
> What happenes if I do the setup and the connection is never
> established? Will I get notified of that via the callback registered
> with nf_conntrack_register_notifier with a IPCT_DESTROY event?
Then the connection will expire after a certain timeout, no need to
worry about this scenario. You'll get IPCT_DESTROY anyway. You can tune
the timeout if you think that they are too long.
> Am I better off doing this with nf_conntrack or ip_conntrack? What's
> the difference?
nf_conntrack is layer 3 independent, ip_conntrack is obsoleted and is
scheduled to be removed in 2.6.22 if my mind serves well. So go
nf_conntrack.
> Am I headed in the correct direction?
Basically yes.
[1] http://people.netfilter.org/pablo/docs/
--
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:[~2007-02-28 12:39 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-27 22:49 Notification of new/destroyed connection Chris Taylor
2007-02-28 12:39 ` Pablo Neira Ayuso [this message]
-- strict thread matches above, loose matches on Subject: below --
2007-07-12 8:00 Kerry Ó Cuanacháin
2007-07-12 9:13 Kerry Ó Cuanacháin
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=45E577F3.1070003@netfilter.org \
--to=pablo@netfilter.org \
--cc=chtaylo4@gmail.com \
--cc=netfilter-devel@lists.netfilter.org \
/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.