connection destruction question

connection destruction question

[Kristen Carlson]

Hello,
Is there a way to be notified in a kernel module 
when a connection is destroyed?  I have a nice helper
module that would like to know when connections are destroyed
so it can do some internal cleanup work. 
Thanks,
Kristen

Re: connection destruction question

[Emmanuel Guiton]

Hi!

Did you take a look at the events used in nf_conntrack?
I had a similar problem and I solved it that way. You may have to define 
a new event (in ip_conntrack.h), or may not, I don't remember if it's 
already included. if you have to use a new event, you can send it with 
the ip_conntrack_cache_event() function.

-Emmanuel


Kristen Carlson wrote:

>Hello,
>Is there a way to be notified in a kernel module 
>when a connection is destroyed?  I have a nice helper
>module that would like to know when connections are destroyed
>so it can do some internal cleanup work. 
>Thanks,
>Kristen
>
>  
>

Re: connection destruction question

[Unit Zero]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1193 bytes --]



On Wed, 10 Mar 2004, Kristen Carlson wrote:

> Hello,
> Is there a way to be notified in a kernel module 
> when a connection is destroyed?  I have a nice helper
> module that would like to know when connections are destroyed
> so it can do some internal cleanup work. 
> Thanks,
> Kristen
> 

Actually I ran into the exact same issue not long ago with a module I've 
been working on. My solution was to add a couple lines here and there in 
conntrack_core.c and ip_conntrack.h to implement a notifier chain and 
export register/unregister routines from the ip_conntrack module, allowing 
other modules to add callback functions to the chain. The notifier chain 
is then called from various parts of the conntrack_core code with an 
event-code and a struct ip_conntrack ptr reference when conntracks are 
created, destroyed (either explicitly or by timeout), become confirmed, 
or become replied.

I've got a small patch that I put together about a month ago which has 
my modifications described above. I'm pretty sure it will apply cleanly 
to a 2.4.24-25 kernel source tree, but if not the modifications are pretty 
straight forward. Just thought it might be of interest.

- V. M. Condino

[-- Attachment #2: conntrack-notifiers patch --]
[-- Type: TEXT/PLAIN, Size: 4139 bytes --]

--- linux/net/ipv4/netfilter/ip_conntrack_core.c	2004-02-19 03:11:14.000000000 -0500
+++ linux-nfhack/net/ipv4/netfilter/ip_conntrack_core.c	2004-02-23 19:34:50.000000000 -0500
@@ -64,6 +64,17 @@
 static atomic_t ip_conntrack_count = ATOMIC_INIT(0);
 struct list_head *ip_conntrack_hash;
 static kmem_cache_t *ip_conntrack_cachep;
+struct notifier_block *ip_ct_notify_chain = NULL;
+
+int register_conntrack_notifier(struct notifier_block *nb)
+{
+  return notifier_chain_register(&ip_ct_notify_chain, nb);
+}
+
+int unregister_conntrack_notifier(struct notifier_block *nb)
+{
+  return notifier_chain_unregister(&ip_ct_notify_chain, nb);
+}
 
 extern struct ip_conntrack_protocol ip_conntrack_generic_protocol;
 
@@ -315,6 +326,8 @@
 	IP_NF_ASSERT(atomic_read(&nfct->use) == 0);
 	IP_NF_ASSERT(!timer_pending(&ct->timeout));
 
+	notifier_call_chain(&ip_ct_notify_chain, IP_CT_NOTIFY_DESTROYED, (void*)ct);
+	
 	/* To make sure we don't get any weird locking issues here:
 	 * destroy_conntrack() MUST NOT be called with a write lock
 	 * to ip_conntrack_lock!!! -HW */
@@ -791,19 +797,22 @@
 		if (test_bit(IPS_SEEN_REPLY_BIT, &h->ctrack->status)) {
 			DEBUGP("ip_conntrack_in: normal packet for %p\n",
 			       h->ctrack);
+			      if(*ctinfo != IP_CT_ESTABLISHED)
 		        *ctinfo = IP_CT_ESTABLISHED;
 		} else if (test_bit(IPS_EXPECTED_BIT, &h->ctrack->status)) {
 			DEBUGP("ip_conntrack_in: related packet for %p\n",
 			       h->ctrack);
 			*ctinfo = IP_CT_RELATED;
+			notifier_call_chain(&ip_ct_notify_chain, IP_CT_NOTIFY_RELATED, (void *)h->ctrack);
 		} else {
 			DEBUGP("ip_conntrack_in: new packet for %p\n",
 			       h->ctrack);
 			*ctinfo = IP_CT_NEW;
+			notifier_call_chain(&ip_ct_notify_chain, IP_CT_NOTIFY_NEW, (void *)h->ctrack);
 		}
 		*set_reply = 0;
 	}
 	skb->nfct = &h->ctrack->infos[*ctinfo];
 	return h->ctrack;
 }
 
