Mailing List Archive: iptables: Devel

New H.323 conntrack & NAT helper module

Index | Next | Previous | View Threaded

zhaojingmin at hotmail

Feb 21, 2006, 9:56 PM

Post #1 of 23 (3571 views)
Permalink

New H.323 conntrack & NAT helper module

Hi, all,

I've written a new H.323 conntrack & NAT helper module for Netfilter.

I have five years experience in H.323 development and many years in Linux
development, so I know many people out there need Linux firewall to support
H.323 as IP phones are becoming more and more popular. I also know Jozsef
Kadlecsik and Max Kellermann have written such Netfilter modules, but they
don't support RAS, Fast-Start and H.245 tunnelling. However, these features
are essential for most modern H.323 devices. Many carriers even don't
support slow-start at all.

This is a almost full featured H.323 module. Since it is based on H.225
version 4, H.235 version 2 and H.245 version 7, it should support most of
the H.323 products in the market. I've spent a lot of time on this module
and my friends helped me test it a lot too. Now I believe it is ready to go
into kernel tree. I'm wondering if anybody can tell me what I should do to
adding it to Netfilter.

Anybody interested in this can download the patch for kernel 2.6.15 in
http://sourceforge.net/project/showfiles.php?group_id=158936. The document
is at http://nath323.sourceforge.net.

Thanks a lot!

Jing Min Zhao

kaber at trash

Feb 21, 2006, 10:17 PM

Post #2 of 23 (3509 views)
Permalink

Re: New H.323 conntrack & NAT helper module [In reply to]

Jing Min Zhao wrote:
> Hi, all,
>
> I've written a new H.323 conntrack & NAT helper module for Netfilter.
>
> I have five years experience in H.323 development and many years in Linux
> development, so I know many people out there need Linux firewall to support
> H.323 as IP phones are becoming more and more popular. I also know Jozsef
> Kadlecsik and Max Kellermann have written such Netfilter modules, but they
> don't support RAS, Fast-Start and H.245 tunnelling. However, these features
> are essential for most modern H.323 devices. Many carriers even don't
> support slow-start at all.

This is great news. I'm actually currently working on an improved
version of the H.323 tracker myself, my version also supports
Fast-Start and Tunneling, but I'm still working on RAS tracking.
Since I'm missing you're 5 years H.323 experience, there's a good
chance that your version is better, I'll have a closer look today.

GregScott at InfraSupportEtc

Feb 24, 2006, 8:00 PM

Post #3 of 23 (3505 views)
Permalink

RE: New H.323 conntrack & NAT helper module [In reply to]

Holey moley - this is GREAT news!!

A couple questions. Will this module work with 2.6.16 and upcoming
newer kernels? And - this is a biggie - the documentation says all I
need to do is SNAT TCP 1720 for outbound calls and DNAT TCP 1720 for
inbound calls. No more tinkering by hand with zillions of TCP/UDP ports
- no more trying to figure out if Polycom or Tandberg or whatever is on
which end. Is this really true??? Will this patch really figure out
and track the dynamic ports these devices use by default? If so, then
HOT DOGGIES!!!!

Also - will it work with proxy ARP? Let's say I proxy ARP an H.323
device behind the firewall. Will this patch still handle connection
tracking, even though there is no NAT? The idea is, I would put a rule
in the FORWARD table for TCP 1720 and the patch would "know" it's an
H.323 device and also track and forward the appropriate TCP and UDP
ports. But it would be to a public IP Address proxy ARP'd behind the
firewall instead of a NAT'd device.

thanks

- Greg Scott

-----Original Message-----
From: netfilter-devel-bounces[at]lists.netfilter.org
[mailto:netfilter-devel-bounces[at]lists.netfilter.org] On Behalf Of Jing
Min Zhao
Sent: Tuesday, February 21, 2006 11:57 PM
To: netfilter-devel[at]lists.netfilter.org
Subject: New H.323 conntrack & NAT helper module

Hi, all,

I've written a new H.323 conntrack & NAT helper module for Netfilter.

I have five years experience in H.323 development and many years in
Linux development, so I know many people out there need Linux firewall
to support H.323 as IP phones are becoming more and more popular. I also
know Jozsef Kadlecsik and Max Kellermann have written such Netfilter
modules, but they don't support RAS, Fast-Start and H.245 tunnelling.
However, these features are essential for most modern H.323 devices.
Many carriers even don't support slow-start at all.

This is a almost full featured H.323 module. Since it is based on H.225
version 4, H.235 version 2 and H.245 version 7, it should support most
of the H.323 products in the market. I've spent a lot of time on this
module and my friends helped me test it a lot too. Now I believe it is
ready to go into kernel tree. I'm wondering if anybody can tell me what
I should do to adding it to Netfilter.

