[H.323 Helper 1/3]: Add support for Call Forwarding

[Jing Min Zhao]

----- Original Message ----- 
From: "Patrick McHardy" <kaber at trash.net>
To: "Jing Min Zhao" <zhaojingmin at hotmail.com>
Cc: <netfilter-devel at 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 at 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