Re: H.323 conntrack patch

Re: H.323 conntrack patch

[Stephan Jager]

Hallo,

> > > OpenChannelAck. So... the gateway is trying to send your ,,voice'' to
> > > not mangled ip/port.
> > 
> > Thats right. I receive the "voice" stream on my linux box, which is then 
> > rejected with an icmp. But it IS going to the port from the h245 function 
> > which registered that expect_related.
> > 
> 
> Oh. Maybe that device, which you have, setup connection in slightly
> different way ;) ethereal with h323 plugin is nice ;-) But, this plugin
> is for win32 only, as I saw last time.
> On that cisco ata, I've got voice stream from box behind NAT, but no
> reply. Only one way.

my voicedevice does send voice "out" (I can hear it on the other side), 
but incoming voice isn't send to the voicedevice.

I've used ethereal with h323, so I know how the protocol goes.
I don't think the asn1 parsing is the problem, because it does find the 
correct ip/port for the voice connections in the h245 packets and it does 
register them with the expect_related function

Stephan

Re: H.323 conntrack patch

[Stephan Jager]

On Tue, 15 Jul 2003, mzieba-netfilter@mail.biuro.medianet.pl wrote:

> On Tue, Jul 15, 2003 at 03:00:10PM +0200, Stephan Jager wrote:

> Jul 14 10:45:20 nat kernel: ct_h245_help: new RTCP/RTP requested
> 192.168.2.101:->193.192.xxx.xxx:19422
> Jul 14 10:45:20 nat kernel: ct_h245_help: new RTCP/RTP requested
> 192.168.2.101:->193.192.xxx.xxx:19423
> 
> but only one h323_data_fixup for that packet. I just can't find example
> code of multiple expectation per packet to look, how it should be done. ;)

So our question: Can you have more expectations for one packet? It does 
not seem to word at least.

Stephan

H.323 conntrack patch

[Stephan Jager]

Hi,

(I'm new here, so if I	post too much/too little information, please tell 
me so)

I'm trying to use the H.323 conntrack module for my AddPac Voicefinder 
device. It seems that it works only "half" in my situation.
I've turned on debugging for the h323 modules, but I could not see 
anything suspicous in the first place.

The function: "static int h225_help" contains a 
ip_conntrack_expect_related call, which seems to work. (it registers a 
incoming call derived from the h.225 package). This one is called first in 
sequence. Those packages are going to my Voicefinder device 
(private network)without problems.

Furthermore, in the "static int h245_help" function, there is also a 
ip_conntrack_expect_related call. This one is also registered (twice), but 
connections for this conntrack are not going to my private network. (this 
is registered 2nd and 3th) It seems that netfilter does not match those 
packages, altough the logging says so.

Perhaps anybody can see at the code if there's anything obvious wrong? I 
can give you a full package-state + debug logging, but I guess thats too 
much for now.

Is there a good way to see the way a package flows? I've trying to turn on 
logging in the ip_conntrack_core, but thats way too much :)

If I've got this running, I'm going to write a H.245 RAS (gatekeeper) 
module, but I need to get this protocol running first fine.

With regards,

Stephan

------ End of forwarded message -------

H.323 conntrack patch

[Stephan Jager]

Hi,

(I'm new here, so if I  post too much/too little information, please tell 
me so)

I'm trying to use the H.323 conntrack module for my AddPac Voicefinder 
device. It seems that it works only "half" in my situation.
I've turned on debugging for the h323 modules, but I could not see 
anything suspicous in the first place.

The function: "static int h225_help" contains a 
ip_conntrack_expect_related call, which seems to work. (it registers a 
incoming call derived from the h.225 package). This one is called first in 
sequence. Those packages are going to my Voicefinder device 
(private network)without problems.

Furthermore, in the "static int h245_help" function, there is also a 
ip_conntrack_expect_related call. This one is also registered (twice), but 
connections for this conntrack are not going to my private network. (this 
is registered 2nd and 3th) It seems that netfilter does not match those 
packages, altough the logging says so.

Perhaps anybody can see at the code if there's anything obvious wrong? I 
can give you a full package-state + debug logging, but I guess thats too 
much for now.

Is there a good way to see the way a package flows? I've trying to turn on 
logging in the ip_conntrack_core, but thats way too much :)

If I've got this running, I'm going to write a H.245 RAS (gatekeeper) 
module, but I need to get this protocol running first fine.

With regards,

Stephan