Anybody interested in this can download the patch for kernel 2.6.15 in
http://sourceforge.net/project/showfiles.php?group_id=158936. The
document is at http://nath323.sourceforge.net.

Thanks a lot!

Jing Min Zhao

zhaojingmin at hotmail

Feb 24, 2006, 10:00 PM

Post #4 of 23 (3503 views)
Permalink

Re: New H.323 conntrack & NAT helper module [In reply to]

On Friday February 24, 2006 11:00 PM, Greg Scott wrote:
>
> Holey moley - this is GREAT news!!

Thanks!

> A couple questions. Will this module work with 2.6.16 and upcoming
> newer kernels?

Yes. I'll keep tracking the kernel development. Once a big version comes
out,
I'll update this patch. I think maybe Patrick McHardy is inspecting my code,
if
I'm lucky, it may go into the kernel tree, and you won't need a separate
patch
any more. I really hope so.

> And - this is a biggie - the documentation says all I
> need to do is SNAT TCP 1720 for outbound calls and DNAT TCP 1720 for
> inbound calls. No more tinkering by hand with zillions of TCP/UDP ports
> - no more trying to figure out if Polycom or Tandberg or whatever is on
> which end. Is this really true???

Yes, and it's more than that. Actually, you don't need to specify the port
1720 -
the module knows it, unless you want NAT only H.323 traffic. For inbound
calls,
if you use a gatekeeper, you don't need the DNAT rule.

> Will this patch really figure out
> and track the dynamic ports these devices use by default?

Yes.

> If so, then
> HOT DOGGIES!!!!

:)

> Also - will it work with proxy ARP?

This does nothing to do with the module. Sorry I'm not sure.

> Let's say I proxy ARP an H.323
> device behind the firewall. Will this patch still handle connection
> tracking, even though there is no NAT?

Yes, it support this mode. Just don't load ip_nat_h323, load only
ip_conntrack_h323.

> The idea is, I would put a rule
> in the FORWARD table for TCP 1720 and the patch would "know" it's an
> H.323 device and also track and forward the appropriate TCP and UDP
> ports. But it would be to a public IP Address proxy ARP'd behind the
> firewall instead of a NAT'd device.
>
> thanks
>
> - Greg Scott

Thanks

Jing Min Zhao

kaber at trash

Feb 25, 2006, 1:01 AM

Post #5 of 23 (3505 views)
Permalink

Re: New H.323 conntrack & NAT helper module [In reply to]

Jing Min Zhao wrote:
> I think maybe Patrick McHardy is inspecting my code, if I'm lucky,
> it may go into the kernel tree, and you won't need a separate
> patch any more. I really hope so.

I'm almost done reviewing it. It really looks great, it is the IMO
cleanest conntrack helper so far, which is really an achievement
for such a complex thing. I've fixed a number of smaller issues
and prepared patches for that, I'll send the first batch in follow-up
mail.

Besides my patches, I have a few small issues with the patch, but if
they are resolved I'd be happy to put this helper into 2.6.17.

The issues so far:

- ASN1 parser: I would prefer the parser to be seperated from the
H.225/H.245 data.

- ASN1 parser: Right now the H.225/H.245 data includes lots of
forward declarations, probably because it seem to be in the
same order as in the ASN.1 file. The forward declarations make
it a lot harder to verify that their is no recursion, so I would
prefer to have the data ordered in a way that doesn't need them.

- TPKT handling: I've seen gnomemeeting send nested TPKTs about a year
ago when I worked on my helper. I can't get it do it anymore, but my
question is if it nested TPKTs are something that should be supported.

- process_rcf uses the stored sig_port to find the expectation and
adjust it's timeout. The sig_port is only set with NAT however.
This seems to be a bug.

- RAS tracking: should be made optional IMO. This is the only part
where foreign IP addresses not belonging to the connection are
used for expectations, which is potentially dangerous.

I'll describe the other issues in the mails containing the patches.

zhaojingmin at hotmail

Feb 25, 2006, 9:07 AM

Post #6 of 23 (3501 views)
Permalink

Re: New H.323 conntrack & NAT helper module [In reply to]

----- Original Message -----
From: "Patrick McHardy" <kaber[at]trash.net>
To: "Jing Min Zhao" <zhaojingmin[at]hotmail.com>
Cc: <netfilter-devel[at]lists.netfilter.org>; "Greg Scott"
<GregScott[at]InfraSupportEtc.com>
Sent: Saturday, February 25, 2006 4:01 AM
Subject: Re: New H.323 conntrack & NAT helper module