@@ -893,6 +894,10 @@
 			return NF_ACCEPT;
 		}
 	}
+	
+	if(set_reply && (! test_bit(IPS_SEEN_REPLY_BIT, &ct->status)))
+		notifier_call_chain(&ip_ct_notify_chain, IP_CT_NOTIFY_ESTABLISHED, (void *)ct);
+	
 	if (set_reply)
 		set_bit(IPS_SEEN_REPLY_BIT, &ct->status);
 
@@ -514,2 +509,4 @@
 EXPORT_SYMBOL_GPL(ip_conntrack_find_get);
 EXPORT_SYMBOL_GPL(ip_conntrack_put);
+EXPORT_SYMBOL(register_conntrack_notifier);
+EXPORT_SYMBOL(unregister_conntrack_notifier);
--- linux/include/linux/netfilter_ipv4/ip_conntrack.h	2004-02-19 12:46:33.000000000 -0500
+++ linux-nfhack/include/linux/netfilter_ipv4/ip_conntrack.h	2004-02-23 19:40:58.000000000 -0500
@@ -210,2 +210,38 @@

+/*
+ * V. M. Condino 2004/02/24 -- My REALLY quick-n-dirty conntrack
+ * event notification hack. It "works for me"... I tested this out
+ * for about 5 minutes last night and got it basically working
+ * "bug free" (i.e. got through a whole HTTP connect, close and
+ * then conntrack finally timing out and destructing, without
+ * even so much as an unhappy-looking printk() from anything :)
+ *
+ * currently i am using this code for a separate ip_statistics
+ * collection module (maintaining hashes for various different
+ * groups of connections, so that matches like connlimit can be
+ * performed with a single hash-lookup, instead of creating and
+ * managing an entire hash table all internally for a single
+ * match.) I plan on extending the conntrack_notifiers stuff
+ * here much more, so I will be posting much more finalized
+ * version on netfilter-devel in the future.
+ *
+ * feel free to contact me at <onyx@zero.fdns.net> or
+ * <onyx@squirrelsoup.net> if you want to discuss anything
+ * about this code.  - V. M. Condino 
+ */
+
+enum ip_ct_notify_event {
+	IP_CT_NOTIFY_NONE = 0,
+	IP_CT_NOTIFY_NEW = 1,
+	IP_CT_NOTIFY_RELATED = 2,
+	IP_CT_NOTIFY_ESTABLISHED = 3,
+	IP_CT_NOTIFY_REPLIED = 4,
+	IP_CT_NOTIFY_DESTROYED = 5
+};
+ 
+extern struct notifier_block *ip_ct_notify_chain;
+
+extern int register_conntrack_notifier(struct notifier_block *nb);
+extern int unregister_conntrack_notifier(struct notifier_block *nb);
+
+
 /* get master conntrack via master expectation */

Re: connection destruction question

[Kristen Carlson]

> Hi!
> 
> Did you take a look at the events used in nf_conntrack?
> I had a similar problem and I solved it that way. You may have to define 
> a new event (in ip_conntrack.h), or may not, I don't remember if it's 
> already included. if you have to use a new event, you can send it with 
> the ip_conntrack_cache_event() function.


	Hum, I don't see any such thing in my kernel version.  I'm using
a kernel for an embedded system, so it isn't straight forward for me to 
upgrade.  I should have specified: on 2.4.18.  Unless I am insane and 
this is really somewhere I didn't grep properly.  I didn't see it in
net/ipv4/netfilter or include/linux/netfilter_ipv4.

