[h323plus] Dropped H323 packets

[Dennis Muhlestein]

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:fb: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



-------------- next part --------------
A non-text attachment was scrubbed...
Name: drops.pcap
Type: application/cap
Size: 847 bytes
Desc: not available
URL: <https://lists.packetizer.com/pipermail/h323plus/attachments/20110316/791007ee/attachment-0001.bin>