> Jing Min Zhao wrote:
>> I think maybe Patrick McHardy is inspecting my code, if I'm lucky,
>> it may go into the kernel tree, and you won't need a separate
>> patch any more. I really hope so.
>
> I'm almost done reviewing it. It really looks great, it is the IMO
> cleanest conntrack helper so far, which is really an achievement
> for such a complex thing. I've fixed a number of smaller issues
> and prepared patches for that, I'll send the first batch in follow-up
> mail.

I've seen all your patches. I can't believe this. I spent almost 2 months to
write the code, but it took you only 3 days to find out so many issues!
And I know you were still doing other things while you were reviewing my
code. Now I know not everybody can do the work you guys are doing.

>
> Besides my patches, I have a few small issues with the patch, but if
> they are resolved I'd be happy to put this helper into 2.6.17.
>

This is really great news! I'll try my best.

> The issues so far:
>
> - ASN1 parser: I would prefer the parser to be seperated from the
> H.225/H.245 data.
>

OK, I'll seperate them. I was just trying to make the code look clean.

> - ASN1 parser: Right now the H.225/H.245 data includes lots of
> forward declarations, probably because it seem to be in the
> same order as in the ASN.1 file. The forward declarations make
> it a lot harder to verify that their is no recursion, so I would
> prefer to have the data ordered in a way that doesn't need them.
>

I generated the object definitions using a parser. I was too lazy to sort
them. But
it seems not a good format for the kernel. I'll modify my parser to sort
them.

> - TPKT handling: I've seen gnomemeeting send nested TPKTs about a year
> ago when I worked on my helper. I can't get it do it anymore, but my
> question is if it nested TPKTs are something that should be supported.
>

What kind of nested TPKTs do you mean? A packet containing multiple TPKTs or
a TPKT containing another TPKT? I can't imagine the latter situation. But if
it's the first
situation, you are right. I didn't think of this. Thank you.

> - process_rcf uses the stored sig_port to find the expectation and
> adjust it's timeout. The sig_port is only set with NAT however.
> This seems to be a bug.
>

I'll fix this.

> - RAS tracking: should be made optional IMO. This is the only part
> where foreign IP addresses not belonging to the connection are
> used for expectations, which is potentially dangerous.
>

I totally agree with you. I'll add a parameter for this.

> I'll describe the other issues in the mails containing the patches.
>
>

Thank you so much!

Jing Min Zhao

kaber at trash

Feb 25, 2006, 10:43 AM

Post #7 of 23 (3498 views)
Permalink

Re: New H.323 conntrack & NAT helper module [In reply to]

Jing Min Zhao wrote:
>> I'm almost done reviewing it. It really looks great, it is the IMO
>> cleanest conntrack helper so far, which is really an achievement
>> for such a complex thing. I've fixed a number of smaller issues
>> and prepared patches for that, I'll send the first batch in follow-up
>> mail.
>
>
> I've seen all your patches. I can't believe this. I spent almost 2
> months to
> write the code, but it took you only 3 days to find out so many issues!
> And I know you were still doing other things while you were reviewing my
> code. Now I know not everybody can do the work you guys are doing.

Thanks, I'm pretty good at finding bugs :)

>> Besides my patches, I have a few small issues with the patch, but if
>> they are resolved I'd be happy to put this helper into 2.6.17.
>>
>
> This is really great news! I'll try my best.
>
>> The issues so far:
>>
>> - ASN1 parser: I would prefer the parser to be seperated from the
>> H.225/H.245 data.
>>
>
> OK, I'll seperate them. I was just trying to make the code look clean.

I wouldn't put them in the helper itself, maybe just a seperate file,
ip_conntrack_h323_helper_asn.c or something like that.

>> - ASN1 parser: Right now the H.225/H.245 data includes lots of
>> forward declarations, probably because it seem to be in the
>> same order as in the ASN.1 file. The forward declarations make
>> it a lot harder to verify that their is no recursion, so I would
>> prefer to have the data ordered in a way that doesn't need them.
>>
>
> I generated the object definitions using a parser. I was too lazy to
> sort them. But
> it seems not a good format for the kernel. I'll modify my parser to sort
> them.

So you automatically generated them? It would be nice to have the script
and the ASN1 files integrated in the build process and generate the
structures on the fly, in that case I wouldn't care about the order.
Forward declarations just make it hard to verify that their is no
recursion, without them it trivial, there can't be any.

