Hi Tom,
THanks for reposnding to my question, and of course thanks for Shorewall.
>>Sent: Thursday, November 26, 2015 at 11:40 AM
>>From: "Tom Eastep" <[email protected]>
>>To: [email protected]
>>Subject: Re: [Shorewall-users] Traffic Shaping VOIP / nf_ct_Q.931: dropping packet: cannot process Q.931 message
>>From: "Tom Eastep" <[email protected]>
>>To: [email protected]
>>Subject: Re: [Shorewall-users] Traffic Shaping VOIP / nf_ct_Q.931: dropping packet: cannot process Q.931 message
>>On 11/25/2015 12:42 PM, Slick Rick wrote:
>>> kernel: [1595740.759044] nf_ct_Q.931: dropping packet: cannot process
>>> Q.931 message IN= OUT= SRC="" DST=192.168.6.96 LEN=190
>>> TOS=0x00 PREC=0x00 TTL=97 ID=46108 PROTO=TCP SPT=1720 DPT=4254
>>> SEQ=2035679657 ACK=2378695115 WINDOW=4369 RES=0x00 ACK FIN URGP=0
>>
>>I'm doubtful that the message has anything to do with traffic shaping.
>>It is being issued out of the nf_ct_Q.931 module which is the Q.931
>>conntrack helper.
>Are there any other symptoms besides the kernel message? I notice that
>the FIN flag is on in the packet, which indicates that the TCP
>connection is being terminated when the message is generated.
>>> kernel: [1595740.759044] nf_ct_Q.931: dropping packet: cannot process
>>> Q.931 message IN= OUT= SRC="" DST=192.168.6.96 LEN=190
>>> TOS=0x00 PREC=0x00 TTL=97 ID=46108 PROTO=TCP SPT=1720 DPT=4254
>>> SEQ=2035679657 ACK=2378695115 WINDOW=4369 RES=0x00 ACK FIN URGP=0
>>
>>I'm doubtful that the message has anything to do with traffic shaping.
>>It is being issued out of the nf_ct_Q.931 module which is the Q.931
>>conntrack helper.
>Are there any other symptoms besides the kernel message? I notice that
>the FIN flag is on in the packet, which indicates that the TCP
>connection is being terminated when the message is generated.
I guess because this was related to my VOIP setup I incorreclty lumped it in with Shorewall taffic shaping. I did more testing today and looked for additional symptoms, however I could not find anything beyond the kernal error from my original message. To be honest, I'm not sure of where else to look besides the logging I set up in Shorewall for this this traffic and the kernel messages themselves.
It occured to me that since my VOIP traffic is over a VPN where the two endpoints are not blocked on by the firewall on either end from communicating with each other that this module was not really needed for me. I tested removing the H232 module by commenting out that helper line in the conntrack file:
?if __H323_HELPER
CT:helper:RAS:PO - - udp 1719
#CT:helper:Q.931:PO - - tcp 1720
?endif
CT:helper:RAS:PO - - udp 1719
#CT:helper:Q.931:PO - - tcp 1720
?endif
After restarting Shorewall it seems this has resolved the issue for me, and from what I understand based on my setup and the purpose of this module I can safely live without it.
Interestingly, some calls would work just fine and others would exhibit this problem so I wonder if this is just a compatibility issue between my VOIP hardware/software and the module itself.
Rick
------------------------------------------------------------------------------ Go from Idea to Many App Stores Faster with Intel(R) XDK Give your users amazing mobile app experiences with Intel(R) XDK. Use one codebase in this all-in-one HTML5 development environment. Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs. http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140
_______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
