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