>> - TPKT handling: I've seen gnomemeeting send nested TPKTs about a year
>> ago when I worked on my helper. I can't get it do it anymore, but my
>> question is if it nested TPKTs are something that should be supported.
>>
>
> What kind of nested TPKTs do you mean? A packet containing multiple
> TPKTs or
> a TPKT containing another TPKT? I can't imagine the latter situation.
> But if it's the first
> situation, you are right. I didn't think of this. Thank you.

I meant TPKTs following TPKTs. The non-linear SKB patch should make
it easy to support them since the data pointer isn't reloaded by
the NAT part anymore.

>> - RAS tracking: should be made optional IMO. This is the only part
>> where foreign IP addresses not belonging to the connection are
>> used for expectations, which is potentially dangerous.
>>
>
> I totally agree with you. I'll add a parameter for this.
>
>
>> I'll describe the other issues in the mails containing the patches.
>>
>>
>
> Thank you so much!

Well, thank you, This is really great work. I forgot one small issue:
there seems to be some debugging-leftover, the functions registering
expectations add up the number of registered expectations and return
that value, but nobody uses it. If there are no plans for using it,
I would prefer to have it removed.

zhaojingmin at hotmail

Feb 28, 2006, 6:57 PM

Post #8 of 23 (3490 views)
Permalink

Re: New H.323 conntrack & NAT helper module [In reply to]

----- Original Message -----
From: "Patrick McHardy" <kaber[at]trash.net>
To: "Jing Min Zhao" <zhaojingmin[at]hotmail.com>
Cc: <netfilter-devel[at]lists.netfilter.org>; "Greg Scott"
<GregScott[at]InfraSupportEtc.com>
Sent: Saturday, February 25, 2006 1:43 PM
Subject: Re: New H.323 conntrack & NAT helper module

Hi, Patrick,

Thank you for your patches, they are very helpful. I've already applied the
patch for
excessive stack usage. For the patch of adding support for non-linear SKBs,
I admit
it is even a bug if there is no support for non-linear SKBs, but I have
some different
idea for the checksum method.

> Add support for non-linear SKBs. I know switching to
> ip_nat_mangle_{tcp,udp}_packet is less efficient because it checksums
> the packet on each call, but that can be fixed seperately by switching
> it to incremental checksumming.

Imagine a Setup signal with 30 fast-start entries (this is not unusual for
Gnomemeeting
and OpenPhone), if you use ip_nat_mangle_tcp_packet, you will have to call
it 45
times. For a RRQ message, you will possible call ip_nat_mangle_udp_packet
more
than 10 times if it contains many signal addresses. You can use incremental
checksumming, but I'm still worrying about the efficiency. This is why I
prefer to use
a counter (please see the last paragraph) to track modifications and do the
checksum only once.

> Change the H.323 helper to support non-linear skbs similar to the other
> helpers. This has two additional positive side-effects:

> - skb_writable was broken as it always tried to reload the data pointer
> with
> an assumed TPKT payload, even for H.225 RAS packets.

This can be fixed by seeing the protocol.

> - we can use the regular NAT packet mangling functions and get rid of the
> manual checksumming

>
> Well, thank you, This is really great work. I forgot one small issue:
> there seems to be some debugging-leftover, the functions registering
> expectations add up the number of registered expectations and return
> that value, but nobody uses it. If there are no plans for using it,
> I would prefer to have it removed.
>

The return is actually a modification track counter. If a function
successfully changed a
packet, the counter will be increased. Finally, if the counter is positive,
the packet will be
checksumed; if it's 0, no changes; if negative, error happened.

Best regards,
Jing Min Zhao

kaber at trash

Mar 4, 2006, 1:41 AM

Post #9 of 23 (3490 views)
Permalink

Re: New H.323 conntrack & NAT helper module [In reply to]

Jing Min Zhao wrote:
> For the patch of adding support for non-linear SKBs, I admit
> it is even a bug if there is no support for non-linear SKBs, but I have
> some different idea for the checksum method.
>
>> Add support for non-linear SKBs. I know switching to
>> ip_nat_mangle_{tcp,udp}_packet is less efficient because it checksums
>> the packet on each call, but that can be fixed seperately by switching
>> it to incremental checksumming.
>
>
> Imagine a Setup signal with 30 fast-start entries (this is not unusual
> for Gnomemeeting
> and OpenPhone), if you use ip_nat_mangle_tcp_packet, you will have to
> call it 45
> times. For a RRQ message, you will possible call
> ip_nat_mangle_udp_packet more
> than 10 times if it contains many signal addresses. You can use incremental
> checksumming, but I'm still worrying about the efficiency. This is why I
> prefer to use
> a counter (please see the last paragraph) to track modifications and do the
> checksum only once.

