Patch for H323 connection tracking for kernel 2.6.14 and Panic with SIP tracking

Patch for H323 connection tracking for kernel 2.6.14 and Panic with SIP tracking

[Moises Silva]

I was patching my 2.6.14 kernel for SIP and H323 connection tracking
support, and got some errors of patch-o-matic h323 patches (i guess is
normal since the version supported is 2.6.12 ), i would like some one
with enough experience check the patch i made and tell me if it ok,
since is compiling just fine, and it makes sense to me, but i could be
wrong.

Patch to be applied in the kernel directory directly, something like
patch -p1 < blah...

http://galileo.ivsol.net/h323-conntrack-nat-kernel-2.6.14.patch

and a patch for patch-o-matic sources

http://galileo.ivsol.net/patch-o-matic-ng-20051230-h323.patch


Additionally im having kernel panics with SIP conntrack extension. I
have it as kernel module (ko). I still does not copy the core dump,
but says something about "interrupt error, not syncing" or something
like that. I will try to compile it inside the kernel to see if it
still panics ( please some one could tell me if this makes any
relevant difference?? )


Thanks in advance

- Moises Silva < moy at ivsol dot net >
--
"Su nombre es GNU/Linux, no solamente Linux, mas info en http://www.gnu.org"

Re: Patch for H323 connection tracking for kernel 2.6.14 and Panic with SIP tracking

[Moises Silva]

still getting kernel panic, copy the whole thing is a time consuming
task, for now doing nothing, but i have downgraded the kernel to
2.6.13 and at least it does not kernel panics. Some one has a patch
for sip connection tracking for kernel-2.6.14??

On 12/31/05, Moises Silva <moises.silva@gmail.com> wrote:
> I was patching my 2.6.14 kernel for SIP and H323 connection tracking
> support, and got some errors of patch-o-matic h323 patches (i guess is
> normal since the version supported is 2.6.12 ), i would like some one
> with enough experience check the patch i made and tell me if it ok,
> since is compiling just fine, and it makes sense to me, but i could be
> wrong.
>
> Patch to be applied in the kernel directory directly, something like
> patch -p1 < blah...
>
> http://galileo.ivsol.net/h323-conntrack-nat-kernel-2.6.14.patch
>
> and a patch for patch-o-matic sources
>
> http://galileo.ivsol.net/patch-o-matic-ng-20051230-h323.patch
>
>
> Additionally im having kernel panics with SIP conntrack extension. I
> have it as kernel module (ko). I still does not copy the core dump,
> but says something about "interrupt error, not syncing" or something
> like that. I will try to compile it inside the kernel to see if it
> still panics ( please some one could tell me if this makes any
> relevant difference?? )
>
>
> Thanks in advance
>
> - Moises Silva < moy at ivsol dot net >
> --
> "Su nombre es GNU/Linux, no solamente Linux, mas info en http://www.gnu.org"
>


--
"Su nombre es GNU/Linux, no solamente Linux, mas info en http://www.gnu.org"

Re: Patch for H323 connection tracking for kernel 2.6.14 and Panic with SIP tracking

[Patrick McHardy]

Moises Silva wrote:
> still getting kernel panic, copy the whole thing is a time consuming
> task, for now doing nothing, but i have downgraded the kernel to
> 2.6.13 and at least it does not kernel panics. Some one has a patch
> for sip connection tracking for kernel-2.6.14??

Most likely you need to change

         ip_ct_refresh_acct(ct, ctinfo, NULL, sip_timeout * HZ);

to

         ip_ct_refresh(ct, *pskb, sip_timeout * HZ);

in net/ipv4/netfilter/ip_conntrack_sip.c. If that doesn't help
please post the entire oops.

Patch for H323 connection tracking for kernel 2.6.14 and Panic with SIP tracking

[Moises Silva]

