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
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@lists.packetizer.com [mailto:h323plus-bounces@lists.packetizer.com] On Behalf Of Dennis Muhlestein Sent: 17 March 2011 05:58 To: h323plus@lists.packetizer.com Cc: zhaojingmin@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
On 03/16/2011 03:27 PM, Simon Horne wrote:
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.
Yes, you're correct.
I know conntrack is maintained in the kernel, just wondering if anyone had ever seen anything like this and knew of a workaround. H460.18/19 is designed to get around this and conntrack is getting in the way. I can't remove the module unfortunately.
The ironic thing is, the module, which is clearly meant to help h323 applications, is at this point causing us nothing but problems.
-Dennis
On 03/16/2011 03:37 PM, Dennis Muhlestein wrote:
On 03/16/2011 03:27 PM, Simon Horne wrote:
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.
Oh yeah, we use H.460.18/19 to talk with our gatekeeper and it does quite nicely the job of getting around NAT problems. (The conntrack module does not do this unless it is running on a public facing ip address, which it isn't.) So that is why we're using H.460. but it isn't H.460 in combination with conntrack that is causing the issue. Conntrack causes us dropped packet issues without it. (In that case, it drops other packets in other situations.)
participants (2)
-
Dennis Muhlestein -
Simon Horne