I would expect incremental checksumming to be less expensive than
redoing the entire checksum. I'll try to get a patch ready for
testing this weekend, than we can compare the two approaches.

>
>> Change the H.323 helper to support non-linear skbs similar to the other
>> helpers. This has two additional positive side-effects:
>
>
>> - skb_writable was broken as it always tried to reload the data
>> pointer with
>> an assumed TPKT payload, even for H.225 RAS packets.
>
>
> This can be fixed by seeing the protocol.

Yes, but it complicates parsing multiple TPKTs.

>> there seems to be some debugging-leftover, the functions registering
>> expectations add up the number of registered expectations and return
>> that value, but nobody uses it. If there are no plans for using it,
>> I would prefer to have it removed.
>>
>
> The return is actually a modification track counter. If a function
> successfully changed a
> packet, the counter will be increased. Finally, if the counter is
> positive, the packet will be
> checksumed; if it's 0, no changes; if negative, error happened.

Ahh of course. I only looked for users after removing the csum hook.

zhaojingmin at hotmail

Mar 12, 2006, 6:22 PM

Post #10 of 23 (3442 views)
Permalink

Re: New H.323 conntrack & NAT helper module [In reply to]

----- 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: Saturday, March 04, 2006 4:41 AM
Subject: Re: New H.323 conntrack & NAT helper module

>
> I would expect incremental checksumming to be less expensive than
> redoing the entire checksum. I'll try to get a patch ready for
> testing this weekend, than we can compare the two approaches.
>

OK, I think you know much more of kernel than I do anyway, so I have
changed the code based on your patches. The new module (version 0.3)
is ready for download at
http://sourceforge.net/project/showfiles.php?group_id=158936.
The document at http://nath323.sourceforge.net is updated.

Following are the changes:

1. Added support for multiple TPKTs in one packet (suggested by Patrick
McHardy)
2. Avoid excessive stack usage (based on Patrick McHardy's patch)
3. Added support for non-linear skb (based on Patrick McHardy's patch)
4. Fixed missing H.245 module owner (Patrick McHardy)
5. Avoid long RAS expectation chains (Patrick McHardy)
6. Fixed incorrect __exit attribute (Patrick McHardy)
7. Eliminated unnecessary return code
8. Fixed incorrect use of NAT data from conntrack code (found by Patrick
McHardy)
9. Fixed TTL calculation error in RCF
10. Added TTL support in RRQ
11. Better support for separate TPKT header and data

Next week I'll release a newer version for these issues:

1. Separate ASN.1 code and data.
2. Sort H.323 data to avoid forwarding declarations
3. Add a parameter to make Q.931 signal expect for any address optional.
4. Add support for T.120.

Best regards,

Jing Min Zhao

kaber at trash

Mar 13, 2006, 7:00 AM

Post #11 of 23 (3436 views)
Permalink

Re: New H.323 conntrack & NAT helper module [In reply to]

Jing Min Zhao wrote:
> OK, I think you know much more of kernel than I do anyway, so I have
> changed the code based on your patches. The new module (version 0.3)
> is ready for download at
> http://sourceforge.net/project/showfiles.php?group_id=158936.
> The document at http://nath323.sourceforge.net is updated.
>
> Following are the changes:
>
> 1. Added support for multiple TPKTs in one packet (suggested by Patrick
> McHardy)
> 2. Avoid excessive stack usage (based on Patrick McHardy's patch)
> 3. Added support for non-linear skb (based on Patrick McHardy's patch)
> 4. Fixed missing H.245 module owner (Patrick McHardy)
> 5. Avoid long RAS expectation chains (Patrick McHardy)
> 6. Fixed incorrect __exit attribute (Patrick McHardy)
> 7. Eliminated unnecessary return code
> 8. Fixed incorrect use of NAT data from conntrack code (found by Patrick
> McHardy)
> 9. Fixed TTL calculation error in RCF
> 10. Added TTL support in RRQ
> 11. Better support for separate TPKT header and data
>
> Next week I'll release a newer version for these issues:
>
> 1. Separate ASN.1 code and data.
> 2. Sort H.323 data to avoid forwarding declarations
> 3. Add a parameter to make Q.931 signal expect for any address optional.
> 4. Add support for T.120.

Great, thanks. When you release the new version, please also post
the patch to netfilter-devel and add a Signed-off-by: line (see
Documentation/SubmittingPatches in the kernel source).

zhaojingmin at hotmail

Mar 15, 2006, 6:24 PM

Post #12 of 23 (3414 views)
Permalink

Re: New H.323 conntrack & NAT helper module [In reply to]

----- 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: Monday, March 13, 2006 10:00 AM
Subject: Re: New H.323 conntrack & NAT helper module

>
> Great, thanks. When you release the new version, please also post
> the patch to netfilter-devel and add a Signed-off-by: line (see
> Documentation/SubmittingPatches in the kernel source).
>
>

I have finished the new release. The new parameter and T.120 support
have been added. But the uncompressed patch is pretty big, about 228KB.
Do you think it's ok to post it here?

Thanks a lot!

Jing Min Zhao

kaber at trash

Mar 16, 2006, 12:55 AM

Post #13 of 23 (3413 views)
Permalink

Re: New H.323 conntrack & NAT helper module [In reply to]

Jing Min Zhao wrote:
>> Great, thanks. When you release the new version, please also post
>> the patch to netfilter-devel and add a Signed-off-by: line (see
>> Documentation/SubmittingPatches in the kernel source).
>>
>>
>
> I have finished the new release. The new parameter and T.120 support
> have been added. But the uncompressed patch is pretty big, about 228KB.
> Do you think it's ok to post it here?

We used to have a pretty small size limit, but I think it has been
lifted. Just try if it works.

zhaojingmin at hotmail

Mar 17, 2006, 6:56 AM

Post #14 of 23 (3402 views)
Permalink

Re: New H.323 conntrack & NAT helper module [In reply to]

----- 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: Thursday, March 16, 2006 3:55 AM
Subject: Re: New H.323 conntrack & NAT helper module

> Jing Min Zhao wrote:
>>> Great, thanks. When you release the new version, please also post
>>> the patch to netfilter-devel and add a Signed-off-by: line (see
>>> Documentation/SubmittingPatches in the kernel source).
>>>
>>>
>>
>> I have finished the new release. The new parameter and T.120 support
>> have been added. But the uncompressed patch is pretty big, about 228KB.
>> Do you think it's ok to post it here?
>
> We used to have a pretty small size limit, but I think it has been
> lifted. Just try if it works.
>
>

Here comes the latest release.

The main new feature of this release is T.120 support.
So chat, whiteboard, file transfer and other T.120 applications are
supported now.

The second new feature is a parameter "gkrouted_only" for
ip_conntrack_h323 module. If you set gkrouted_only to 1, only calls from
the gatekeeper will be forwarded to the registered endpoint.

Change log:

1. Added support for T.120 channels
2. Added parameter gkrouted_only (suggested by Patrick McHardy)
3. Splitted ASN.1 code and data (suggested by Patrick McHardy)
4. Sort ASN.1 data to avoid forwarding declarations (suggested by Patrick McHardy)
5. Reset next TPKT data length in get_tpkt_data()

Best regards.

Jing Min Zhao

Attachments:

patch-2.6.15-nath323-0.4 (223 KB)

zhaojingmin at hotmail

Mar 18, 2006, 8:38 AM

Post #15 of 23 (3397 views)
Permalink

Re: New H.323 conntrack & NAT helper module [In reply to]

----- 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: Thursday, March 16, 2006 3:55 AM
Subject: Re: New H.323 conntrack & NAT helper module

> Jing Min Zhao wrote:
>>> Great, thanks. When you release the new version, please also post
>>> the patch to netfilter-devel and add a Signed-off-by: line (see
>>> Documentation/SubmittingPatches in the kernel source).
>>>
>>>
>>
>> I have finished the new release. The new parameter and T.120 support
>> have been added. But the uncompressed patch is pretty big, about 228KB.
>> Do you think it's ok to post it here?
>
> We used to have a pretty small size limit, but I think it has been
> lifted. Just try if it works.
>
>
I tried, but it didn't work, so now I send it as compressed.

The main new feature of this release is T.120 support. So chat, whiteboard,
file transfer and other T.120 applications are now supported.

The second new feature is a parameter "gkrouted_only" for ip_conntrack_h323
module. If set it to 1, only calls from the gatekeeper will be forwarded to
the
registered endpoint.

Change log:

1. Added support for T.120 channels
2. Added parameter gkrouted_only (suggested by Patrick McHardy)
3. Splitted ASN.1 code and data (suggested by Patrick McHardy)
4. Sort ASN.1 data to avoid forwarding declarations (suggested by Patrick
McHardy)
5. Reset next TPKT data length in get_tpkt_data()

Best regards

Jing Min Zhao

Signed-off-by: Jing Min Zhao <zhaojignmin[at]hotmail.com>

Attachments:

patch-2.6.15-nath323-0.4.bz2 (26.0 KB)

kaber at trash

Mar 18, 2006, 8:47 AM

Post #16 of 23 (3397 views)
Permalink

Re: New H.323 conntrack & NAT helper module [In reply to]

Jing Min Zhao wrote:
> I tried, but it didn't work, so now I send it as compressed.

Thanks, thats fine too.

> The main new feature of this release is T.120 support. So chat, whiteboard,
> file transfer and other T.120 applications are now supported.
>
> The second new feature is a parameter "gkrouted_only" for ip_conntrack_h323
> module. If set it to 1, only calls from the gatekeeper will be forwarded
> to the
> registered endpoint.

Since the H.323 helper behaves different than other helpers in this
regard and many people just load all available helpers, I would prefer
if it defaulted to off. If you agree I'm simply going to change this,
no need to send a new patch.

> Change log:
>
> 1. Added support for T.120 channels
> 2. Added parameter gkrouted_only (suggested by Patrick McHardy)
> 3. Splitted ASN.1 code and data (suggested by Patrick McHardy)
> 4. Sort ASN.1 data to avoid forwarding declarations (suggested by
> Patrick McHardy)
> 5. Reset next TPKT data length in get_tpkt_data()

Thanks a lot. I'll review the patch this weekend, if there are no
new issues I'll put it in my 2.6.17 tree.

zhaojingmin at hotmail

Mar 18, 2006, 9:13 AM

Post #17 of 23 (3400 views)
Permalink

Re: New H.323 conntrack & NAT helper module [In reply to]

----- 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: Saturday, March 18, 2006 11:47 AM
Subject: Re: New H.323 conntrack & NAT helper module

> Jing Min Zhao wrote:
>> I tried, but it didn't work, so now I send it as compressed.
>
> Thanks, thats fine too.
>
>> The main new feature of this release is T.120 support. So chat,
>> whiteboard,
>> file transfer and other T.120 applications are now supported.
>>
>> The second new feature is a parameter "gkrouted_only" for
>> ip_conntrack_h323
>> module. If set it to 1, only calls from the gatekeeper will be forwarded
>> to the
>> registered endpoint.
>
> Since the H.323 helper behaves different than other helpers in this
> regard and many people just load all available helpers, I would prefer
> if it defaulted to off. If you agree I'm simply going to change this,
> no need to send a new patch.
>

Sorry, I forgot to say that the default value is 0. Sure you can change it.

>> Change log:
>>
>> 1. Added support for T.120 channels
>> 2. Added parameter gkrouted_only (suggested by Patrick McHardy)
>> 3. Splitted ASN.1 code and data (suggested by Patrick McHardy)
>> 4. Sort ASN.1 data to avoid forwarding declarations (suggested by
>> Patrick McHardy)
>> 5. Reset next TPKT data length in get_tpkt_data()
>
> Thanks a lot. I'll review the patch this weekend, if there are no
> new issues I'll put it in my 2.6.17 tree.
>
>

That's great.

Many Thanks!

Jing Min Zhao

kaber at trash

Mar 20, 2006, 6:22 AM

Post #18 of 23 (3388 views)
Permalink

Re: New H.323 conntrack & NAT helper module [In reply to]

Jing Min Zhao wrote:
> The main new feature of this release is T.120 support. So chat, whiteboard,
> file transfer and other T.120 applications are now supported.
>
> Signed-off-by: Jing Min Zhao <zhaojignmin[at]hotmail.com>

Thanks, applied. I've made three small changes before applying it:

- Change gkrouted_only default to 1
- Remove #ifndef offsetof in ASN.1 parser
- Initialize datalen to 0 in ras_help to silence an incorrect gcc
warning. I usually don't do this, but last time Linus complained
about new code giving (a correct) warning.

Thanks again.

zhaojingmin at hotmail

Mar 20, 2006, 7:51 AM

Post #19 of 23 (3390 views)
Permalink

Re: New H.323 conntrack & NAT helper module [In reply to]

----- 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: Monday, March 20, 2006 9:22 AM
Subject: Re: New H.323 conntrack & NAT helper module

> Jing Min Zhao wrote:
>> The main new feature of this release is T.120 support. So chat, whiteboard,
>> file transfer and other T.120 applications are now supported.
>>
>> Signed-off-by: Jing Min Zhao <zhaojignmin[at]hotmail.com>
>
> Thanks, applied. I've made three small changes before applying it:
>
> - Change gkrouted_only default to 1
> - Remove #ifndef offsetof in ASN.1 parser
> - Initialize datalen to 0 in ras_help to silence an incorrect gcc
> warning. I usually don't do this, but last time Linus complained
> about new code giving (a correct) warning.
>
I'll update my local source code according to these changes.

> Thanks again.
>
Thank you! I saw 2.6.16 was released. Do you need a patch for 2.6.16?
By the way, do you mean this patch will possibly appear in the next kernel release?

Best regards,

Jing Min Zhao

kaber at trash

Mar 20, 2006, 11:13 AM

Post #20 of 23 (3382 views)
Permalink

Re: New H.323 conntrack & NAT helper module [In reply to]

Jing Min Zhao wrote:
> Thank you! I saw 2.6.16 was released. Do you need a patch for 2.6.16? By
> the way, do you mean this patch will possibly appear in the next kernel
> release?

Your patch applies cleanly against the latest kernel. I will submit
your patch for 2.6.17 tonight, I assumed thats why you sent it and
included a Signed-off-by line :)

zhaojingmin at hotmail

Mar 22, 2006, 6:26 AM

Post #21 of 23 (3353 views)
Permalink

Re: New H.323 conntrack & NAT helper module [In reply to]

Andrew Morton found some compilation errors at the linkage stage:

LD .tmp_vmlinux1
net/built-in.o(.text+0x7762d): In function `set_sig_addr':
: undefined reference to `get_h225_addr'
net/built-in.o(.text+0x776c9): In function `set_sig_addr':
: undefined reference to `get_h225_addr'
net/built-in.o(.text+0x77742): In function `set_ras_addr':
: undefined reference to `get_h225_addr'
net/built-in.o(.text+0x77d82): In function `nat_q931':
: undefined reference to `get_h225_addr'
make: *** [.tmp_vmlinux1] Error 1

The reason is function 'get_h225_addr` is incorrectly
defined as a 'static' function in ip_conntrack_helper_h323.c and
`set_sig_addr' is in ip_nat_helper_h323.c. This is interesting because
gcc normally doesn't report this obvious error.

I apologize and will release a bugfix version soon.

Best regards,

Jing Min Zhao

kaber at trash

Mar 22, 2006, 8:04 AM

Post #22 of 23 (3349 views)
Permalink

Re: New H.323 conntrack & NAT helper module [In reply to]

Jing Min Zhao wrote:
> Andrew Morton found some compilation errors at the linkage stage:
>
> LD .tmp_vmlinux1 net/built-in.o(.text+0x7762d): In function
> `set_sig_addr': : undefined reference to `get_h225_addr'
> net/built-in.o(.text+0x776c9): In function `set_sig_addr': : undefined
> reference to `get_h225_addr' net/built-in.o(.text+0x77742): In function
> `set_ras_addr': : undefined reference to `get_h225_addr'
> net/built-in.o(.text+0x77d82): In function `nat_q931': : undefined
> reference to `get_h225_addr' make: *** [.tmp_vmlinux1] Error 1
>
> The reason is function 'get_h225_addr` is incorrectly defined as a
> 'static' function in ip_conntrack_helper_h323.c and `set_sig_addr' is in
> ip_nat_helper_h323.c. This is interesting because
> gcc normally doesn't report this obvious error.
>
> I apologize and will release a bugfix version soon.

Don't worry, I already fixed it in my tree and will push it out
soon.

zhaojingmin at hotmail

Mar 22, 2006, 8:18 AM

Post #23 of 23 (3364 views)
Permalink

Re: New H.323 conntrack & NAT helper module [In reply to]

----- 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, March 22, 2006 11:04 AM
Subject: Re: New H.323 conntrack & NAT helper module

> Jing Min Zhao wrote:
>> Andrew Morton found some compilation errors at the linkage stage:
>>
>> LD .tmp_vmlinux1 net/built-in.o(.text+0x7762d): In function
>> `set_sig_addr': : undefined reference to `get_h225_addr'
>> net/built-in.o(.text+0x776c9): In function `set_sig_addr': : undefined
>> reference to `get_h225_addr' net/built-in.o(.text+0x77742): In function
>> `set_ras_addr': : undefined reference to `get_h225_addr'
>> net/built-in.o(.text+0x77d82): In function `nat_q931': : undefined
>> reference to `get_h225_addr' make: *** [.tmp_vmlinux1] Error 1
>>
>> The reason is function 'get_h225_addr` is incorrectly defined as a
>> 'static' function in ip_conntrack_helper_h323.c and `set_sig_addr' is in
>> ip_nat_helper_h323.c. This is interesting because
>> gcc normally doesn't report this obvious error.
>>
>> I apologize and will release a bugfix version soon.
>
> Don't worry, I already fixed it in my tree and will push it out
> soon.
>
Thank you very much.

Anybody who want the bugfix version (0.6) for 2.6.15 and 2.6.16
can download them from
http://sourceforge.net/project/showfiles.php?group_id=158936

This version includes Patrick's 3 changes on March 20.

Thanks again.

Jing Min Zhao

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com