[-- Attachment #1: Type: text/plain, Size: 2128 bytes --]

I have already done the changes to use ip_ct_refresh() and still
panics. But as time passes and i read more stuff, im more confused. I
found this patch

http://people.ecsc.co.uk/~matt/patches/kernel/2.6.14/05-netfilter-sip-conntrack-nat.patch

however i didnt check for differences between that patch and the one
provided by patch-o-matic, so i made a copy of my previous kernel but
with this other patch, and seems to work. I made a diff -Nur between
both kernels and didnt find anything particular about the sip
conntrack. Then i backed again to the buggy kernel and now is giving
the next errors when i try to modprobe ip_nat_sip:

Jan  3 13:17:17 [kernel] kobject_register failed for ip_conntrack_sip (-17)
Jan  3 13:17:17 [kernel] ------------[ cut here ]------------
Jan  3 13:17:17 [kernel] kernel BUG at net/ipv4/netfilter/ip_nat_sip.c:241!
Jan  3 13:17:17 [kernel] invalid operand: 0000 [#1]

Im attaching a copy of the kernel panic it gives me the first time.
Notice that i have seen 2 different kernel panics, one when my box is
booting up, and other when I load the ip_nat_sip module. The first
kernel panic is the one im attaching a copy of, but the second one i
havent had the time of copyingit, theres a painless way of copying the
dump when panics??

Any help would be appreciated.

On 1/3/06, Patrick McHardy <kaber@trash.net> wrote:
> Moises Silva wrote:
> > still getting kernel panic, copy the whole thing is a time consuming
> > task, for now doing nothing, but i have downgraded the kernel to
> > 2.6.13 and at least it does not kernel panics. Some one has a patch
> > for sip connection tracking for kernel-2.6.14??
>
> Most likely you need to change
>
>          ip_ct_refresh_acct(ct, ctinfo, NULL, sip_timeout * HZ);
>
> to
>
>          ip_ct_refresh(ct, *pskb, sip_timeout * HZ);
>
> in net/ipv4/netfilter/ip_conntrack_sip.c. If that doesn't help
> please post the entire oops.
>


--
"Su nombre es GNU/Linux, no solamente Linux, mas info en http://www.gnu.org"




--
"Su nombre es GNU/Linux, no solamente Linux, mas info en http://www.gnu.org"

[-- Attachment #2: panic --]
[-- Type: application/octet-stream, Size: 1061 bytes --]

[<c0482c25>] nf_hook_slow+0x75/0x130
[<c043df50>] ip_finish_output2+0x0/0x10
[<c043bab0>] ip_output+0x270/0x2a0
[<c043df50>] ip_finish_output+0x0/0x10
[<c043d97e>] ip_push_pending_frames+0x30e/0x4b0
[<c043df20>] dst_output+0x0/0x30
[<c0458abe>] udp_push_pending_frames+0x15e/0x2a0
[<c0458fb8>] udp_sendmsg+0x378/0x700
[<c045b487>] arp_bind_neighbor+0x67/0xa0
[<c0460c1a>] inet_sendmsg+0x4a/0x60
[<c0410955>] sock_sendmsg+0xe5/0x100
[<c0436a7f>] ip_route_output_flow+0x1f/0x60
[<c0132e00>] autoremove_wait_function+0x0/0x60
[<c0410488>] move_addr_to_kernel+0x48/0x70
[<c0411fc3>] sys_sendto+0xe3/0x100
[<de8ed3ab>] ct_receive+0x2ab/0x7c0[zaptel]
[<c01522d6>] __handle_mm_fault+0xf6/0x170
[<c02ac9b6>] copy_from_user+0x46/0x90
[<c04128f5>] sys_socketcall+0x1b5/0x280
[<c0103155>] syscall_call+0x7/0xb
code: 00 00 89 5e 14 c7 44 24 08 08 00 00 00 8b 6c 24 0c 85 ed 74 3e 83 ff 03 19
c0 83 e0 f8 ff 44 06 30 89 c3 86 54 24 10 8b 7c 1e 30 <8b> 42 20 0f b7 50 02 89
d0 c1 ea 08 c1 e0 08 09 b0 0f b7 c0 03
<0> kernel panic - not syncing: fatal exception in interrupt

Re: Patch for H323 connection tracking for kernel 2.6.14 and Panic with SIP tracking

[Victor Julien]

Patrick McHardy wrote:
> Moises Silva wrote:
> 
>> still getting kernel panic, copy the whole thing is a time consuming
>> task, for now doing nothing, but i have downgraded the kernel to
>> 2.6.13 and at least it does not kernel panics. Some one has a patch
>> for sip connection tracking for kernel-2.6.14??
> 
> 
> Most likely you need to change
> 
>         ip_ct_refresh_acct(ct, ctinfo, NULL, sip_timeout * HZ);
> 
> to
> 
>         ip_ct_refresh(ct, *pskb, sip_timeout * HZ);
> 
> in net/ipv4/netfilter/ip_conntrack_sip.c. If that doesn't help
> please post the entire oops.
> 

This fix works for me!

Regards,
Victor

Re: Patch for H323 connection tracking for kernel 2.6.14 and Panic with SIP tracking

[Moises Silva]

hum, i guess mine is a different problem. The thing that seems to be
causing panic is the coexistence of ppp_asyc nad ip_nat_sip (or the
consequent ip_conntrack_sip). Im preparing an explanation of the tests
i made, i will post it here in a while. Hopefully some developer will
be able to know whats the problem.

Regards

On 1/5/06, Victor Julien <victor@nk.nl> wrote:
> Moises Silva wrote:
> > Victor: Did you were getting kernel panics as well?
> >
>
> Yes, as soon as i loaded the ip_nat_sip module (which in also loaded the
> ip_conntrack_sip module) it caused a kernel panic when there was SIP
> traffic. Now it seems to work fine. I had a few conversations, no panics
> yet :-)
>
> Regards,
> Victor
>
>


--
"Su nombre es GNU/Linux, no solamente Linux, mas info en http://www.gnu.org"

Re: Patch for H323 connection tracking for kernel 2.6.14 and Panic with SIP tracking

[Victor Julien]

Victor Julien wrote:
> Patrick McHardy wrote:
> 
>> Moises Silva wrote:
>>
>>> still getting kernel panic, copy the whole thing is a time consuming
>>> task, for now doing nothing, but i have downgraded the kernel to
>>> 2.6.13 and at least it does not kernel panics. Some one has a patch
>>> for sip connection tracking for kernel-2.6.14??
>>
>>
>>
>> Most likely you need to change
>>
>>         ip_ct_refresh_acct(ct, ctinfo, NULL, sip_timeout * HZ);
>>
>> to
>>
>>         ip_ct_refresh(ct, *pskb, sip_timeout * HZ);
>>
>> in net/ipv4/netfilter/ip_conntrack_sip.c. If that doesn't help
>> please post the entire oops.
>>
> 
> This fix works for me!
> 
> Regards,
> Victor
> 
> 

Hmmm, while it still hasn't crashed on me, i can't get it to operate
either. I am using 2.6.15 + pom 20060101 + the above fix. I am trying to 
get the following setup working:

softphone (lan) --- sip proxy on gateway --- sip server (@isp)

I have rules to allow port 5060/udp. I expected that by loading
ip_conntrack_sip this rule, together with accepting
all RELATED traffic, sip conversations would work.

If i call a number, i see the following entry appear in
/proc/net/ip_conntrack_expect:
176 proto=17 src=217.66.118.164 dst=80.126.xx.xx sport=0 dport=7071
176 proto=17 src=192.168.1.1 dst=192.168.1.2 sport=0 dport=8000

(lan client 192.168.1.2, firewall has 192.168.1.1 and 80.126.xx.xx, sip 
server is 217.66.118.164).

But the connection does not work. I have added the following rule to all 
chains in all tables (mangle, nat, filter):
iptables -t <table> -I <chain> 1 -m helper --helper sip
to see if the sip match ever gets reached, but all counters remain on 0 
all the time.

If i do the same for ftp, i can see the counters increase.

Does anyone have an idea what is going wrong?

Regards,
Victor

Re: Patch for H323 connection tracking for kernel 2.6.14 and Panic with SIP tracking

[Patrick McHardy]

Victor Julien wrote:
> Hmmm, while it still hasn't crashed on me, i can't get it to operate
> either. I am using 2.6.15 + pom 20060101 + the above fix. I am trying to 
> get the following setup working:
> 
> softphone (lan) --- sip proxy on gateway --- sip server (@isp)
> 
> I have rules to allow port 5060/udp. I expected that by loading
> ip_conntrack_sip this rule, together with accepting
> all RELATED traffic, sip conversations would work.
> 
> If i call a number, i see the following entry appear in
> /proc/net/ip_conntrack_expect:
> 176 proto=17 src=217.66.118.164 dst=80.126.xx.xx sport=0 dport=7071
> 176 proto=17 src=192.168.1.1 dst=192.168.1.2 sport=0 dport=8000
> 
> (lan client 192.168.1.2, firewall has 192.168.1.1 and 80.126.xx.xx, sip 
> server is 217.66.118.164).
> 
> But the connection does not work. I have added the following rule to all 
> chains in all tables (mangle, nat, filter):
> iptables -t <table> -I <chain> 1 -m helper --helper sip
> to see if the sip match ever gets reached, but all counters remain on 0 
> all the time.
> 
> If i do the same for ftp, i can see the counters increase.
> 
> Does anyone have an idea what is going wrong?

Try to find out if the expectations ports are correct by logging
the incoming traffic or using tcpdump.

Re: Patch for H323 connection tracking for kernel 2.6.14 and Panic with SIP tracking

[Victor Julien]

> Try to find out if the expectations ports are correct by logging
> the incoming traffic or using tcpdump.
> 

When making a call:

# cat /proc/net/ip_conntrack_expect
174 proto=17 src=217.66.118.164 dst=80.126.43.45 sport=0 dport=7071
174 proto=17 src=192.168.1.1 dst=192.168.1.2 sport=0 dport=8000

tcpdump:
13:05:46.220869 IP 192.168.1.2.8000 > 192.168.1.1.7072: UDP, length: 172

syslog:
Jan  6 13:05:46 sanctorium kernel: vrmr: REJECT reject-in IN=eth0 OUT= 
MAC=aa:00:04:00:0a:04:00:90:27:57:31:29:08:00 SRC=192.168.1.2 
DST=192.168.1.1 LEN=200 TOS=0x00 PREC=0x00 TTL=64 ID=401 DF PROTO=UDP 
SPT=8000 DPT=7072 LEN=180

REJECT is the default policy for lan to firewall traffic.

Can it be that the expectation direction is wrong?
dropped traffic is src 192.168.1.2:8000 to dst 192.168.1.1:7072
expect is src 192.168.1.1 to dst 192.168.1.2:8000

On the other hand, the dropped traffic looks the same as the 
expectation, only in the opposite direction...

Regards,
Victor

Re: Patch for H323 connection tracking for kernel 2.6.14 and Panic with SIP tracking

[Patrick McHardy]

Victor Julien wrote:
>> Try to find out if the expectations ports are correct by logging
>> the incoming traffic or using tcpdump.
>>
> 
> When making a call:
> 
> # cat /proc/net/ip_conntrack_expect
> 174 proto=17 src=217.66.118.164 dst=80.126.43.45 sport=0 dport=7071
> 174 proto=17 src=192.168.1.1 dst=192.168.1.2 sport=0 dport=8000
> 
> tcpdump:
> 13:05:46.220869 IP 192.168.1.2.8000 > 192.168.1.1.7072: UDP, length: 172
> 
> syslog:
> Jan  6 13:05:46 sanctorium kernel: vrmr: REJECT reject-in IN=eth0 OUT= 
> MAC=aa:00:04:00:0a:04:00:90:27:57:31:29:08:00 SRC=192.168.1.2 
> DST=192.168.1.1 LEN=200 TOS=0x00 PREC=0x00 TTL=64 ID=401 DF PROTO=UDP 
> SPT=8000 DPT=7072 LEN=180
> 
> REJECT is the default policy for lan to firewall traffic.
> 
> Can it be that the expectation direction is wrong?
> dropped traffic is src 192.168.1.2:8000 to dst 192.168.1.1:7072
> expect is src 192.168.1.1 to dst 192.168.1.2:8000

Possible. In which direction (relative to registration) does
the call go?

Re: Patch for H323 connection tracking for kernel 2.6.14 and Panic with SIP tracking

[Victor Julien]

Patrick McHardy wrote:
> Victor Julien wrote:
> 
>>> Try to find out if the expectations ports are correct by logging
>>> the incoming traffic or using tcpdump.
>>>
>>
>> When making a call:
>>
>> # cat /proc/net/ip_conntrack_expect
>> 174 proto=17 src=217.66.118.164 dst=80.126.43.45 sport=0 dport=7071
>> 174 proto=17 src=192.168.1.1 dst=192.168.1.2 sport=0 dport=8000
>>
>> tcpdump:
>> 13:05:46.220869 IP 192.168.1.2.8000 > 192.168.1.1.7072: UDP, length: 172
>>
>> syslog:
>> Jan  6 13:05:46 sanctorium kernel: vrmr: REJECT reject-in IN=eth0 OUT= 
>> MAC=aa:00:04:00:0a:04:00:90:27:57:31:29:08:00 SRC=192.168.1.2 
>> DST=192.168.1.1 LEN=200 TOS=0x00 PREC=0x00 TTL=64 ID=401 DF PROTO=UDP 
>> SPT=8000 DPT=7072 LEN=180
>>
>> REJECT is the default policy for lan to firewall traffic.
>>
>> Can it be that the expectation direction is wrong?
>> dropped traffic is src 192.168.1.2:8000 to dst 192.168.1.1:7072
>> expect is src 192.168.1.1 to dst 192.168.1.2:8000
> 
> 
> Possible. In which direction (relative to registration) does
> the call go?
> 

 From 192.168.1.2 to 217.66.118.164 via proxy 192.168.1.1. The 
registration is in the same direction. The expectation seems to be in 
the opposite direction.

Regards,
Victor

sip connection tracking & expectations

[Victor Julien]

Hello people,

I have retried getting sip working. I have tried to create manual 
expectations, to see which one works, since the default onces created by 
the sip conntrack module in pom don't work for me.

For simplicity (only one expectation) i have tried a nat setup:

lan client ---- nat gateway ---- sip server

lan client has: 192.168.1.2
nat gateway: 192.168.1.1 and 80.126.43.45
sip server: 217.66.118.164

Kernel 2.6.15, pom 20060101 with ip_ct_refresh fix.

ip_conntrack_sip and ip_nat_sip loaded, all RELATED is accepted.


The client (192.168.1.2) registers at the sip server sip.xs4all.nl 
(217.66.118.164).

When i call my voicemail 1233@sip.xs4all.nl i see the following 
expectations getting generated automaticly:
180 proto=17 src=217.66.118.164 dst=80.126.43.45 sport=0 dport=7078
180 proto=17 src=217.66.118.164 dst=80.126.43.45 sport=0 dport=10500

After the call was initiated, i started to see REJECTs on the lan side 
of my firewall like this:
192.168.1.2:7078 -> 217.66.118.146:34106
(note the different ipaddress, this is not a typo)

Then i manually added this expectation using the conntrack tool:
180 proto=17 src=192.168.1.2 dst=217.66.118.146 sport=7078 dport=34106

And the REJECT messages stopped, and i suddenly heard the audio!

Next to the REJECTs above, i saw in a low frequency (about 1 for 30 of 
above) the following REJECTs:
192.168.1.2:7079 -> 217.66.118.146:34107

So i added that expectation as well:
180 proto=17 src=192.168.1.2 dst=217.66.118.146 sport=7079 dport=34107

Now no REJECTs were showing at the firewall anymore.

When all is working i see the following connections in 
/proc/net/ip_conntrack

udp      17 3562 src=192.168.1.2 dst=217.66.118.164 sport=5060 
dport=5060 packets=8 bytes=4714 src=217.66.118.164 dst=80.126.43.45 
sport=5060 dport=5060 packets=12 bytes=4003 [ASSURED] mark=0 use=3

udp      17 29 src=192.168.1.2 dst=217.66.118.146 sport=7079 dport=34107 
packets=7 bytes=1036 [UNREPLIED] src=217.66.118.146 dst=80.126.43.45 
sport=34107 dport=7079 packets=0 bytes=0 mark=0 use=1

udp      17 179 src=192.168.1.2 dst=217.66.118.146 sport=7078 
dport=334106 packets=2283 bytes=455820 src=217.66.118.146 
dst=80.126.43.45 sport=34106 dport=7078 packets=2278 bytes=455600 
[ASSURED] mark=0 use=1


If you need more info, let me know.

Regards,
Victor