* [H.323 Helper 1/3]: Add support for Call Forwarding
@ 2006-04-24 3:40 Jing Min Zhao
2006-04-26 13:48 ` Patrick McHardy
0 siblings, 1 reply; 14+ messages in thread
From: Jing Min Zhao @ 2006-04-24 3:40 UTC (permalink / raw)
To: netfilter-devel
[-- Attachment #1: Type: text/plain, Size: 170 bytes --]
This patch is for 2.6.17-rc2. Please visit
http://nath323.sourceforge.net/#_Toc133598071 for details.
Signed-off-by: Jing Min Zhao <zhaojingmin@users.sourceforge.net>
[-- Attachment #2: nath323-callforwarding --]
[-- Type: application/octet-stream, Size: 13695 bytes --]
diff -pruN linux-2.6.17-rc2.a/include/linux/netfilter_ipv4/ip_conntrack.h linux-2.6.17-rc2.b/include/linux/netfilter_ipv4/ip_conntrack.h
--- linux-2.6.17-rc2.a/include/linux/netfilter_ipv4/ip_conntrack.h 2006-04-21 20:37:26.000000000 -0400
+++ linux-2.6.17-rc2.b/include/linux/netfilter_ipv4/ip_conntrack.h 2006-04-21 20:41:11.000000000 -0400
@@ -154,6 +154,7 @@ struct ip_conntrack_expect
unsigned int flags;
#ifdef CONFIG_IP_NF_NAT_NEEDED
+ u_int32_t saved_ip;
/* This is the original per-proto part, used to map the
* expected connection the way the recipient expects. */
union ip_conntrack_manip_proto saved_proto;
diff -pruN linux-2.6.17-rc2.a/include/linux/netfilter_ipv4/ip_conntrack_h323.h linux-2.6.17-rc2.b/include/linux/netfilter_ipv4/ip_conntrack_h323.h
--- linux-2.6.17-rc2.a/include/linux/netfilter_ipv4/ip_conntrack_h323.h 2006-04-21 20:37:26.000000000 -0400
+++ linux-2.6.17-rc2.b/include/linux/netfilter_ipv4/ip_conntrack_h323.h 2006-04-21 20:41:11.000000000 -0400
@@ -71,6 +71,13 @@ extern int (*nat_h245_hook) (struct sk_b
unsigned char **data, int dataoff,
TransportAddress * addr, u_int16_t port,
struct ip_conntrack_expect * exp);
+extern int (*nat_callforwarding_hook) (struct sk_buff ** pskb,
+ struct ip_conntrack * ct,
+ enum ip_conntrack_info ctinfo,
+ unsigned char **data, int dataoff,
+ TransportAddress * addr,
+ u_int16_t port,
+ struct ip_conntrack_expect * exp);
extern int (*nat_q931_hook) (struct sk_buff ** pskb, struct ip_conntrack * ct,
enum ip_conntrack_info ctinfo,
unsigned char **data, TransportAddress * addr,
diff -pruN linux-2.6.17-rc2.a/include/linux/netfilter_ipv4/ip_conntrack_helper_h323_types.h linux-2.6.17-rc2.b/include/linux/netfilter_ipv4/ip_conntrack_helper_h323_types.h
--- linux-2.6.17-rc2.a/include/linux/netfilter_ipv4/ip_conntrack_helper_h323_types.h 2006-04-21 20:37:26.000000000 -0400
+++ linux-2.6.17-rc2.b/include/linux/netfilter_ipv4/ip_conntrack_helper_h323_types.h 2006-04-21 20:41:11.000000000 -0400
@@ -1,4 +1,4 @@
-/* Generated by Jing Min Zhao's ASN.1 parser, Mar 15 2006
+/* Generated by Jing Min Zhao's ASN.1 parser, Apr 20 2006
*
* Copyright (c) 2006 Jing Min Zhao <zhaojingmin@users.sourceforge.net>
*
@@ -412,6 +412,7 @@ typedef struct Facility_UUIE { /* SEQUEN
eFacility_UUIE_destinationInfo = (1 << 14),
eFacility_UUIE_h245SecurityMode = (1 << 13),
} options;
+ TransportAddress alternativeAddress;
FacilityReason reason;
TransportAddress h245Address;
Facility_UUIE_fastStart fastStart;
diff -pruN linux-2.6.17-rc2.a/net/ipv4/netfilter/ip_conntrack_helper_h323.c linux-2.6.17-rc2.b/net/ipv4/netfilter/ip_conntrack_helper_h323.c
--- linux-2.6.17-rc2.a/net/ipv4/netfilter/ip_conntrack_helper_h323.c 2006-04-21 20:37:32.000000000 -0400
+++ linux-2.6.17-rc2.b/net/ipv4/netfilter/ip_conntrack_helper_h323.c 2006-04-21 20:41:11.000000000 -0400
@@ -22,6 +22,8 @@
#include <linux/netfilter_ipv4/ip_conntrack_tuple.h>
#include <linux/netfilter_ipv4/ip_conntrack_h323.h>
#include <linux/moduleparam.h>
+#include <linux/ctype.h>
+#include <linux/inet.h>
#if 0
#define DEBUGP printk
@@ -38,6 +40,13 @@ static int gkrouted_only = 1;
module_param(gkrouted_only, int, 0600);
MODULE_PARM_DESC(gkrouted_only, "only accept calls from gatekeeper");
+static char *internal_net = NULL;
+static u_int32_t internal_net_addr = 0;
+static u_int32_t internal_net_mask = 0;
+module_param(internal_net, charp, 0600);
+MODULE_PARM_DESC(internal_net, "specify your internal network using format "
+ "address/mask. this is used by call forwarding support");
+
/* Hooks for NAT */
int (*set_h245_addr_hook) (struct sk_buff ** pskb,
unsigned char **data, int dataoff,
@@ -77,6 +86,12 @@ int (*nat_h245_hook) (struct sk_buff **
unsigned char **data, int dataoff,
TransportAddress * addr, u_int16_t port,
struct ip_conntrack_expect * exp);
+int (*nat_callforwarding_hook) (struct sk_buff ** pskb,
+ struct ip_conntrack * ct,
+ enum ip_conntrack_info ctinfo,
+ unsigned char **data, int dataoff,
+ TransportAddress * addr, u_int16_t port,
+ struct ip_conntrack_expect * exp);
int (*nat_q931_hook) (struct sk_buff ** pskb,
struct ip_conntrack * ct,
enum ip_conntrack_info ctinfo,
@@ -681,6 +696,76 @@ static int expect_h245(struct sk_buff **
return ret;
}
+/* Forwarding declaration */
+void ip_conntrack_q931_expect(struct ip_conntrack *new,
+ struct ip_conntrack_expect *this);
+
+/****************************************************************************/
+static int expect_callforwarding(struct sk_buff **pskb,
+ struct ip_conntrack *ct,
+ enum ip_conntrack_info ctinfo,
+ unsigned char **data, int dataoff,
+ TransportAddress * addr)
+{
+ int dir = CTINFO2DIR(ctinfo);
+ int ret = 0;
+ u_int32_t ip;
+ u_int16_t port;
+ struct ip_conntrack_expect *exp = NULL;
+
+ /* Read alternativeAddress */
+ if (!get_h225_addr(*data, addr, &ip, &port) || port == 0)
+ return 0;
+
+ /* If the calling party is on the same side of the forward-to party,
+ * we don't need to track the second call */
+ if (internal_net &&
+ ((ip & internal_net_mask) == internal_net_addr) ==
+ ((ct->tuplehash[!dir].tuple.src.ip & internal_net_mask) ==
+ internal_net_addr)) {
+ DEBUGP("ip_ct_q931: Call Forwarding not tracked\n");
+ return 0;
+ }
+
+ /* Create expect for the second call leg */
+ if ((exp = ip_conntrack_expect_alloc(ct)) == NULL)
+ return -1;
+ exp->tuple.src.ip = ct->tuplehash[!dir].tuple.src.ip;
+ exp->tuple.src.u.tcp.port = 0;
+ exp->tuple.dst.ip = ip;
+ exp->tuple.dst.u.tcp.port = htons(port);
+ exp->tuple.dst.protonum = IPPROTO_TCP;
+ exp->mask.src.ip = 0xFFFFFFFF;
+ exp->mask.src.u.tcp.port = 0;
+ exp->mask.dst.ip = 0xFFFFFFFF;
+ exp->mask.dst.u.tcp.port = 0xFFFF;
+ exp->mask.dst.protonum = 0xFF;
+ exp->flags = 0;
+
+ if (ct->tuplehash[dir].tuple.src.ip !=
+ ct->tuplehash[!dir].tuple.dst.ip && nat_callforwarding_hook) {
+ /* Need NAT */
+ ret = nat_callforwarding_hook(pskb, ct, ctinfo, data, dataoff,
+ addr, port, exp);
+ } else { /* Conntrack only */
+ exp->expectfn = ip_conntrack_q931_expect;
+
+ if (ip_conntrack_expect_related(exp) == 0) {
+ DEBUGP("ip_ct_q931: expect Call Forwarding "
+ "%u.%u.%u.%u:%hu->%u.%u.%u.%u:%hu\n",
+ NIPQUAD(exp->tuple.src.ip),
+ ntohs(exp->tuple.src.u.tcp.port),
+ NIPQUAD(exp->tuple.dst.ip),
+ ntohs(exp->tuple.dst.u.tcp.port));
+ } else
+ ret = -1;
+ }
+
+ ip_conntrack_expect_put(exp);
+
+ return ret;
+}
+
/****************************************************************************/
static int process_setup(struct sk_buff **pskb, struct ip_conntrack *ct,
enum ip_conntrack_info ctinfo,
@@ -876,6 +961,15 @@ static int process_facility(struct sk_bu
DEBUGP("ip_ct_q931: Facility\n");
+ if (facility->reason.choice == eFacilityReason_callForwarded) {
+ if (facility->options & eFacility_UUIE_alternativeAddress)
+ return expect_callforwarding(pskb, ct, ctinfo, data,
+ dataoff,
+ &facility->
+ alternativeAddress);
+ return 0;
+ }
+
if (facility->options & eFacility_UUIE_h245Address) {
ret = expect_h245(pskb, ct, ctinfo, data, dataoff,
&facility->h245Address);
@@ -1666,6 +1760,7 @@ static void fini(void)
static int __init init(void)
{
int ret;
+ char *p;
h323_buffer = kmalloc(65536, GFP_KERNEL);
if (!h323_buffer)
@@ -1676,6 +1771,22 @@ static int __init init(void)
return ret;
}
+ if (internal_net) {
+ if ((p = strchr(internal_net, '/')))
+ *p++ = 0;
+ if (isdigit(internal_net[0])) {
+ internal_net_addr = in_aton(internal_net);
+ if (p && isdigit(p[0]))
+ internal_net_mask = in_aton(p);
+ else
+ internal_net_mask = 0xffffffff;
+ internal_net_addr &= internal_net_mask;
+ }
+ DEBUGP("ip_ct_h323: internal_net = %u.%u.%u.%u/%u.%u.%u.%u\n",
+ NIPQUAD(internal_net_addr),
+ NIPQUAD(internal_net_mask));
+ }
+
DEBUGP("ip_ct_h323: init success\n");
return 0;
}
@@ -1694,6 +1805,7 @@ EXPORT_SYMBOL_GPL(set_ras_addr_hook);
EXPORT_SYMBOL_GPL(nat_rtp_rtcp_hook);
EXPORT_SYMBOL_GPL(nat_t120_hook);
EXPORT_SYMBOL_GPL(nat_h245_hook);
+EXPORT_SYMBOL_GPL(nat_callforwarding_hook);
EXPORT_SYMBOL_GPL(nat_q931_hook);
MODULE_AUTHOR("Jing Min Zhao <zhaojingmin@users.sourceforge.net>");
diff -pruN linux-2.6.17-rc2.a/net/ipv4/netfilter/ip_conntrack_helper_h323_types.c linux-2.6.17-rc2.b/net/ipv4/netfilter/ip_conntrack_helper_h323_types.c
--- linux-2.6.17-rc2.a/net/ipv4/netfilter/ip_conntrack_helper_h323_types.c 2006-04-21 20:37:33.000000000 -0400
+++ linux-2.6.17-rc2.b/net/ipv4/netfilter/ip_conntrack_helper_h323_types.c 2006-04-21 20:41:11.000000000 -0400
@@ -1,4 +1,4 @@
-/* Generated by Jing Min Zhao's ASN.1 parser, Mar 15 2006
+/* Generated by Jing Min Zhao's ASN.1 parser, Apr 20 2006
*
* Copyright (c) 2006 Jing Min Zhao <zhaojingmin@users.sourceforge.net>
*
@@ -1069,8 +1069,8 @@ static field_t _Facility_UUIE_fastStart[
static field_t _Facility_UUIE[] = { /* SEQUENCE */
{FNAME("protocolIdentifier") OID, BYTE, 0, 0, SKIP, 0, NULL},
- {FNAME("alternativeAddress") CHOICE, 3, 7, 7, SKIP | EXT | OPT, 0,
- _TransportAddress},
+ {FNAME("alternativeAddress") CHOICE, 3, 7, 7, DECODE | EXT | OPT,
+ offsetof(Facility_UUIE, alternativeAddress), _TransportAddress},
{FNAME("alternativeAliasAddress") SEQOF, SEMI, 0, 0, SKIP | OPT, 0,
_Facility_UUIE_alternativeAliasAddress},
{FNAME("conferenceID") OCTSTR, FIXD, 16, 0, SKIP | OPT, 0, NULL},
diff -pruN linux-2.6.17-rc2.a/net/ipv4/netfilter/ip_nat_helper_h323.c linux-2.6.17-rc2.b/net/ipv4/netfilter/ip_nat_helper_h323.c
--- linux-2.6.17-rc2.a/net/ipv4/netfilter/ip_nat_helper_h323.c 2006-04-21 20:37:33.000000000 -0400
+++ linux-2.6.17-rc2.b/net/ipv4/netfilter/ip_nat_helper_h323.c 2006-04-21 20:41:11.000000000 -0400
@@ -487,6 +487,80 @@ static int nat_q931(struct sk_buff **psk
}
/****************************************************************************/
+static void ip_nat_callforwarding_expect(struct ip_conntrack *new,
+ struct ip_conntrack_expect *this)
+{
+ struct ip_nat_range range;
+
+ /* This must be a fresh one. */
+ BUG_ON(new->status & IPS_NAT_DONE_MASK);
+
+ /* Change src to where master sends to */
+ range.flags = IP_NAT_RANGE_MAP_IPS;
+ range.min_ip = range.max_ip = new->tuplehash[!this->dir].tuple.src.ip;
+
+ /* hook doesn't matter, but it has to do source manip */
+ ip_nat_setup_info(new, &range, NF_IP_POST_ROUTING);
+
+ /* For DST manip, map port here to where it's expected. */
+ range.flags = (IP_NAT_RANGE_MAP_IPS | IP_NAT_RANGE_PROTO_SPECIFIED);
+ range.min = range.max = this->saved_proto;
+ range.min_ip = range.max_ip = this->saved_ip;
+
+ /* hook doesn't matter, but it has to do destination manip */
+ ip_nat_setup_info(new, &range, NF_IP_PRE_ROUTING);
+
+ ip_conntrack_q931_expect(new, this);
+}
+
+/****************************************************************************/
+static int nat_callforwarding(struct sk_buff **pskb, struct ip_conntrack *ct,
+ enum ip_conntrack_info ctinfo,
+ unsigned char **data, int dataoff,
+ TransportAddress * addr, u_int16_t port,
+ struct ip_conntrack_expect *exp)
+{
+ int dir = CTINFO2DIR(ctinfo);
+ u_int16_t nated_port;
+
+ /* Set expectations for NAT */
+ exp->saved_ip = exp->tuple.dst.ip;
+ exp->tuple.dst.ip = ct->tuplehash[!dir].tuple.dst.ip;
+ exp->saved_proto.tcp.port = exp->tuple.dst.u.tcp.port;
+ exp->expectfn = ip_nat_callforwarding_expect;
+ exp->dir = !dir;
+
+ /* Try to get same port: if not, try to change it. */
+ for (nated_port = port; nated_port != 0; nated_port++) {
+ exp->tuple.dst.u.tcp.port = htons(nated_port);
+ if (ip_conntrack_expect_related(exp) == 0)
+ break;
+ }
+
+ if (nated_port == 0) { /* No port available */
+ if (net_ratelimit())
+ printk("ip_nat_q931: out of TCP ports\n");
+ return 0;
+ }
+
+ /* Modify signal */
+ if (!set_h225_addr(pskb, data, dataoff, addr,
+ ct->tuplehash[!dir].tuple.dst.ip,
+ nated_port) == 0) {
+ ip_conntrack_unexpect_related(exp);
+ return -1;
+ }
+
+ /* Success */
+ DEBUGP("ip_nat_q931: expect Call Forwarding "
+ "%u.%u.%u.%u:%hu->%u.%u.%u.%u:%hu\n",
+ NIPQUAD(exp->tuple.src.ip), ntohs(exp->tuple.src.u.tcp.port),
+ NIPQUAD(exp->tuple.dst.ip), ntohs(exp->tuple.dst.u.tcp.port));
+
+ return 0;
+}
+
+/****************************************************************************/
static int __init init(void)
{
BUG_ON(set_h245_addr_hook != NULL);
@@ -496,6 +570,7 @@ static int __init init(void)
BUG_ON(nat_rtp_rtcp_hook != NULL);
BUG_ON(nat_t120_hook != NULL);
BUG_ON(nat_h245_hook != NULL);
+ BUG_ON(nat_callforwarding_hook != NULL);
BUG_ON(nat_q931_hook != NULL);
set_h245_addr_hook = set_h245_addr;
@@ -505,6 +580,7 @@ static int __init init(void)
nat_rtp_rtcp_hook = nat_rtp_rtcp;
nat_t120_hook = nat_t120;
nat_h245_hook = nat_h245;
+ nat_callforwarding_hook = nat_callforwarding;
nat_q931_hook = nat_q931;
DEBUGP("ip_nat_h323: init success\n");
@@ -521,6 +597,7 @@ static void __exit fini(void)
nat_rtp_rtcp_hook = NULL;
nat_t120_hook = NULL;
nat_h245_hook = NULL;
+ nat_callforwarding_hook = NULL;
nat_q931_hook = NULL;
synchronize_net();
}
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [H.323 Helper 1/3]: Add support for Call Forwarding
2006-04-24 3:40 [H.323 Helper 1/3]: Add support for Call Forwarding Jing Min Zhao
@ 2006-04-26 13:48 ` Patrick McHardy
2006-04-26 14:33 ` Jing Min Zhao
0 siblings, 1 reply; 14+ messages in thread
From: Patrick McHardy @ 2006-04-26 13:48 UTC (permalink / raw)
To: Jing Min Zhao; +Cc: netfilter-devel
Jing Min Zhao wrote:
> This patch is for 2.6.17-rc2. Please visit
> http://nath323.sourceforge.net/#_Toc133598071 for details.
>
> Signed-off-by: Jing Min Zhao <zhaojingmin@users.sourceforge.net>
Please attach patches inline so I can view and quote them in my mail
client and include the patch description with the patch.
As for the patch:
I definitely don't like the internal_net module option. I know its not
strictly required, more an optimization, but still limiting this to only
one network is not a good idea. We may be able to use the routing
information as indication whether we need an expectation or not .. but
I need think about it some more.
--- a/include/linux/netfilter_ipv4/ip_conntrack.h
+++ b/include/linux/netfilter_ipv4/ip_conntrack.h
@@ -154,6 +154,7 @@ struct ip_conntrack_expect
unsigned int flags;
#ifdef CONFIG_IP_NF_NAT_NEEDED
+ u_int32_t saved_ip;
/* This is the original per-proto part, used to map the
* expected connection the way the recipient expects. */
union ip_conntrack_manip_proto saved_proto;
Please explain why this is needed.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [H.323 Helper 1/3]: Add support for Call Forwarding
2006-04-26 13:48 ` Patrick McHardy
@ 2006-04-26 14:33 ` Jing Min Zhao
2006-04-26 16:49 ` Patrick McHardy
0 siblings, 1 reply; 14+ messages in thread
From: Jing Min Zhao @ 2006-04-26 14:33 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netfilter-devel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="gb18030", Size: 2523 bytes --]
----- Original Message -----
From: "Patrick McHardy" <kaber@trash.net>
To: "Jing Min Zhao" <zhaojingmin@hotmail.com>
Cc: <netfilter-devel@lists.netfilter.org>
Sent: Wednesday, April 26, 2006 9:48 AM
Subject: Re: [H.323 Helper 1/3]: Add support for Call Forwarding
> Jing Min Zhao wrote:
>> This patch is for 2.6.17-rc2. Please visit
>> http://nath323.sourceforge.net/#_Toc133598071 for details.
>>
>> Signed-off-by: Jing Min Zhao <zhaojingmin@users.sourceforge.net>
>
> Please attach patches inline so I can view and quote them in my mail
> client and include the patch description with the patch.
>
I'm sorry. Actually, I'm always frustrated by my Outlook Express
and my hotmail account :(. I'm worrying about the email format
won't be compatible with you guys' clients. I'll try next time with
inline patches, please tell me if it doesn't work.
> As for the patch:
>
> I definitely don't like the internal_net module option. I know its not
> strictly required, more an optimization, but still limiting this to only
> one network is not a good idea. We may be able to use the routing
> information as indication whether we need an expectation or not .. but
> I need think about it some more.
>
>
I also want such a solution deadly, but I can't figure out a way.
Actually, the only question is how can a firewall tell that any two
endpoints can talk with each other directly without passing though it.
Any suggestion for this will be greatly appreciated.
> --- a/include/linux/netfilter_ipv4/ip_conntrack.h
> +++ b/include/linux/netfilter_ipv4/ip_conntrack.h
> @@ -154,6 +154,7 @@ struct ip_conntrack_expect
> unsigned int flags;
>
> #ifdef CONFIG_IP_NF_NAT_NEEDED
> + u_int32_t saved_ip;
> /* This is the original per-proto part, used to map the
> * expected connection the way the recipient expects. */
> union ip_conntrack_manip_proto saved_proto;
>
> Please explain why this is needed.
>
>
If an external endpoint A calls an internal endpoint B, and B forwards
the call to an internal endpoint C, then the second call will come from
A, pass through firewall, and go to C. The current architecture assumes
any expected connections come back to the same internal endpoint, so
only the port (saved_proto) is saved. But in this case, it is not
enough - the expected connection will go to the third endpoint. So we
need to save not only C's port but also C's IP.
Best rgds,
Jing Min Zhao
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [H.323 Helper 1/3]: Add support for Call Forwarding
2006-04-26 14:33 ` Jing Min Zhao
@ 2006-04-26 16:49 ` Patrick McHardy
2006-04-26 18:06 ` Jing Min Zhao
0 siblings, 1 reply; 14+ messages in thread
From: Patrick McHardy @ 2006-04-26 16:49 UTC (permalink / raw)
To: Jing Min Zhao; +Cc: netfilter-devel
Jing Min Zhao wrote:
> ----- Original Message -----
> From: "Patrick McHardy" <kaber@trash.net>
> To: "Jing Min Zhao" <zhaojingmin@hotmail.com>
> Cc: <netfilter-devel@lists.netfilter.org>
> Sent: Wednesday, April 26, 2006 9:48 AM
> Subject: Re: [H.323 Helper 1/3]: Add support for Call Forwarding
>
>
>
>>Jing Min Zhao wrote:
>>
>>>This patch is for 2.6.17-rc2. Please visit
>>>http://nath323.sourceforge.net/#_Toc133598071 for details.
>>>
>>>Signed-off-by: Jing Min Zhao <zhaojingmin@users.sourceforge.net>
>>
>>Please attach patches inline so I can view and quote them in my mail
>>client and include the patch description with the patch.
>>
>
> I'm sorry. Actually, I'm always frustrated by my Outlook Express
> and my hotmail account :(.
I can relate :) I think you should be able to use imap on
people.netfilter.org.
>>I definitely don't like the internal_net module option. I know its not
>>strictly required, more an optimization, but still limiting this to only
>>one network is not a good idea. We may be able to use the routing
>>information as indication whether we need an expectation or not .. but
>>I need think about it some more.
>>
>>
>
> I also want such a solution deadly, but I can't figure out a way.
> Actually, the only question is how can a firewall tell that any two
> endpoints can talk with each other directly without passing though it.
> Any suggestion for this will be greatly appreciated.
There is no general way to do this, but we I think we can take a good
guess for the common case of no weird NATing etc based on the nexthop
information we get from fib_lookup(). I think an assumption that is
true for most cases is that if the nexthop information is identical,
the two endpoints can reach each other without our help. It needs to
be optional of course. What do you think about this?
>>--- a/include/linux/netfilter_ipv4/ip_conntrack.h
>>+++ b/include/linux/netfilter_ipv4/ip_conntrack.h
>>@@ -154,6 +154,7 @@ struct ip_conntrack_expect
>> unsigned int flags;
>>
>>#ifdef CONFIG_IP_NF_NAT_NEEDED
>>+ u_int32_t saved_ip;
>> /* This is the original per-proto part, used to map the
>> * expected connection the way the recipient expects. */
>> union ip_conntrack_manip_proto saved_proto;
>>
>>Please explain why this is needed.
>>
>>
>
> If an external endpoint A calls an internal endpoint B, and B forwards
> the call to an internal endpoint C, then the second call will come from
> A, pass through firewall, and go to C. The current architecture assumes
> any expected connections come back to the same internal endpoint, so
> only the port (saved_proto) is saved. But in this case, it is not
> enough - the expected connection will go to the third endpoint. So we
> need to save not only C's port but also C's IP.
OK, this seems to be unavoidable. But please just replace
ip_conntrack_manip_proto by ip_conntrack_manip.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [H.323 Helper 1/3]: Add support for Call Forwarding
2006-04-26 16:49 ` Patrick McHardy
@ 2006-04-26 18:06 ` Jing Min Zhao
2006-04-26 20:20 ` Patrick McHardy
` (2 more replies)
0 siblings, 3 replies; 14+ messages in thread
From: Jing Min Zhao @ 2006-04-26 18:06 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netfilter-devel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="gb18030", Size: 3768 bytes --]
----- Original Message -----
From: "Patrick McHardy" <kaber@trash.net>
To: "Jing Min Zhao" <zhaojingmin@hotmail.com>
Cc: <netfilter-devel@lists.netfilter.org>
Sent: Wednesday, April 26, 2006 12:49 PM
Subject: Re: [H.323 Helper 1/3]: Add support for Call Forwarding
> Jing Min Zhao wrote:
>> ----- Original Message -----
>> From: "Patrick McHardy" <kaber@trash.net>
>> To: "Jing Min Zhao" <zhaojingmin@hotmail.com>
>> Cc: <netfilter-devel@lists.netfilter.org>
>> Sent: Wednesday, April 26, 2006 9:48 AM
>> Subject: Re: [H.323 Helper 1/3]: Add support for Call Forwarding
>>
>>
>>
>>>Jing Min Zhao wrote:
>>>
>>>>This patch is for 2.6.17-rc2. Please visit
>>>>http://nath323.sourceforge.net/#_Toc133598071 for details.
>>>>
>>>>Signed-off-by: Jing Min Zhao <zhaojingmin@users.sourceforge.net>
>>>
>>>Please attach patches inline so I can view and quote them in my mail
>>>client and include the patch description with the patch.
>>>
>>
>> I'm sorry. Actually, I'm always frustrated by my Outlook Express
>> and my hotmail account :(.
>
> I can relate :) I think you should be able to use imap on
> people.netfilter.org.
>
>
Really? That'll be great! I'll try. Thank you.
>>>I definitely don't like the internal_net module option. I know its not
>>>strictly required, more an optimization, but still limiting this to only
>>>one network is not a good idea. We may be able to use the routing
>>>information as indication whether we need an expectation or not .. but
>>>I need think about it some more.
>>>
>>>
>>
>> I also want such a solution deadly, but I can't figure out a way.
>> Actually, the only question is how can a firewall tell that any two
>> endpoints can talk with each other directly without passing though it.
>> Any suggestion for this will be greatly appreciated.
>
> There is no general way to do this, but we I think we can take a good
> guess for the common case of no weird NATing etc based on the nexthop
> information we get from fib_lookup(). I think an assumption that is
> true for most cases is that if the nexthop information is identical,
> the two endpoints can reach each other without our help. It needs to
> be optional of course. What do you think about this?
>
>
This is a good idea, and it's probably the best that a firewall can do.
I'll think about it.
>>>--- a/include/linux/netfilter_ipv4/ip_conntrack.h
>>>+++ b/include/linux/netfilter_ipv4/ip_conntrack.h
>>>@@ -154,6 +154,7 @@ struct ip_conntrack_expect
>>> unsigned int flags;
>>>
>>>#ifdef CONFIG_IP_NF_NAT_NEEDED
>>>+ u_int32_t saved_ip;
>>> /* This is the original per-proto part, used to map the
>>> * expected connection the way the recipient expects. */
>>> union ip_conntrack_manip_proto saved_proto;
>>>
>>>Please explain why this is needed.
>>>
>>>
>>
>> If an external endpoint A calls an internal endpoint B, and B forwards
>> the call to an internal endpoint C, then the second call will come from
>> A, pass through firewall, and go to C. The current architecture assumes
>> any expected connections come back to the same internal endpoint, so
>> only the port (saved_proto) is saved. But in this case, it is not
>> enough - the expected connection will go to the third endpoint. So we
>> need to save not only C's port but also C's IP.
>
> OK, this seems to be unavoidable. But please just replace
> ip_conntrack_manip_proto by ip_conntrack_manip.
>
>
Do you mean to delete saved_ip and replace
"union ip_conntrack_manip_proto saved_proto" with
"struct ip_conntrack_manip saved_xxx"? This will break other code,
for example, ip_nat_follow_master(). Or I misunderstood.
rgds,
Jing Min Zhao
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [H.323 Helper 1/3]: Add support for Call Forwarding
2006-04-26 18:06 ` Jing Min Zhao
@ 2006-04-26 20:20 ` Patrick McHardy
2006-04-26 20:21 ` Patrick McHardy
2006-05-01 17:51 ` imap.netfilter.org (was Re: [H.323 Helper 1/3]: Add support for Call Forwarding) Harald Welte
2 siblings, 0 replies; 14+ messages in thread
From: Patrick McHardy @ 2006-04-26 20:20 UTC (permalink / raw)
To: Jing Min Zhao; +Cc: netfilter-devel
Jing Min Zhao wrote:
>>>>--- a/include/linux/netfilter_ipv4/ip_conntrack.h
>>>>+++ b/include/linux/netfilter_ipv4/ip_conntrack.h
>>>>@@ -154,6 +154,7 @@ struct ip_conntrack_expect
>>>> unsigned int flags;
>>>>
>>>>#ifdef CONFIG_IP_NF_NAT_NEEDED
>>>>+ u_int32_t saved_ip;
>>>> /* This is the original per-proto part, used to map the
>>>> * expected connection the way the recipient expects. */
>>>> union ip_conntrack_manip_proto saved_proto;
>>>>
>>>>Please explain why this is needed.
>>>>
>>>>
>>>
>>>If an external endpoint A calls an internal endpoint B, and B forwards
>>>the call to an internal endpoint C, then the second call will come from
>>>A, pass through firewall, and go to C. The current architecture assumes
>>>any expected connections come back to the same internal endpoint, so
>>>only the port (saved_proto) is saved. But in this case, it is not
>>>enough - the expected connection will go to the third endpoint. So we
>>>need to save not only C's port but also C's IP.
>>
>>OK, this seems to be unavoidable. But please just replace
>>ip_conntrack_manip_proto by ip_conntrack_manip.
>>
>>
>
>
> Do you mean to delete saved_ip and replace
> "union ip_conntrack_manip_proto saved_proto" with
> "struct ip_conntrack_manip saved_xxx"? This will break other code,
> for example, ip_nat_follow_master(). Or I misunderstood.
Yes, these places need to be changes as well. But ip_conntrack_manip
is semantically correct, you use the saved_ip for the manip of the
new connection, so we can instead just save an entire manip.
But its still a good point, please make this change in a seperate patch
from the call forwarding patch.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [H.323 Helper 1/3]: Add support for Call Forwarding
2006-04-26 18:06 ` Jing Min Zhao
2006-04-26 20:20 ` Patrick McHardy
@ 2006-04-26 20:21 ` Patrick McHardy
2006-04-26 21:15 ` Jing Min Zhao
2006-05-01 17:51 ` imap.netfilter.org (was Re: [H.323 Helper 1/3]: Add support for Call Forwarding) Harald Welte
2 siblings, 1 reply; 14+ messages in thread
From: Patrick McHardy @ 2006-04-26 20:21 UTC (permalink / raw)
To: Jing Min Zhao; +Cc: netfilter-devel
Jing Min Zhao wrote:
>>>>I definitely don't like the internal_net module option. I know its not
>>>>strictly required, more an optimization, but still limiting this to only
>>>>one network is not a good idea. We may be able to use the routing
>>>>information as indication whether we need an expectation or not .. but
>>>>I need think about it some more.
>>>>
>>>>
>>>
>>>I also want such a solution deadly, but I can't figure out a way.
>>>Actually, the only question is how can a firewall tell that any two
>>>endpoints can talk with each other directly without passing though it.
>>>Any suggestion for this will be greatly appreciated.
>>
>>There is no general way to do this, but we I think we can take a good
>>guess for the common case of no weird NATing etc based on the nexthop
>>information we get from fib_lookup(). I think an assumption that is
>>true for most cases is that if the nexthop information is identical,
>>the two endpoints can reach each other without our help. It needs to
>>be optional of course. What do you think about this?
>>
>>
>
> This is a good idea, and it's probably the best that a firewall can do.
> I'll think about it.
BTW, I can give you some help implementing this if you need.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [H.323 Helper 1/3]: Add support for Call Forwarding
2006-04-26 20:21 ` Patrick McHardy
@ 2006-04-26 21:15 ` Jing Min Zhao
2006-04-27 19:57 ` Patrick McHardy
0 siblings, 1 reply; 14+ messages in thread
From: Jing Min Zhao @ 2006-04-26 21:15 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netfilter-devel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="gb18030", Size: 1710 bytes --]
----- Original Message -----
From: "Patrick McHardy" <kaber@trash.net>
To: "Jing Min Zhao" <zhaojingmin@hotmail.com>
Cc: <netfilter-devel@lists.netfilter.org>
Sent: Wednesday, April 26, 2006 4:21 PM
Subject: Re: [H.323 Helper 1/3]: Add support for Call Forwarding
> Jing Min Zhao wrote:
>>>>>I definitely don't like the internal_net module option. I know its not
>>>>>strictly required, more an optimization, but still limiting this to only
>>>>>one network is not a good idea. We may be able to use the routing
>>>>>information as indication whether we need an expectation or not .. but
>>>>>I need think about it some more.
>>>>>
>>>>>
>>>>
>>>>I also want such a solution deadly, but I can't figure out a way.
>>>>Actually, the only question is how can a firewall tell that any two
>>>>endpoints can talk with each other directly without passing though it.
>>>>Any suggestion for this will be greatly appreciated.
>>>
>>>There is no general way to do this, but we I think we can take a good
>>>guess for the common case of no weird NATing etc based on the nexthop
>>>information we get from fib_lookup(). I think an assumption that is
>>>true for most cases is that if the nexthop information is identical,
>>>the two endpoints can reach each other without our help. It needs to
>>>be optional of course. What do you think about this?
>>>
>>>
>>
>> This is a good idea, and it's probably the best that a firewall can do.
>> I'll think about it.
>
> BTW, I can give you some help implementing this if you need.
>
>
>
PLEASE! Not only because I'm not very familiar with that part of kernel,
but also I'm too busy these two weeks :(
Thank you very much!
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [H.323 Helper 1/3]: Add support for Call Forwarding
2006-04-26 21:15 ` Jing Min Zhao
@ 2006-04-27 19:57 ` Patrick McHardy
2006-04-28 15:07 ` Jing Min Zhao
0 siblings, 1 reply; 14+ messages in thread
From: Patrick McHardy @ 2006-04-27 19:57 UTC (permalink / raw)
To: Jing Min Zhao; +Cc: netfilter-devel
[-- Attachment #1: Type: text/plain, Size: 1001 bytes --]
Jing Min Zhao wrote:
>>>>>I also want such a solution deadly, but I can't figure out a way.
>>>>>Actually, the only question is how can a firewall tell that any two
>>>>>endpoints can talk with each other directly without passing though it.
>>>>>Any suggestion for this will be greatly appreciated.
>>>>
>>>>There is no general way to do this, but we I think we can take a good
>>>>guess for the common case of no weird NATing etc based on the nexthop
>>>>information we get from fib_lookup(). I think an assumption that is
>>>>true for most cases is that if the nexthop information is identical,
>>>>the two endpoints can reach each other without our help. It needs to
>>>>be optional of course. What do you think about this?
>>>>
>>>>
>>>
>>>This is a good idea, and it's probably the best that a firewall can do.
>>>I'll think about it.
Here is a patch which does this. I don't have a proper setup, please
test if it works and if it does just integrate it with your patch and
resubmit. Thanks.
[-- Attachment #2: x --]
[-- Type: text/plain, Size: 3648 bytes --]
[NETFILTER]: H.323 helper: optionally use nexthop information to guess whether two hosts can reach each other directly
Signed-off-by: Patrick McHardy <kaber@trash.net>
---
commit fa397eabacd7c7aeab07227bd6ab40b70c59d2c9
tree 23bd56b41918ce09725adf1a4c5320ca87b71961
parent c6e95adefe7a13a2cf4933e131c86a36410340bf
author Patrick McHardy <kaber@trash.net> Thu, 27 Apr 2006 21:54:55 +0200
committer Patrick McHardy <kaber@trash.net> Thu, 27 Apr 2006 21:54:55 +0200
net/ipv4/netfilter/ip_conntrack_helper_h323.c | 61 ++++++++++++-------------
1 files changed, 29 insertions(+), 32 deletions(-)
diff --git a/net/ipv4/netfilter/ip_conntrack_helper_h323.c b/net/ipv4/netfilter/ip_conntrack_helper_h323.c
index 5dec119..8aeec26 100644
--- a/net/ipv4/netfilter/ip_conntrack_helper_h323.c
+++ b/net/ipv4/netfilter/ip_conntrack_helper_h323.c
@@ -24,6 +24,7 @@
#include <linux/moduleparam.h>
#include <linux/ctype.h>
#include <linux/inet.h>
+#include <net/ip_fib.h>
#if 0
#define DEBUGP printk
@@ -40,12 +41,9 @@ static int gkrouted_only = 1;
module_param(gkrouted_only, int, 0600);
MODULE_PARM_DESC(gkrouted_only, "only accept calls from gatekeeper");
-static char *internal_net = NULL;
-static u_int32_t internal_net_addr = 0;
-static u_int32_t internal_net_mask = 0;
-module_param(internal_net, charp, 0600);
-MODULE_PARM_DESC(internal_net, "specify your internal network using format "
- "address/mask. this is used by call forwarding support");
+static int forwarding_mode;
+module_param(forwarding_mode, int, 0600);
+MODULE_PARM_DESC(forwarding_mode, "call forwarding mode");
/* Hooks for NAT */
int (*set_h245_addr_hook) (struct sk_buff ** pskb,
@@ -717,14 +715,31 @@ static int expect_callforwarding(struct
if (!get_h225_addr(*data, addr, &ip, &port) || port == 0)
return 0;
- /* If the calling party is on the same side of the forward-to party,
- * we don't need to track the second call */
- if (internal_net &&
- ((ip & internal_net_mask) == internal_net_addr) ==
- ((ct->tuplehash[!dir].tuple.src.ip & internal_net_mask) ==
- internal_net_addr)) {
- DEBUGP("ip_ct_q931: Call Forwarding not tracked\n");
- return 0;
+ if (forwarding_mode) {
+ struct fib_result res1, res2;
+ struct flowi fl;
+ int eq = 0;
+
+ memset(&fl, 0, sizeof(fl));
+
+ fl.fl4_dst = ip;
+ if (fib_lookup(&fl, &res1) == 0) {
+ fl.fl4_dst = ct->tuplehash[!dir].tuple.src.ip;
+ if (fib_lookup(&fl, &res2) == 0) {
+ if (FIB_RES_GW(res1) == FIB_RES_GW(res2) &&
+ FIB_RES_OIF(res1) == FIB_RES_OIF(res2))
+ eq = 1;
+ fib_res_put(&res2);
+ }
+ fib_res_put(&res1);
+ }
+
+ /* If the calling party is on the same side of the forward-to
+ * party, we don't need to track the second call */
+ if (eq) {
+ DEBUGP("ip_ct_q931: Call Forwarding not tracked\n");
+ return 0;
+ }
}
/* Create expect for the second call leg */
@@ -1760,7 +1775,6 @@ static void fini(void)
static int __init init(void)
{
int ret;
- char *p;
h323_buffer = kmalloc(65536, GFP_KERNEL);
if (!h323_buffer)
@@ -1770,23 +1784,6 @@ static int __init init(void)
fini();
return ret;
}
-
- if (internal_net) {
- if ((p = strchr(internal_net, '/')))
- *p++ = 0;
- if (isdigit(internal_net[0])) {
- internal_net_addr = in_aton(internal_net);
- if (p && isdigit(p[0]))
- internal_net_mask = in_aton(p);
- else
- internal_net_mask = 0xffffffff;
- internal_net_addr &= internal_net_mask;
- }
- DEBUGP("ip_ct_h323: internal_net = %u.%u.%u.%u/%u.%u.%u.%u\n",
- NIPQUAD(internal_net_addr),
- NIPQUAD(internal_net_mask));
- }
-
DEBUGP("ip_ct_h323: init success\n");
return 0;
}
^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [H.323 Helper 1/3]: Add support for Call Forwarding
2006-04-27 19:57 ` Patrick McHardy
@ 2006-04-28 15:07 ` Jing Min Zhao
2006-04-28 15:13 ` Patrick McHardy
0 siblings, 1 reply; 14+ messages in thread
From: Jing Min Zhao @ 2006-04-28 15:07 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netfilter-devel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="gb18030", Size: 6040 bytes --]
Hi, Patrick,
I applied your patch, it compiled ok, but there are some
linking warnings:
WARNING: "free_fib_info" [net/ipv4/netfilter/ip_conntrack_h323.ko] undefined!
WARNING: "fib_lookup" [net/ipv4/netfilter/ip_conntrack_h323.ko] undefined!
WARNING: "fib_rule_put" [net/ipv4/netfilter/ip_conntrack_h323.ko] undefined!
When I disabled IP: policy routing (CONFIG_IP_MULTIPLE_TABLES), I got
different warnings:
WARNING: "ip_fib_main_table" [net/ipv4/netfilter/ip_conntrack_h323.ko] undefined!
WARNING: "ip_fib_local_table" [net/ipv4/netfilter/ip_conntrack_h323.ko] undefined!
WARNING: "free_fib_info" [net/ipv4/netfilter/ip_conntrack_h323.ko] undefined!
Can you help me?
Thanks a lot!
Jing Min Zhao
----- Original Message -----
From: "Patrick McHardy" <kaber@trash.net>
To: "Jing Min Zhao" <zhaojingmin@hotmail.com>
Cc: <netfilter-devel@lists.netfilter.org>
Sent: Thursday, April 27, 2006 3:57 PM
Subject: Re: [H.323 Helper 1/3]: Add support for Call Forwarding
> Jing Min Zhao wrote:
>>>>>>I also want such a solution deadly, but I can't figure out a way.
>>>>>>Actually, the only question is how can a firewall tell that any two
>>>>>>endpoints can talk with each other directly without passing though it.
>>>>>>Any suggestion for this will be greatly appreciated.
>>>>>
>>>>>There is no general way to do this, but we I think we can take a good
>>>>>guess for the common case of no weird NATing etc based on the nexthop
>>>>>information we get from fib_lookup(). I think an assumption that is
>>>>>true for most cases is that if the nexthop information is identical,
>>>>>the two endpoints can reach each other without our help. It needs to
>>>>>be optional of course. What do you think about this?
>>>>>
>>>>>
>>>>
>>>>This is a good idea, and it's probably the best that a firewall can do.
>>>>I'll think about it.
>
> Here is a patch which does this. I don't have a proper setup, please
> test if it works and if it does just integrate it with your patch and
> resubmit. Thanks.
>
>
--------------------------------------------------------------------------------
> [NETFILTER]: H.323 helper: optionally use nexthop information to guess whether two hosts can reach each other directly
>
> Signed-off-by: Patrick McHardy <kaber@trash.net>
>
> ---
> commit fa397eabacd7c7aeab07227bd6ab40b70c59d2c9
> tree 23bd56b41918ce09725adf1a4c5320ca87b71961
> parent c6e95adefe7a13a2cf4933e131c86a36410340bf
> author Patrick McHardy <kaber@trash.net> Thu, 27 Apr 2006 21:54:55 +0200
> committer Patrick McHardy <kaber@trash.net> Thu, 27 Apr 2006 21:54:55 +0200
>
> net/ipv4/netfilter/ip_conntrack_helper_h323.c | 61 ++++++++++++-------------
> 1 files changed, 29 insertions(+), 32 deletions(-)
>
> diff --git a/net/ipv4/netfilter/ip_conntrack_helper_h323.c b/net/ipv4/netfilter/ip_conntrack_helper_h323.c
> index 5dec119..8aeec26 100644
> --- a/net/ipv4/netfilter/ip_conntrack_helper_h323.c
> +++ b/net/ipv4/netfilter/ip_conntrack_helper_h323.c
> @@ -24,6 +24,7 @@
> #include <linux/moduleparam.h>
> #include <linux/ctype.h>
> #include <linux/inet.h>
> +#include <net/ip_fib.h>
>
> #if 0
> #define DEBUGP printk
> @@ -40,12 +41,9 @@ static int gkrouted_only = 1;
> module_param(gkrouted_only, int, 0600);
> MODULE_PARM_DESC(gkrouted_only, "only accept calls from gatekeeper");
>
> -static char *internal_net = NULL;
> -static u_int32_t internal_net_addr = 0;
> -static u_int32_t internal_net_mask = 0;
> -module_param(internal_net, charp, 0600);
> -MODULE_PARM_DESC(internal_net, "specify your internal network using format "
> - "address/mask. this is used by call forwarding support");
> +static int forwarding_mode;
> +module_param(forwarding_mode, int, 0600);
> +MODULE_PARM_DESC(forwarding_mode, "call forwarding mode");
>
> /* Hooks for NAT */
> int (*set_h245_addr_hook) (struct sk_buff ** pskb,
> @@ -717,14 +715,31 @@ static int expect_callforwarding(struct
> if (!get_h225_addr(*data, addr, &ip, &port) || port == 0)
> return 0;
>
> - /* If the calling party is on the same side of the forward-to party,
> - * we don't need to track the second call */
> - if (internal_net &&
> - ((ip & internal_net_mask) == internal_net_addr) ==
> - ((ct->tuplehash[!dir].tuple.src.ip & internal_net_mask) ==
> - internal_net_addr)) {
> - DEBUGP("ip_ct_q931: Call Forwarding not tracked\n");
> - return 0;
> + if (forwarding_mode) {
> + struct fib_result res1, res2;
> + struct flowi fl;
> + int eq = 0;
> +
> + memset(&fl, 0, sizeof(fl));
> +
> + fl.fl4_dst = ip;
> + if (fib_lookup(&fl, &res1) == 0) {
> + fl.fl4_dst = ct->tuplehash[!dir].tuple.src.ip;
> + if (fib_lookup(&fl, &res2) == 0) {
> + if (FIB_RES_GW(res1) == FIB_RES_GW(res2) &&
> + FIB_RES_OIF(res1) == FIB_RES_OIF(res2))
> + eq = 1;
> + fib_res_put(&res2);
> + }
> + fib_res_put(&res1);
> + }
> +
> + /* If the calling party is on the same side of the forward-to
> + * party, we don't need to track the second call */
> + if (eq) {
> + DEBUGP("ip_ct_q931: Call Forwarding not tracked\n");
> + return 0;
> + }
> }
>
> /* Create expect for the second call leg */
> @@ -1760,7 +1775,6 @@ static void fini(void)
> static int __init init(void)
> {
> int ret;
> - char *p;
>
> h323_buffer = kmalloc(65536, GFP_KERNEL);
> if (!h323_buffer)
> @@ -1770,23 +1784,6 @@ static int __init init(void)
> fini();
> return ret;
> }
> -
> - if (internal_net) {
> - if ((p = strchr(internal_net, '/')))
> - *p++ = 0;
> - if (isdigit(internal_net[0])) {
> - internal_net_addr = in_aton(internal_net);
> - if (p && isdigit(p[0]))
> - internal_net_mask = in_aton(p);
> - else
> - internal_net_mask = 0xffffffff;
> - internal_net_addr &= internal_net_mask;
> - }
> - DEBUGP("ip_ct_h323: internal_net = %u.%u.%u.%u/%u.%u.%u.%u\n",
> - NIPQUAD(internal_net_addr),
> - NIPQUAD(internal_net_mask));
> - }
> -
> DEBUGP("ip_ct_h323: init success\n");
> return 0;
> }
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [H.323 Helper 1/3]: Add support for Call Forwarding
2006-04-28 15:07 ` Jing Min Zhao
@ 2006-04-28 15:13 ` Patrick McHardy
2006-05-20 3:23 ` Patrick McHardy
0 siblings, 1 reply; 14+ messages in thread
From: Patrick McHardy @ 2006-04-28 15:13 UTC (permalink / raw)
To: Jing Min Zhao; +Cc: netfilter-devel
Jing Min Zhao wrote:
> Hi, Patrick,
>
> I applied your patch, it compiled ok, but there are some
> linking warnings:
>
> WARNING: "free_fib_info" [net/ipv4/netfilter/ip_conntrack_h323.ko] undefined!
> WARNING: "fib_lookup" [net/ipv4/netfilter/ip_conntrack_h323.ko] undefined!
> WARNING: "fib_rule_put" [net/ipv4/netfilter/ip_conntrack_h323.ko] undefined!
>
> When I disabled IP: policy routing (CONFIG_IP_MULTIPLE_TABLES), I got
> different warnings:
>
> WARNING: "ip_fib_main_table" [net/ipv4/netfilter/ip_conntrack_h323.ko] undefined!
> WARNING: "ip_fib_local_table" [net/ipv4/netfilter/ip_conntrack_h323.ko] undefined!
> WARNING: "free_fib_info" [net/ipv4/netfilter/ip_conntrack_h323.ko] undefined!
Oops .. these aren't exported. Just drop the patch, I'll send you a
better one this weekend.
^ permalink raw reply [flat|nested] 14+ messages in thread
* imap.netfilter.org (was Re: [H.323 Helper 1/3]: Add support for Call Forwarding)
2006-04-26 18:06 ` Jing Min Zhao
2006-04-26 20:20 ` Patrick McHardy
2006-04-26 20:21 ` Patrick McHardy
@ 2006-05-01 17:51 ` Harald Welte
2 siblings, 0 replies; 14+ messages in thread
From: Harald Welte @ 2006-05-01 17:51 UTC (permalink / raw)
To: Jing Min Zhao; +Cc: netfilter-devel, Patrick McHardy
[-- Attachment #1: Type: text/plain, Size: 1172 bytes --]
On Wed, Apr 26, 2006 at 02:06:23PM -0400, Jing Min Zhao wrote:
> >> I'm sorry. Actually, I'm always frustrated by my Outlook Express
> >> and my hotmail account :(.
> >
> > I can relate :) I think you should be able to use imap on
> > people.netfilter.org.
Almost.
> Really? That'll be great! I'll try. Thank you.
we do have imap.netfilter.org, which is _not_ people.netfilter.org. If
you want an imap account, I can configure it for you. We only allow
imap-over-ssl, IIRC. The email address there would be
username@imap.netfilter.org, and you can then set your .forward on
people.netfilter.org accordingly.
I'm currently travelling back from Brazil, please send an email in two
days as a reminder for me to create such an account, in case you're
interested.
Cheers,
--
- Harald Welte <laforge@netfilter.org> http://netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [H.323 Helper 1/3]: Add support for Call Forwarding
2006-04-28 15:13 ` Patrick McHardy
@ 2006-05-20 3:23 ` Patrick McHardy
2006-05-20 4:10 ` Jing Min Zhao
0 siblings, 1 reply; 14+ messages in thread
From: Patrick McHardy @ 2006-05-20 3:23 UTC (permalink / raw)
To: Jing Min Zhao; +Cc: netfilter-devel
[-- Attachment #1: Type: text/plain, Size: 642 bytes --]
Patrick McHardy wrote:
> Jing Min Zhao wrote:
>
>>WARNING: "ip_fib_main_table" [net/ipv4/netfilter/ip_conntrack_h323.ko] undefined!
>>WARNING: "ip_fib_local_table" [net/ipv4/netfilter/ip_conntrack_h323.ko] undefined!
>>WARNING: "free_fib_info" [net/ipv4/netfilter/ip_conntrack_h323.ko] undefined!
>
>
> Oops .. these aren't exported. Just drop the patch, I'll send you a
> better one this weekend.
Sorry for the delay, but here it is :) I've already queued your patch
for 2.6.18, if there are no problems I'll just add this one on top.
The saved_ip conversion can happen latter, currently it would conflict
with a bunch of other patches.
[-- Attachment #2: x --]
[-- Type: text/plain, Size: 3945 bytes --]
[NETFILTER]: H.323 helper: replace internal_net_addr parameter by routing-based heuristic
Call Forwarding doesn't need to create an expectation if both peers can
reach each other without our help. The internal_net_addr parameter
lets the user explicitly specify a single network where this is true,
but is not very flexible and even fails in the common case that calls
will both be forwarded to outside parties and inside parties. Use an
optional heuristic based on routing instead, the assumption is that
if bpth the outgoing device and the gateway are equal, both peers can
reach each other directly.
Signed-off-by: Patrick McHardy <kaber@trash.net>
---
commit 19d2680b3e7afec4258525d4ca13079bea4e4d7b
tree 67a780d51c8e8bde8234abc17d497177d53a2299
parent 165f6194cc61940a2277b0f0dde84695e598aebe
author Patrick McHardy <kaber@trash.net> Sat, 20 May 2006 05:16:47 +0200
committer Patrick McHardy <kaber@trash.net> Sat, 20 May 2006 05:16:47 +0200
net/ipv4/netfilter/ip_conntrack_helper_h323.c | 57 ++++++++++++-------------
1 files changed, 27 insertions(+), 30 deletions(-)
diff --git a/net/ipv4/netfilter/ip_conntrack_helper_h323.c b/net/ipv4/netfilter/ip_conntrack_helper_h323.c
index 3052468..0665674 100644
--- a/net/ipv4/netfilter/ip_conntrack_helper_h323.c
+++ b/net/ipv4/netfilter/ip_conntrack_helper_h323.c
@@ -40,12 +40,11 @@ static int gkrouted_only = 1;
module_param(gkrouted_only, int, 0600);
MODULE_PARM_DESC(gkrouted_only, "only accept calls from gatekeeper");
-static char *internal_net = NULL;
-static u_int32_t internal_net_addr = 0;
-static u_int32_t internal_net_mask = 0;
-module_param(internal_net, charp, 0600);
-MODULE_PARM_DESC(internal_net, "specify your internal network using format "
- "address/mask. this is used by call forwarding support");
+static int callforward_filter = 1;
+module_param(callforward_filter, bool, 0600);
+MODULE_PARM_DESC(callforward_filter, "only create call forwarding expectations "
+ "if both endpoints are on different sides "
+ "(determined by routing information)");
/* Hooks for NAT */
int (*set_h245_addr_hook) (struct sk_buff ** pskb,
@@ -721,12 +720,28 @@ static int expect_callforwarding(struct
/* If the calling party is on the same side of the forward-to party,
* we don't need to track the second call */
- if (internal_net &&
- ((ip & internal_net_mask) == internal_net_addr) ==
- ((ct->tuplehash[!dir].tuple.src.ip & internal_net_mask) ==
- internal_net_addr)) {
- DEBUGP("ip_ct_q931: Call Forwarding not tracked\n");
- return 0;
+ if (callforward_filter) {
+ struct rtable *rt1, *rt2;
+ struct flowi fl1 = {
+ .fl4_dst = ip,
+ };
+ struct flowi fl2 = {
+ .fl4_dst = ct->tuplehash[!dir].tuple.src.ip,
+ };
+
+ if (ip_route_output_key(&rt1, &fl1) == 0) {
+ if (ip_route_output_key(&rt2, &fl2) == 0) {
+ if (rt1->rt_gateway == rt2->rt_gateway &&
+ rt1->u.dst.dev == rt2->u.dst.dev)
+ ret = 1;
+ dst_release(&rt2->u.dst);
+ }
+ dst_release(&rt1->u.dst);
+ }
+ if (ret) {
+ DEBUGP("ip_ct_q931: Call Forwarding not tracked\n");
+ return 0;
+ }
}
/* Create expect for the second call leg */
@@ -1762,7 +1777,6 @@ static void fini(void)
static int __init init(void)
{
int ret;
- char *p;
h323_buffer = kmalloc(65536, GFP_KERNEL);
if (!h323_buffer)
@@ -1772,23 +1786,6 @@ static int __init init(void)
fini();
return ret;
}
-
- if (internal_net) {
- if ((p = strchr(internal_net, '/')))
- *p++ = 0;
- if (isdigit(internal_net[0])) {
- internal_net_addr = in_aton(internal_net);
- if (p && isdigit(p[0]))
- internal_net_mask = in_aton(p);
- else
- internal_net_mask = 0xffffffff;
- internal_net_addr &= internal_net_mask;
- }
- DEBUGP("ip_ct_h323: internal_net = %u.%u.%u.%u/%u.%u.%u.%u\n",
- NIPQUAD(internal_net_addr),
- NIPQUAD(internal_net_mask));
- }
-
DEBUGP("ip_ct_h323: init success\n");
return 0;
}
^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [H.323 Helper 1/3]: Add support for Call Forwarding
2006-05-20 3:23 ` Patrick McHardy
@ 2006-05-20 4:10 ` Jing Min Zhao
0 siblings, 0 replies; 14+ messages in thread
From: Jing Min Zhao @ 2006-05-20 4:10 UTC (permalink / raw)
To: Patrick McHardy, Jing Min Zhao; +Cc: netfilter-devel
Thank you, Patrick. This patch is very important. It can also be used
by the future H.450 features. I'd like to make these code a general
function. I'll do this when I come back in 3 days.
----- Original Message -----
From: "Patrick McHardy" <kaber@trash.net>
To: "Jing Min Zhao" <zhaojingmin@users.sourceforge.net>
Cc: <netfilter-devel@lists.netfilter.org>
Sent: Friday, May 19, 2006 11:23 PM
Subject: Re: [H.323 Helper 1/3]: Add support for Call Forwarding
> Patrick McHardy wrote:
>> Jing Min Zhao wrote:
>>
>>>WARNING: "ip_fib_main_table" [net/ipv4/netfilter/ip_conntrack_h323.ko]
>>>undefined!
>>>WARNING: "ip_fib_local_table" [net/ipv4/netfilter/ip_conntrack_h323.ko]
>>>undefined!
>>>WARNING: "free_fib_info" [net/ipv4/netfilter/ip_conntrack_h323.ko]
>>>undefined!
>>
>>
>> Oops .. these aren't exported. Just drop the patch, I'll send you a
>> better one this weekend.
>
> Sorry for the delay, but here it is :) I've already queued your patch
> for 2.6.18, if there are no problems I'll just add this one on top.
> The saved_ip conversion can happen latter, currently it would conflict
> with a bunch of other patches.
>
--------------------------------------------------------------------------------
> [NETFILTER]: H.323 helper: replace internal_net_addr parameter by
> routing-based heuristic
>
> Call Forwarding doesn't need to create an expectation if both peers can
> reach each other without our help. The internal_net_addr parameter
> lets the user explicitly specify a single network where this is true,
> but is not very flexible and even fails in the common case that calls
> will both be forwarded to outside parties and inside parties. Use an
> optional heuristic based on routing instead, the assumption is that
> if bpth the outgoing device and the gateway are equal, both peers can
> reach each other directly.
>
> Signed-off-by: Patrick McHardy <kaber@trash.net>
>
> ---
> commit 19d2680b3e7afec4258525d4ca13079bea4e4d7b
> tree 67a780d51c8e8bde8234abc17d497177d53a2299
> parent 165f6194cc61940a2277b0f0dde84695e598aebe
> author Patrick McHardy <kaber@trash.net> Sat, 20 May 2006 05:16:47 +0200
> committer Patrick McHardy <kaber@trash.net> Sat, 20 May 2006 05:16:47
> +0200
>
> net/ipv4/netfilter/ip_conntrack_helper_h323.c | 57
> ++++++++++++-------------
> 1 files changed, 27 insertions(+), 30 deletions(-)
>
> diff --git a/net/ipv4/netfilter/ip_conntrack_helper_h323.c
> b/net/ipv4/netfilter/ip_conntrack_helper_h323.c
> index 3052468..0665674 100644
> --- a/net/ipv4/netfilter/ip_conntrack_helper_h323.c
> +++ b/net/ipv4/netfilter/ip_conntrack_helper_h323.c
> @@ -40,12 +40,11 @@ static int gkrouted_only = 1;
> module_param(gkrouted_only, int, 0600);
> MODULE_PARM_DESC(gkrouted_only, "only accept calls from gatekeeper");
>
> -static char *internal_net = NULL;
> -static u_int32_t internal_net_addr = 0;
> -static u_int32_t internal_net_mask = 0;
> -module_param(internal_net, charp, 0600);
> -MODULE_PARM_DESC(internal_net, "specify your internal network using
> format "
> - "address/mask. this is used by call forwarding support");
> +static int callforward_filter = 1;
> +module_param(callforward_filter, bool, 0600);
> +MODULE_PARM_DESC(callforward_filter, "only create call forwarding
> expectations "
> + "if both endpoints are on different sides "
> + "(determined by routing information)");
>
> /* Hooks for NAT */
> int (*set_h245_addr_hook) (struct sk_buff ** pskb,
> @@ -721,12 +720,28 @@ static int expect_callforwarding(struct
>
> /* If the calling party is on the same side of the forward-to party,
> * we don't need to track the second call */
> - if (internal_net &&
> - ((ip & internal_net_mask) == internal_net_addr) ==
> - ((ct->tuplehash[!dir].tuple.src.ip & internal_net_mask) ==
> - internal_net_addr)) {
> - DEBUGP("ip_ct_q931: Call Forwarding not tracked\n");
> - return 0;
> + if (callforward_filter) {
> + struct rtable *rt1, *rt2;
> + struct flowi fl1 = {
> + .fl4_dst = ip,
> + };
> + struct flowi fl2 = {
> + .fl4_dst = ct->tuplehash[!dir].tuple.src.ip,
> + };
> +
> + if (ip_route_output_key(&rt1, &fl1) == 0) {
> + if (ip_route_output_key(&rt2, &fl2) == 0) {
> + if (rt1->rt_gateway == rt2->rt_gateway &&
> + rt1->u.dst.dev == rt2->u.dst.dev)
> + ret = 1;
> + dst_release(&rt2->u.dst);
> + }
> + dst_release(&rt1->u.dst);
> + }
> + if (ret) {
> + DEBUGP("ip_ct_q931: Call Forwarding not tracked\n");
> + return 0;
> + }
> }
>
> /* Create expect for the second call leg */
> @@ -1762,7 +1777,6 @@ static void fini(void)
> static int __init init(void)
> {
> int ret;
> - char *p;
>
> h323_buffer = kmalloc(65536, GFP_KERNEL);
> if (!h323_buffer)
> @@ -1772,23 +1786,6 @@ static int __init init(void)
> fini();
> return ret;
> }
> -
> - if (internal_net) {
> - if ((p = strchr(internal_net, '/')))
> - *p++ = 0;
> - if (isdigit(internal_net[0])) {
> - internal_net_addr = in_aton(internal_net);
> - if (p && isdigit(p[0]))
> - internal_net_mask = in_aton(p);
> - else
> - internal_net_mask = 0xffffffff;
> - internal_net_addr &= internal_net_mask;
> - }
> - DEBUGP("ip_ct_h323: internal_net = %u.%u.%u.%u/%u.%u.%u.%u\n",
> - NIPQUAD(internal_net_addr),
> - NIPQUAD(internal_net_mask));
> - }
> -
> DEBUGP("ip_ct_h323: init success\n");
> return 0;
> }
>
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2006-05-20 4:10 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-04-24 3:40 [H.323 Helper 1/3]: Add support for Call Forwarding Jing Min Zhao
2006-04-26 13:48 ` Patrick McHardy
2006-04-26 14:33 ` Jing Min Zhao
2006-04-26 16:49 ` Patrick McHardy
2006-04-26 18:06 ` Jing Min Zhao
2006-04-26 20:20 ` Patrick McHardy
2006-04-26 20:21 ` Patrick McHardy
2006-04-26 21:15 ` Jing Min Zhao
2006-04-27 19:57 ` Patrick McHardy
2006-04-28 15:07 ` Jing Min Zhao
2006-04-28 15:13 ` Patrick McHardy
2006-05-20 3:23 ` Patrick McHardy
2006-05-20 4:10 ` Jing Min Zhao
2006-05-01 17:51 ` imap.netfilter.org (was Re: [H.323 Helper 1/3]: Add support for Call Forwarding) Harald Welte
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.