* [CTNETLINK] Rework conntrack fields dumping logic on events
@ 2006-11-10 1:20 Pablo Neira Ayuso
2006-11-10 21:09 ` Jozsef Kadlecsik
2006-11-23 13:34 ` Patrick McHardy
0 siblings, 2 replies; 10+ messages in thread
From: Pablo Neira Ayuso @ 2006-11-10 1:20 UTC (permalink / raw)
To: Netfilter Development Mailinglist; +Cc: Harald Welte, Patrick McHardy
[-- Attachment #1: Type: text/plain, Size: 890 bytes --]
| NEW | UPDATE | DESTROY |
----------------------------------------|
tuples | Y | Y | Y |
status | Y | Y | N |
timeout | Y | Y | N |
protoinfo | S | S | N |
helper | S | S | N |
mark | S | S | N |
counters | F | F | Y |
Leyend:
Y: yes
N: no
S: iif the field is set
F: iif overflow
This patch also replace IPCT_HELPINFO by IPCT_HELPER since we want to
track the helper assignation process, not the changes in the private
information held by the helper.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
--
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
[-- Attachment #2: 03events.patch --]
[-- Type: text/plain, Size: 5839 bytes --]
[CTNETLINK] Rework conntrack fields dumping logic on events
| NEW | UPDATE | DESTROY |
----------------------------------------|
tuples | Y | Y | Y |
status | Y | Y | N |
timeout | Y | Y | N |
protoinfo | S | S | N |
helper | S | S | N |
mark | S | S | N |
counters | F | F | Y |
Leyend:
Y: yes
N: no
S: iif the field is set
F: iif overflow
This patch also replace IPCT_HELPINFO by IPCT_HELPER since we want to track
the helper assignation process, not the changes in the private information
held by the helper.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Index: linux-2.6.git/net/netfilter/nf_conntrack_netlink.c
===================================================================
--- linux-2.6.git.orig/net/netfilter/nf_conntrack_netlink.c 2006-11-08 23:55:49.000000000 +0100
+++ linux-2.6.git/net/netfilter/nf_conntrack_netlink.c 2006-11-10 01:02:19.000000000 +0100
@@ -329,8 +329,6 @@ static int ctnetlink_conntrack_event(str
} else if (events & (IPCT_NEW | IPCT_RELATED)) {
type = IPCTNL_MSG_CT_NEW;
flags = NLM_F_CREATE|NLM_F_EXCL;
- /* dump everything */
- events = ~0UL;
group = NFNLGRP_CONNTRACK_NEW;
} else if (events & (IPCT_STATUS | IPCT_PROTOINFO)) {
type = IPCTNL_MSG_CT_NEW;
@@ -365,28 +363,35 @@ static int ctnetlink_conntrack_event(str
if (ctnetlink_dump_tuples(skb, tuple(ct, IP_CT_DIR_REPLY)) < 0)
goto nfattr_failure;
NFA_NEST_END(skb, nest_parms);
-
- /* NAT stuff is now a status flag */
- if ((events & IPCT_STATUS || events & IPCT_NATINFO)
- && ctnetlink_dump_status(skb, ct) < 0)
- goto nfattr_failure;
- if (events & IPCT_REFRESH
- && ctnetlink_dump_timeout(skb, ct) < 0)
- goto nfattr_failure;
- if (events & IPCT_PROTOINFO
- && ctnetlink_dump_protoinfo(skb, ct) < 0)
- goto nfattr_failure;
- if (events & IPCT_HELPINFO
- && ctnetlink_dump_helpinfo(skb, ct) < 0)
- goto nfattr_failure;
- if (ctnetlink_dump_counters(skb, ct, IP_CT_DIR_ORIGINAL) < 0 ||
- ctnetlink_dump_counters(skb, ct, IP_CT_DIR_REPLY) < 0)
- goto nfattr_failure;
+ if (events & IPCT_DESTROY) {
+ if (ctnetlink_dump_counters(skb, ct, IP_CT_DIR_ORIGINAL) < 0 ||
+ ctnetlink_dump_counters(skb, ct, IP_CT_DIR_REPLY) < 0)
+ goto nfattr_failure;
+ } else {
+ if (ctnetlink_dump_status(skb, ct) < 0)
+ goto nfattr_failure;
- if (events & IPCT_MARK
- && ctnetlink_dump_mark(skb, ct) < 0)
- goto nfattr_failure;
+ if (ctnetlink_dump_timeout(skb, ct) < 0)
+ goto nfattr_failure;
+
+ if (events & IPCT_PROTOINFO
+ && ctnetlink_dump_protoinfo(skb, ct) < 0)
+ goto nfattr_failure;
+
+ if ((events & IPCT_HELPER || nfct_help(ct))
+ && ctnetlink_dump_helpinfo(skb, ct) < 0)
+ goto nfattr_failure;
+
+ if ((events & IPCT_MARK || ct->mark)
+ && ctnetlink_dump_mark(skb, ct) < 0)
+ goto nfattr_failure;
+
+ if (events & IPCT_COUNTER_FILLING &&
+ (ctnetlink_dump_counters(skb, ct, IP_CT_DIR_ORIGINAL) < 0 ||
+ ctnetlink_dump_counters(skb, ct, IP_CT_DIR_REPLY) < 0))
+ goto nfattr_failure;
+ }
nlh->nlmsg_len = skb->tail - b;
nfnetlink_send(skb, 0, group, 0);
Index: linux-2.6.git/net/ipv4/netfilter/ip_conntrack_netlink.c
===================================================================
--- linux-2.6.git.orig/net/ipv4/netfilter/ip_conntrack_netlink.c 2006-11-08 23:54:55.000000000 +0100
+++ linux-2.6.git/net/ipv4/netfilter/ip_conntrack_netlink.c 2006-11-10 01:02:21.000000000 +0100
@@ -319,8 +319,6 @@ static int ctnetlink_conntrack_event(str
} else if (events & (IPCT_NEW | IPCT_RELATED)) {
type = IPCTNL_MSG_CT_NEW;
flags = NLM_F_CREATE|NLM_F_EXCL;
- /* dump everything */
- events = ~0UL;
group = NFNLGRP_CONNTRACK_NEW;
} else if (events & (IPCT_STATUS | IPCT_PROTOINFO)) {
type = IPCTNL_MSG_CT_NEW;
@@ -355,28 +353,35 @@ static int ctnetlink_conntrack_event(str
if (ctnetlink_dump_tuples(skb, tuple(ct, IP_CT_DIR_REPLY)) < 0)
goto nfattr_failure;
NFA_NEST_END(skb, nest_parms);
-
- /* NAT stuff is now a status flag */
- if ((events & IPCT_STATUS || events & IPCT_NATINFO)
- && ctnetlink_dump_status(skb, ct) < 0)
- goto nfattr_failure;
- if (events & IPCT_REFRESH
- && ctnetlink_dump_timeout(skb, ct) < 0)
- goto nfattr_failure;
- if (events & IPCT_PROTOINFO
- && ctnetlink_dump_protoinfo(skb, ct) < 0)
- goto nfattr_failure;
- if (events & IPCT_HELPINFO
- && ctnetlink_dump_helpinfo(skb, ct) < 0)
- goto nfattr_failure;
- if (ctnetlink_dump_counters(skb, ct, IP_CT_DIR_ORIGINAL) < 0 ||
- ctnetlink_dump_counters(skb, ct, IP_CT_DIR_REPLY) < 0)
- goto nfattr_failure;
+ if (events & IPCT_DESTROY) {
+ if (ctnetlink_dump_counters(skb, ct, IP_CT_DIR_ORIGINAL) < 0 ||
+ ctnetlink_dump_counters(skb, ct, IP_CT_DIR_REPLY) < 0)
+ goto nfattr_failure;
+ } else {
+ if (ctnetlink_dump_status(skb, ct) < 0)
+ goto nfattr_failure;
- if (events & IPCT_MARK
- && ctnetlink_dump_mark(skb, ct) < 0)
- goto nfattr_failure;
+ if (ctnetlink_dump_timeout(skb, ct) < 0)
+ goto nfattr_failure;
+
+ if (events & IPCT_PROTOINFO
+ && ctnetlink_dump_protoinfo(skb, ct) < 0)
+ goto nfattr_failure;
+
+ if ((events & IPCT_HELPER || ct->helper)
+ && ctnetlink_dump_helpinfo(skb, ct) < 0)
+ goto nfattr_failure;
+
+ if ((events & IPCT_MARK || ct->mark)
+ && ctnetlink_dump_mark(skb, ct) < 0)
+ goto nfattr_failure;
+
+ if (events & IPCT_COUNTER_FILLING &&
+ (ctnetlink_dump_counters(skb, ct, IP_CT_DIR_ORIGINAL) < 0 ||
+ ctnetlink_dump_counters(skb, ct, IP_CT_DIR_REPLY) < 0))
+ goto nfattr_failure;
+ }
nlh->nlmsg_len = skb->tail - b;
nfnetlink_send(skb, 0, group, 0);
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [CTNETLINK] Rework conntrack fields dumping logic on events
2006-11-10 1:20 [CTNETLINK] Rework conntrack fields dumping logic on events Pablo Neira Ayuso
@ 2006-11-10 21:09 ` Jozsef Kadlecsik
2006-11-12 23:42 ` Pablo Neira Ayuso
2006-11-23 13:34 ` Patrick McHardy
1 sibling, 1 reply; 10+ messages in thread
From: Jozsef Kadlecsik @ 2006-11-10 21:09 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Harald Welte, Netfilter Development Mailinglist, Patrick McHardy
Hi,
On Fri, 10 Nov 2006, Pablo Neira Ayuso wrote:
> This patch also replace IPCT_HELPINFO by IPCT_HELPER since we want to
> track the helper assignation process, not the changes in the private
> information held by the helper.
Actually, how it is solved to pass the setting of dynamically assigned
(i.e. currently not registered) helpers? What about registering such
helpers with non-matching address/proto/port parameters?
Best regards,
Jozsef
-
E-mail : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [CTNETLINK] Rework conntrack fields dumping logic on events
2006-11-10 21:09 ` Jozsef Kadlecsik
@ 2006-11-12 23:42 ` Pablo Neira Ayuso
2006-11-14 20:01 ` Jozsef Kadlecsik
0 siblings, 1 reply; 10+ messages in thread
From: Pablo Neira Ayuso @ 2006-11-12 23:42 UTC (permalink / raw)
To: Jozsef Kadlecsik
Cc: Harald Welte, Netfilter Development Mailinglist, Patrick McHardy
Hi Jozsef,
Jozsef Kadlecsik wrote:
> On Fri, 10 Nov 2006, Pablo Neira Ayuso wrote:
>
>> This patch also replace IPCT_HELPINFO by IPCT_HELPER since we want to
>> track the helper assignation process, not the changes in the private
>> information held by the helper.
>
> Actually, how it is solved to pass the setting of dynamically assigned
> (i.e. currently not registered) helpers? What about registering such
> helpers with non-matching address/proto/port parameters?
I'm unsure that I understand the question. Currently ctnetlink cannot
assign a helper that is not registered. Therefore, in order to register
a helper with non-matching parameter, wouldn't we need a new parameter
at modprobe stage? Perhaps some kind of userspace tool to manage helper
matching parameters could be interesting.
--
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [CTNETLINK] Rework conntrack fields dumping logic on events
2006-11-12 23:42 ` Pablo Neira Ayuso
@ 2006-11-14 20:01 ` Jozsef Kadlecsik
2006-11-14 20:50 ` Sven Schuster
2006-11-23 13:18 ` Patrick McHardy
0 siblings, 2 replies; 10+ messages in thread
From: Jozsef Kadlecsik @ 2006-11-14 20:01 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Harald Welte, Netfilter Development Mailinglist, Patrick McHardy
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1259 bytes --]
Hi Pablo,
On Mon, 13 Nov 2006, Pablo Neira Ayuso wrote:
> > Actually, how it is solved to pass the setting of dynamically assigned
> > (i.e. currently not registered) helpers? What about registering such
> > helpers with non-matching address/proto/port parameters?
>
> I'm unsure that I understand the question. Currently ctnetlink cannot
> assign a helper that is not registered. Therefore, in order to register
> a helper with non-matching parameter, wouldn't we need a new parameter
> at modprobe stage? Perhaps some kind of userspace tool to manage helper
> matching parameters could be interesting.
The attached patch (on top of Patrick's nf_nat git tree and my patches
sent to this list) implements what I suggested: *do* register the helpers
which are actually assigned by an expectfn. Thus ctnetlink can find them
by name and then fill conntrack with the helper. In order to make sure a
bogus packet can't trigger such helpers, __nf_ct_helper_find had to be
modified. What do you think?
Best regards,
Jozsef
-
E-mail : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
H-1525 Budapest 114, POB. 49, Hungary
[-- Attachment #2: netlink.patch --]
[-- Type: TEXT/PLAIN, Size: 2667 bytes --]
diff -urN --exclude-from=/usr/src/diff.exclude linux-2.6.20-nat-core/include/net/netfilter/nf_conntrack_helper.h linux-2.6.20-netlink/include/net/netfilter/nf_conntrack_helper.h
--- linux-2.6.20-nat-core/include/net/netfilter/nf_conntrack_helper.h 2006-11-06 14:08:15.000000000 +0100
+++ linux-2.6.20-netlink/include/net/netfilter/nf_conntrack_helper.h 2006-11-14 17:02:40.000000000 +0100
@@ -23,7 +23,9 @@
* expected connections */
unsigned int timeout; /* timeout for expecteds */
- /* Mask of things we will help (compared against server response) */
+ /* Mask of things we will help (compared against server response):
+ * tuple.src.u must be set to zero for dynamic helpers, i.e. which
+ * are attached by an expectfn to the conntrack entry */
struct nf_conntrack_tuple tuple;
struct nf_conntrack_tuple mask;
diff -urN --exclude-from=/usr/src/diff.exclude linux-2.6.20-nat-core/net/netfilter/nf_conntrack_helper.c linux-2.6.20-netlink/net/netfilter/nf_conntrack_helper.c
--- linux-2.6.20-nat-core/net/netfilter/nf_conntrack_helper.c 2006-11-06 14:08:15.000000000 +0100
+++ linux-2.6.20-netlink/net/netfilter/nf_conntrack_helper.c 2006-11-14 16:44:45.000000000 +0100
@@ -35,8 +35,13 @@
struct nf_conntrack_helper *h;
list_for_each_entry(h, &helpers, list) {
- if (nf_ct_tuple_mask_cmp(tuple, &h->tuple, &h->mask))
- return h;
+ if (nf_ct_tuple_mask_cmp(tuple, &h->tuple, &h->mask)) {
+ /* Ignore dynamic helpers: we should log it */
+ if (h->tuple.src.u)
+ return h;
+ else
+ return NULL
+ }
}
return NULL;
}
diff -urN --exclude-from=/usr/src/diff.exclude linux-2.6.20-nat-core/net/netfilter/nf_conntrack_helper_h323.c linux-2.6.20-netlink/net/netfilter/nf_conntrack_helper_h323.c
--- linux-2.6.20-nat-core/net/netfilter/nf_conntrack_helper_h323.c 2006-11-06 14:39:04.000000000 +0100
+++ linux-2.6.20-netlink/net/netfilter/nf_conntrack_helper_h323.c 2006-11-13 17:50:48.000000000 +0100
@@ -1770,6 +1770,7 @@
/* Not __exit - called from init() */
static void fini(void)
{
+ nf_conntrack_helper_unregister(&nf_conntrack_helper_h245);
nf_conntrack_helper_unregister(&nf_conntrack_helper_ras);
nf_conntrack_helper_unregister(&nf_conntrack_helper_q931);
kfree(h323_buffer);
@@ -1785,7 +1786,8 @@
if (!h323_buffer)
return -ENOMEM;
if ((ret = nf_conntrack_helper_register(&nf_conntrack_helper_q931)) ||
- (ret = nf_conntrack_helper_register(&nf_conntrack_helper_ras))) {
+ (ret = nf_conntrack_helper_register(&nf_conntrack_helper_ras)) ||
+ (ret = nf_conntrack_helper_register(&nf_conntrack_helper_h245))) {
fini();
return ret;
}
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [CTNETLINK] Rework conntrack fields dumping logic on events
2006-11-14 20:01 ` Jozsef Kadlecsik
@ 2006-11-14 20:50 ` Sven Schuster
2006-11-15 7:43 ` Jozsef Kadlecsik
2006-11-23 13:18 ` Patrick McHardy
1 sibling, 1 reply; 10+ messages in thread
From: Sven Schuster @ 2006-11-14 20:50 UTC (permalink / raw)
To: Jozsef Kadlecsik
Cc: Harald Welte, Netfilter Development Mailinglist, Patrick McHardy,
Pablo Neira Ayuso
[-- Attachment #1: Type: text/plain, Size: 3097 bytes --]
Hi Jozsef,
On Tue, Nov 14, 2006 at 09:01:32PM +0100, Jozsef Kadlecsik told us:
> diff -urN --exclude-from=/usr/src/diff.exclude linux-2.6.20-nat-core/include/net/netfilter/nf_conntrack_helper.h linux-2.6.20-netlink/include/net/netfilter/nf_conntrack_helper.h
> --- linux-2.6.20-nat-core/include/net/netfilter/nf_conntrack_helper.h 2006-11-06 14:08:15.000000000 +0100
> +++ linux-2.6.20-netlink/include/net/netfilter/nf_conntrack_helper.h 2006-11-14 17:02:40.000000000 +0100
> @@ -23,7 +23,9 @@
> * expected connections */
> unsigned int timeout; /* timeout for expecteds */
>
> - /* Mask of things we will help (compared against server response) */
> + /* Mask of things we will help (compared against server response):
> + * tuple.src.u must be set to zero for dynamic helpers, i.e. which
> + * are attached by an expectfn to the conntrack entry */
> struct nf_conntrack_tuple tuple;
> struct nf_conntrack_tuple mask;
>
> diff -urN --exclude-from=/usr/src/diff.exclude linux-2.6.20-nat-core/net/netfilter/nf_conntrack_helper.c linux-2.6.20-netlink/net/netfilter/nf_conntrack_helper.c
> --- linux-2.6.20-nat-core/net/netfilter/nf_conntrack_helper.c 2006-11-06 14:08:15.000000000 +0100
> +++ linux-2.6.20-netlink/net/netfilter/nf_conntrack_helper.c 2006-11-14 16:44:45.000000000 +0100
> @@ -35,8 +35,13 @@
> struct nf_conntrack_helper *h;
>
> list_for_each_entry(h, &helpers, list) {
> - if (nf_ct_tuple_mask_cmp(tuple, &h->tuple, &h->mask))
> - return h;
> + if (nf_ct_tuple_mask_cmp(tuple, &h->tuple, &h->mask)) {
> + /* Ignore dynamic helpers: we should log it */
> + if (h->tuple.src.u)
> + return h;
> + else
> + return NULL
missing a ';'??
Kind regards,
Sven
> + }
> }
> return NULL;
> }
> diff -urN --exclude-from=/usr/src/diff.exclude linux-2.6.20-nat-core/net/netfilter/nf_conntrack_helper_h323.c linux-2.6.20-netlink/net/netfilter/nf_conntrack_helper_h323.c
> --- linux-2.6.20-nat-core/net/netfilter/nf_conntrack_helper_h323.c 2006-11-06 14:39:04.000000000 +0100
> +++ linux-2.6.20-netlink/net/netfilter/nf_conntrack_helper_h323.c 2006-11-13 17:50:48.000000000 +0100
> @@ -1770,6 +1770,7 @@
> /* Not __exit - called from init() */
> static void fini(void)
> {
> + nf_conntrack_helper_unregister(&nf_conntrack_helper_h245);
> nf_conntrack_helper_unregister(&nf_conntrack_helper_ras);
> nf_conntrack_helper_unregister(&nf_conntrack_helper_q931);
> kfree(h323_buffer);
> @@ -1785,7 +1786,8 @@
> if (!h323_buffer)
> return -ENOMEM;
> if ((ret = nf_conntrack_helper_register(&nf_conntrack_helper_q931)) ||
> - (ret = nf_conntrack_helper_register(&nf_conntrack_helper_ras))) {
> + (ret = nf_conntrack_helper_register(&nf_conntrack_helper_ras)) ||
> + (ret = nf_conntrack_helper_register(&nf_conntrack_helper_h245))) {
> fini();
> return ret;
> }
--
Linux zion.homelinux.com 2.6.18-1.2849.fc6xen #1 SMP Fri Nov 10 13:56:52 EST 2006 i686 athlon i386 GNU/Linux
21:49:08 up 2 days, 1:03, 1 user, load average: 0.00, 0.03, 0.06
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [CTNETLINK] Rework conntrack fields dumping logic on events
2006-11-14 20:50 ` Sven Schuster
@ 2006-11-15 7:43 ` Jozsef Kadlecsik
0 siblings, 0 replies; 10+ messages in thread
From: Jozsef Kadlecsik @ 2006-11-15 7:43 UTC (permalink / raw)
To: Sven Schuster
Cc: Harald Welte, Netfilter Development Mailinglist, Patrick McHardy,
Pablo Neira Ayuso
On Tue, 14 Nov 2006, Sven Schuster wrote:
> > list_for_each_entry(h, &helpers, list) {
> > - if (nf_ct_tuple_mask_cmp(tuple, &h->tuple, &h->mask))
> > - return h;
> > + if (nf_ct_tuple_mask_cmp(tuple, &h->tuple, &h->mask)) {
> > + /* Ignore dynamic helpers: we should log it */
> > + if (h->tuple.src.u)
> > + return h;
> > + else
> > + return NULL
>
> missing a ';'??
Yes! I should have compiled the patched kernel. :-(
Best regards,
Jozsef
-
E-mail : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [CTNETLINK] Rework conntrack fields dumping logic on events
2006-11-14 20:01 ` Jozsef Kadlecsik
2006-11-14 20:50 ` Sven Schuster
@ 2006-11-23 13:18 ` Patrick McHardy
2006-11-23 13:46 ` Jozsef Kadlecsik
1 sibling, 1 reply; 10+ messages in thread
From: Patrick McHardy @ 2006-11-23 13:18 UTC (permalink / raw)
To: Jozsef Kadlecsik
Cc: Harald Welte, Netfilter Development Mailinglist,
Pablo Neira Ayuso
Jozsef Kadlecsik wrote:
> Hi Pablo,
>
> On Mon, 13 Nov 2006, Pablo Neira Ayuso wrote:
>
>
>>>Actually, how it is solved to pass the setting of dynamically assigned
>>>(i.e. currently not registered) helpers? What about registering such
>>>helpers with non-matching address/proto/port parameters?
>>
>>I'm unsure that I understand the question. Currently ctnetlink cannot
>>assign a helper that is not registered. Therefore, in order to register
>>a helper with non-matching parameter, wouldn't we need a new parameter
>>at modprobe stage? Perhaps some kind of userspace tool to manage helper
>>matching parameters could be interesting.
>
>
> The attached patch (on top of Patrick's nf_nat git tree and my patches
> sent to this list) implements what I suggested: *do* register the helpers
> which are actually assigned by an expectfn. Thus ctnetlink can find them
> by name and then fill conntrack with the helper. In order to make sure a
> bogus packet can't trigger such helpers, __nf_ct_helper_find had to be
> modified. What do you think?
This is something needed for userspace-helpers (Harald did some work
in this direction), but I can't really think of what it could be used
for currently.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [CTNETLINK] Rework conntrack fields dumping logic on events
2006-11-23 13:18 ` Patrick McHardy
@ 2006-11-23 13:46 ` Jozsef Kadlecsik
2006-11-23 13:56 ` Patrick McHardy
0 siblings, 1 reply; 10+ messages in thread
From: Jozsef Kadlecsik @ 2006-11-23 13:46 UTC (permalink / raw)
To: Patrick McHardy
Cc: Harald Welte, Netfilter Development Mailinglist,
Pablo Neira Ayuso
Hi Patrick,
On Thu, 23 Nov 2006, Patrick McHardy wrote:
> > The attached patch (on top of Patrick's nf_nat git tree and my patches
> > sent to this list) implements what I suggested: *do* register the helpers
> > which are actually assigned by an expectfn. Thus ctnetlink can find them
> > by name and then fill conntrack with the helper. In order to make sure a
> > bogus packet can't trigger such helpers, __nf_ct_helper_find had to be
> > modified. What do you think?
>
> This is something needed for userspace-helpers (Harald did some work
> in this direction), but I can't really think of what it could be used
> for currently.
It is required at conntrack replication if/when the H.323 helper is in
use. The H.245 helper is currently not registered so there is no
way to replicate the helper: the name is passed but the other side is
unable to find the helper on the list of the registered helpers.
Best regards,
Jozsef
-
E-mail : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [CTNETLINK] Rework conntrack fields dumping logic on events
2006-11-23 13:46 ` Jozsef Kadlecsik
@ 2006-11-23 13:56 ` Patrick McHardy
0 siblings, 0 replies; 10+ messages in thread
From: Patrick McHardy @ 2006-11-23 13:56 UTC (permalink / raw)
To: Jozsef Kadlecsik
Cc: Harald Welte, Netfilter Development Mailinglist,
Pablo Neira Ayuso
Jozsef Kadlecsik wrote:
> Hi Patrick,
>
> On Thu, 23 Nov 2006, Patrick McHardy wrote:
>
>
>>>The attached patch (on top of Patrick's nf_nat git tree and my patches
>>>sent to this list) implements what I suggested: *do* register the helpers
>>>which are actually assigned by an expectfn. Thus ctnetlink can find them
>>>by name and then fill conntrack with the helper. In order to make sure a
>>>bogus packet can't trigger such helpers, __nf_ct_helper_find had to be
>>>modified. What do you think?
>>
>>This is something needed for userspace-helpers (Harald did some work
>>in this direction), but I can't really think of what it could be used
>>for currently.
>
>
> It is required at conntrack replication if/when the H.323 helper is in
> use. The H.245 helper is currently not registered so there is no
> way to replicate the helper: the name is passed but the other side is
> unable to find the helper on the list of the registered helpers.
Good point :) But instead of overloading tuple semantics a flag would
be cleaner IMO and would allow us to skip them quickly
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [CTNETLINK] Rework conntrack fields dumping logic on events
2006-11-10 1:20 [CTNETLINK] Rework conntrack fields dumping logic on events Pablo Neira Ayuso
2006-11-10 21:09 ` Jozsef Kadlecsik
@ 2006-11-23 13:34 ` Patrick McHardy
1 sibling, 0 replies; 10+ messages in thread
From: Patrick McHardy @ 2006-11-23 13:34 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: Harald Welte, Netfilter Development Mailinglist
Pablo Neira Ayuso wrote:
> [CTNETLINK] Rework conntrack fields dumping logic on events
Also applied, thanks for staying persistent :)
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2006-11-23 13:56 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-11-10 1:20 [CTNETLINK] Rework conntrack fields dumping logic on events Pablo Neira Ayuso
2006-11-10 21:09 ` Jozsef Kadlecsik
2006-11-12 23:42 ` Pablo Neira Ayuso
2006-11-14 20:01 ` Jozsef Kadlecsik
2006-11-14 20:50 ` Sven Schuster
2006-11-15 7:43 ` Jozsef Kadlecsik
2006-11-23 13:18 ` Patrick McHardy
2006-11-23 13:46 ` Jozsef Kadlecsik
2006-11-23 13:56 ` Patrick McHardy
2006-11-23 13:34 ` Patrick McHardy
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.