H.323 conntrack patches for 2.4

Hi guys,

Just wondering what patches I need to apply to the 2.4.21 kernel tree
to get H.323 working. I have tried applying all the "pending",
"submitted" and "base" patches before the "extra" H323conntrack patch,
but I am having problems getting a bootable kernel.

Been playing with these for the last week, and keep getting unresolved
references "journal_xxx".

What is actually required? Can I just apply the H.323 patch to the
naked kernel tree or are there other dependencies?

Thanks heaps

Matt

(E-Mail Removed) (Schmuck) wrote in message news:<(E-Mail Removed). com>...
> Hi guys,
>
> Just wondering what patches I need to apply to the 2.4.21 kernel tree
> to get H.323 working. I have tried applying all the "pending",
> "submitted" and "base" patches before the "extra" H323conntrack patch,
> but I am having problems getting a bootable kernel.
>
> Been playing with these for the last week, and keep getting unresolved
> references "journal_xxx".
>
> What is actually required? Can I just apply the H.323 patch to the
> naked kernel tree or are there other dependencies?
>
> Thanks heaps
>
> Matt

And, of course, once you post to USENET the patch goes in easier
than... um.. something very very small into something very very big.


So.. now left to configure it.

Is it as simple as open 1718-1720 + 1731 and allow Established on the
return for 1024-65535? Any RTFMs greatly appreciated.

Thanks

Matt

On 14 Jul 2003 14:25:49 -0700, (E-Mail Removed) (Schmuck)
wrote:

>(E-Mail Removed) (Schmuck) wrote in message news:<(E-Mail Removed). com>...
>> Hi guys,
>>
>> Just wondering what patches I need to apply to the 2.4.21 kernel tree
>> to get H.323 working. I have tried applying all the "pending",
>> "submitted" and "base" patches before the "extra" H323conntrack patch,
>> but I am having problems getting a bootable kernel.
>>
>> Been playing with these for the last week, and keep getting unresolved
>> references "journal_xxx".
>>
>> What is actually required? Can I just apply the H.323 patch to the
>> naked kernel tree or are there other dependencies?
>>
>> Thanks heaps
>>
>> Matt
>
>And, of course, once you post to USENET the patch goes in easier
>than... um.. something very very small into something very very big.
>
>
>So.. now left to configure it.
>
>Is it as simple as open 1718-1720 + 1731 and allow Established on the
>return for 1024-65535? Any RTFMs greatly appreciated.
>
>Thanks
>
>Matt

It is amazing how the USENET makes you smarter!

That is correct. If the modules are loaded and those ports are open,
it will work. The only negative is that using those modules, the call
must be initiated from the machine behind the firewall.

For a different solution, see;

http://www.gnugk.org/index.html

BTW, 1718-1720 + 1731 are TCP ports and 1024-65535 are UDP ports.


Rich Piotrowski

To reply via E-Mail use rpiotro(at)wi(dot)rr(dot)com

Rich Piotrowski <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>. ..
> On 14 Jul 2003 14:25:49 -0700, (E-Mail Removed) (Schmuck)
> wrote:
>
> >(E-Mail Removed) (Schmuck) wrote in message news:<(E-Mail Removed). com>...
> >> Hi guys,
> >>
> >> Just wondering what patches I need to apply to the 2.4.21 kernel tree
> >> to get H.323 working. I have tried applying all the "pending",
> >> "submitted" and "base" patches before the "extra" H323conntrack patch,
> >> but I am having problems getting a bootable kernel.
> >>
> >> Been playing with these for the last week, and keep getting unresolved
> >> references "journal_xxx".
> >>
> >> What is actually required? Can I just apply the H.323 patch to the
> >> naked kernel tree or are there other dependencies?
> >>
> >> Thanks heaps
> >>
> >> Matt
> >
> >And, of course, once you post to USENET the patch goes in easier
> >than... um.. something very very small into something very very big.
> >
> >
> >So.. now left to configure it.
> >
> >Is it as simple as open 1718-1720 + 1731 and allow Established on the
> >return for 1024-65535? Any RTFMs greatly appreciated.
> >
> >Thanks
> >
> >Matt
>
> It is amazing how the USENET makes you smarter!
>
> That is correct. If the modules are loaded and those ports are open,
> it will work. The only negative is that using those modules, the call
> must be initiated from the machine behind the firewall.
>
> For a different solution, see;
>
> http://www.gnugk.org/index.html
>
> BTW, 1718-1720 + 1731 are TCP ports and 1024-65535 are UDP ports.
>
> Rich Piotrowski

Thanks Rich, but what I am actually doing... assuming I understand how
this thing works.. is a filtered one-to-one nat.

This box is a dedicated H323 firewall between the Big Bad World (BBW)
and our internal 3Com NBX IP-Phone system. Thus incoming calls pass to
our public H323 IP (dedicated), get filtered through the firewall and
dumped onto the NBX 100, which then sends it to an "automated
attendant" which allows people to hit the extention number they want
or be passed to the operator. Thus I don't need one-to-many from
outside.

I hope

Matt

Rich Piotrowski <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>. ..
> On 14 Jul 2003 14:25:49 -0700, (E-Mail Removed) (Schmuck)
> wrote:
>
> >(E-Mail Removed) (Schmuck) wrote in message news:<(E-Mail Removed). com>...
> >> Hi guys,
> >>
> >> Just wondering what patches I need to apply to the 2.4.21 kernel tree
> >> to get H.323 working. I have tried applying all the "pending",
> >> "submitted" and "base" patches before the "extra" H323conntrack patch,
> >> but I am having problems getting a bootable kernel.
> >>
> >> Been playing with these for the last week, and keep getting unresolved
> >> references "journal_xxx".
> >>
> >> What is actually required? Can I just apply the H.323 patch to the
> >> naked kernel tree or are there other dependencies?
> >>
> >> Thanks heaps
> >>
> >> Matt
> >
> >And, of course, once you post to USENET the patch goes in easier
> >than... um.. something very very small into something very very big.
> >
> >
> >So.. now left to configure it.
> >
> >Is it as simple as open 1718-1720 + 1731 and allow Established on the
> >return for 1024-65535? Any RTFMs greatly appreciated.
> >
> >Thanks
> >
> >Matt
>
> It is amazing how the USENET makes you smarter!
>
> That is correct. If the modules are loaded and those ports are open,
> it will work. The only negative is that using those modules, the call
> must be initiated from the machine behind the firewall.
>
> For a different solution, see;
>
> http://www.gnugk.org/index.html
>
> BTW, 1718-1720 + 1731 are TCP ports and 1024-65535 are UDP ports.
>
>
> Rich Piotrowski
>
> To reply via E-Mail use rpiotro(at)wi(dot)rr(dot)com

Hi (again) Rich,

I've been reading up on some of your other posts about what you can
and cannot do with H.323 firewalls and proxies.

I am really starting to dislike this protocol.

The 3com box does everything I need in terms of call routing. All I
have to do is get the packets to its interface. But their software
runs on Windows. Not my idea of a secure operating system and
definately not something I want open to the world.

So... what I think I need to do is configure a transparent bridge to
forward packets between the 3com gateway and the real world. This will
give me the external IP address on the outward facing NIC of the
Windows box and avoid NAT problems. (I gather I can't NAT the packets
because this will break the Call Setup (Q.931) negotiation.)

Will the h323 conntrack module let me do this? (I'm not a very
efficient source-code reader).

Did I mention I am really starting to dislike this protocol?

Thanks in advance for any ideas. If I get this thing working I'll FAQ
it up.

Matt