> 
> -Emmanuel
> 
> 
> Kristen Carlson wrote:
> 
> >Hello,
> >Is there a way to be notified in a kernel module 
> >when a connection is destroyed?  I have a nice helper
> >module that would like to know when connections are destroyed
> >so it can do some internal cleanup work. 
> >Thanks,
> >Kristen
> >
> >  
> >
> 
> 
> 
> 

Re: connection destruction question

[Henrik Nordstrom]

On Thu, 11 Mar 2004, Kristen Carlson wrote:

> > Did you take a look at the events used in nf_conntrack?
> 
> 	Hum, I don't see any such thing in my kernel version.  I'm using
> a kernel for an embedded system, so it isn't straight forward for me to 
> upgrade.  I should have specified: on 2.4.18.  Unless I am insane and 
> this is really somewhere I didn't grep properly.  I didn't see it in
> net/ipv4/netfilter or include/linux/netfilter_ipv4.

nf_conntrack is part of the nfnetlink-ctnetlink-0.13 patch in 
iptables patch-o-matic.

Regards
Henrik

Re: connection destruction question

[Emmanuel Guiton]

Hi!

No, you're not insane: you need the patch. I'm not sure it's available 
for 2.4.18, but at least it is for 2.4.23 (as it is what I use).

          Emmanuel



Kristen Carlson wrote:

>>Hi!
>>
>>Did you take a look at the events used in nf_conntrack?
>>I had a similar problem and I solved it that way. You may have to define 
>>a new event (in ip_conntrack.h), or may not, I don't remember if it's 
>>already included. if you have to use a new event, you can send it with 
>>the ip_conntrack_cache_event() function.
>>    
>>
>
>
>	Hum, I don't see any such thing in my kernel version.  I'm using
>a kernel for an embedded system, so it isn't straight forward for me to 
>upgrade.  I should have specified: on 2.4.18.  Unless I am insane and 
>this is really somewhere I didn't grep properly.  I didn't see it in
>net/ipv4/netfilter or include/linux/netfilter_ipv4.
>  
>

RE: connection destruction question

[Accardi, Kristen C]

Thank you, that does interest me.  It does seem to match my needs more
closely than the other patch. I also have realized that my approach of
making a helper module to be notified when connections were created
wasn't going to work since I realized it would only be called on the
master connection and not on any of the related connections, and I need
to see state changes for all connections.  I will take a look at the
patch and see if it works out.

By the way, what are your plans for this patch?  I always hate the idea
of using a patch I actually have to maintain myself :), although of
course I will do that if that's what it takes to get my job done.

Kristen



-----Original Message-----
From: netfilter-devel-admin@lists.netfilter.org
[mailto:netfilter-devel-admin@lists.netfilter.org] On Behalf Of Unit
Zero
Sent: Friday, March 19, 2004 7:34 AM
To: Kristen Carlson
Cc: netfilter-devel@lists.netfilter.org
Subject: Re: connection destruction question




On Wed, 10 Mar 2004, Kristen Carlson wrote:

> Hello,
> Is there a way to be notified in a kernel module 
> when a connection is destroyed?  I have a nice helper
> module that would like to know when connections are destroyed
> so it can do some internal cleanup work. 
> Thanks,
> Kristen
> 

Actually I ran into the exact same issue not long ago with a module I've

been working on. My solution was to add a couple lines here and there in

conntrack_core.c and ip_conntrack.h to implement a notifier chain and 
export register/unregister routines from the ip_conntrack module,
allowing 
other modules to add callback functions to the chain. The notifier chain

is then called from various parts of the conntrack_core code with an 
event-code and a struct ip_conntrack ptr reference when conntracks are 
created, destroyed (either explicitly or by timeout), become confirmed, 
or become replied.

I've got a small patch that I put together about a month ago which has 
my modifications described above. I'm pretty sure it will apply cleanly 
to a 2.4.24-25 kernel source tree, but if not the modifications are
pretty 
straight forward. Just thought it might be of interest.

- V. M. Condino