[h323plus] Dropped H323 packets

[Simon Horne]

H323plus does not maintain conntrack h323.  If you are using H.460.18/19 you
do not need the NAT assistant services (ALG) of conntrack.  In fact the
problem might simply be the ALG is getting in the way. I recommend it be
turned off or you disable H.460.18/.19.  Don't have both running.

Simon

-----Original Message-----
From: h323plus-bounces at lists.packetizer.com
[mailto:h323plus-bounces at lists.packetizer.com] On Behalf Of Dennis
Muhlestein
Sent: 17 March 2011 05:58
To: h323plus at lists.packetizer.com
Cc: zhaojingmin at users.sourceforge.net
Subject: [h323plus] Dropped H323 packets

I've been battling for some time go get all my call flows working with H323.
A constantly re-appearing issue is that the kernel is dropping 
packets for part of the H323 protocol.   The offending code is in 
nf_conntrack_h323_main.c  I'll make one call, and the call will work, but
the next the kernel will drop packets.  I've worked around a number of these
issues, but this one is stumping me currently.

Call flow:
  Call a hold server through a gatekeeper (H.460.18/19 because we're NATted)
  Hold server transfers to another machine and call is completed.

Problem:
  1st call works.
  At transfer, Facility message is sent from hold server back to gatekeeper,
gatekeeper forwards to phone.  phone computer adds IP address of target
phone even though that call is placed through a gatekeeper.  Expect table
has ip addresses of target phone and gatekeeper.
  2nd call phone drops facility packet at transfer and call fails.

Kernel message (I added a couple debugging messages just to be sure)

<7>[  312.181335] nf_ct_q931: process_q931 facility.
<7>[  312.181579] nf_ct_q931: Facility
<4>[  312.181915] nf_ct_q931: packet dropped <0>[  312.182037] nf_ct_Q.931:
dropping packetIN=eth0 OUT=
MAC=38:e7:d8:7a:20:99:00:0b:86:42:1b:40:08:00:45:00:00:8b:3b:e1:40:00:3d:06:
54:c4:0a:14:91:10:0a:14:07:90:06:b8:d1:a1:23:92:8b:34:1c:c5:d6:c4:80:18:00:f
b:7b:9e:00:00:01:01:08:0a:1e:30:fe:d0:ff:ff:ff:b2:03:00:00:57:08:02:e0:b0:62
:1c:00:7e:00:49:05:26:d0:06:00:08:91:4a:00:04:00:0a:14:91
SRC=10.20.145.16 DST=10.20.7.144 LEN=139 TOS=0x00 PREC=0x00 TTL=61
ID=15329 DF PROTO=TCP SPT=1720 DPT=53665 SEQ=596806452 ACK=482727620
WINDOW=251 RES=0x00 ACK PSH URGP=0 OPT (0101080A1E30FED0FFFFFFB2)


Attached network trace
  65.37.255.198 is the hold server.
  10.20.145.16 is my test gatekeeper.
  10.20.7.144 is my test phone.

Here is what the expect table looks like after the 1st call:
235 l3proto = 2 proto=17 src=10.20.145.16 dst=10.20.7.144 sport=0
dport=5024
235 l3proto = 2 proto=17 src=10.20.145.16 dst=10.20.7.144 sport=0
dport=5025
229 l3proto = 2 proto=17 src=10.20.145.16 dst=10.20.7.144 sport=0
dport=5023
229 l3proto = 2 proto=17 src=10.20.145.16 dst=10.20.7.144 sport=0
dport=5022
229 l3proto = 2 proto=17 src=10.20.7.144 dst=10.20.145.16 sport=0
dport=6769
215 l3proto = 2 proto=6 src=10.20.145.16 dst=10.20.7.144 sport=0
dport=1720 PERMANENT
234 l3proto = 2 proto=6 src=10.20.7.144 dst=10.20.145.16 sport=0
dport=1720 PERMANENT
235 l3proto = 2 proto=17 src=10.20.145.16 dst=10.20.7.144 sport=0
dport=5027
234 l3proto = 2 proto=6 src=10.20.7.144 dst=10.20.145.12 sport=0 dport=1720
235 l3proto = 2 proto=17 src=10.20.145.16 dst=10.20.7.144 sport=0
dport=5026

The 2nd to bottom line I believe is the offending line.  Perhaps h323
conntrack doesn't know about gatekeepers, or perhaps we could do something
else to avoid this, but so far I haven't found a solution.

Any thoughts?  Bug?

Kernel 2.6.32.17.  Unfortunately, I don't have control over the target
platform and this module will be used so I'm trying to find some way around
this on the software side.  Perhaps there is a way to send a fake 
packet that will clear the entry or something.   I'm wondering if I can 
do anything on the h323 side in terms of PDUs I send that might persuade the
kernel to drop the entry from the expect table.

Thanks
Dennis