sr-users February 2011

sr-users@lists.kamailio.org

72 participants
133 discussions

Re: [SR-Users] Kamailio 1.5.4 and beyond - mhomed issue under Linux

by Sean O'Donnell

Hi all, I checked the GIT repository and noticed that there was a patch in forward.c for this issue. Looks like it was done 11/4/2010. Two questions: 1) Is there any reason that patch didn't make it into Kamailio 3.1.2 ? 2) Any reason I shouldn't apply that patck to my 1.5.4 release? Thanks, Sean O'Donnell Senior Engineer uReach Technologies, Inc. ---- On Thu, 10 Feb 2011, Sean O'Donnell (skodonnell(a)ureach.com) wrote: Hi all, I just started deploying Kamailio release 1.5.4, and I think there's an issue with how Kamailio identifies an outgoing interface when mhomed is enabled under Linux. I use Kamailio as a call distributor/proxy between a soft-switch/SBC and a voicemail platform. It runs on a CentOS 5.3 (Linux 2.6 kernel) host with two network interfaces and is configured such that it listens on both interfaces. One interface (public interface) handles traffic with the SBC, the other (private interface) handles with the VM platform. The 'mhomed' option is enabled. After upgrading from 1.5.3 to 1.5.4, I started noticing problems with UDP packets coming out of the public interface. After looking at some ngrep captures on that interface, I noticed that some packets had the source IP address of the private interface and also had Record-Route and Via headers for the private interface only - no headers for the public interface were there. Usually when I see the wrong source IP in a UDP packet, it's an issue with how routes are set up on the host. However, I had our network engineer double check them, and they seem fine (no ambiguous routes). The fact that I captured these messages on the public interface also indicates to me that the kernel is routing the message correctly. The missing Record-Route and Via for the public interface, however, lead me to believe that the proxy didn't correctly identify the outgoing interface in the first place. After looking at the ChangeLog for 1.5.4, I noticed that the some new logic was put in to improve performance when mhomed is enabled (r5971) in forward.c, and I think this is the issue. As I understand it, prior to 1.5.4, when mhomed was enabled, Kamailio determined the outgoing interface by creating a temporary UDP socket, invoking connect() on the socket with the packet destination, then checking the source IP of the socket that the kernel assigned using getsockname(). After the source address was determined, the temp socket was closed closed. As of 1.5.4, this was modified to reuse the temporary socket and just re-invoking connect() with a new destination address. The problem with the enhancement is that Linux (again, at least in the 2.6 kernels I'm using) doesn't seem to rebind a new source address to the socket when connect() is called more than once on a UDP socket. Instead, it keeps the original one, and thus the wrong interface is assumed. I wrote a small program to confirm this - basically creates a UDP socket, calls connect()/getsockname() multiple times using different destination addresses. I ran it on several 2.6 kernels, including Centos4.x and Centos5. The result was always that the source address of the socket wasn't changed after the first connect(), regardless of the destination address. The only way I could get it work as required was to first do a connect() using a zero'd out AF_UNSPEC address before doing the connect() to the remote address. I also ran it on Solaris and it worked. Go figure. I've downloaded the latest stable release (3.1.2) but I think the issue is still there, and I don't see anything in the user groups that addresses this. Any help would be appreciated. Thanks, Sean _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

13 years, 9 months

Error running kamailio 3.1.0

by Lucas Alvarez

Hi, I have compiled kamailio 3.1.0 without any error and I having this error when running kamailio: ERROR: <core> [sr_module.c:523]: ERROR: load_module: could not open module </usr/local/lib/kamailio/modules_k/sl.so>: /usr/local/lib/kamailio/modules_k/sl.so: undefined symbol: fm_malloc Any will be appreciated. Regards, Lucas

13 years, 9 months

After upgrade from openser 1.3.4 to kamailio 1.5.5 the same crash set

by Andrew O. Zhukov

[root@ tmp]# /usr/local/sbin/kamailio -V version: kamailio 1.5.5-notls (x86_64/linux) flags: STATISTICS, EXTRA_DEBUG, USE_IPV6, USE_TCP, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, PKG_SIZE 4194304 poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. svnrevision: unknown @(#) $Id: main.c 5608 2009-02-13 16:48:17Z henningw $ main.c compiled on 12:38:36 Feb 2 2011 with gcc 4.1.2 ----------------------------- Core was generated by `/usr/local/sbin/kamailio -P /var/run/openser/openser.pid -m 32 -u openser -g op'. Program terminated with signal 11, Segmentation fault. #0 0x000000000046b0e3 in fm_malloc (qm=0x72dc00, size=32) at mem/f_malloc.c:354 354 if ((*f)->size>=size) goto found; (gdb) backtrace #0 0x000000000046b0e3 in fm_malloc (qm=0x72dc00, size=32) at mem/f_malloc.c:354 #1 0x00002b30f2803087 in build_rr (_l=0x76f110, _l2=0x76fe80, user=0x7fffe9c5a500, tag=0x777a58, params=0x0, _inbound=0) at record.c:176 #2 0x00002b30f2802b7a in record_route (_m=0x76e0e0, params=0x0) at record.c:322 #3 0x00002b30f28047db in w_record_route (msg=0x76e0e0, key=0x0, bar=0x0) at rr_mod.c:212 #4 0x000000000040ed9b in do_action (a=0x73f5a0, msg=0x76e0e0) at action.c:874 #5 0x000000000040c03a in run_action_list (a=0x73f5a0, msg=0x76e0e0) at action.c:145 #6 0x000000000040e6a7 in do_action (a=0x73f810, msg=0x76e0e0) at action.c:746 #7 0x000000000040c03a in run_action_list (a=0x73e418, msg=0x76e0e0) at action.c:145 #8 0x000000000040c2a9 in run_actions (a=0x73e418, msg=0x76e0e0) at action.c:120 #9 0x000000000040c357 in run_top_route (a=0x73e418, msg=0x76e0e0) at action.c:195 #10 0x000000000043bda4 in receive_msg ( buf=0x70c980 "NOTIFY sip:XXXXXX.com SIP/2.0\r\nVia: SIP/2.0/UDP XX.XXX.101.68:5060;branch=z9hG4bK-6ee3865\r\nFrom: VTHome <sip:101650@XXXXXX.com>;tag=129d73a13db8ec7fo0\r\nTo: <sip:XXXXX.com>\r\nCall-ID: e3fd1da9-142a0a17"..., len=373, rcv_info=0x7fffe9c5ae90) at receive.c:175 #11 0x0000000000467eeb in udp_rcv_loop () at udp_server.c:449 #12 0x000000000042097b in main_loop () at main.c:774 #13 0x00000000004228b0 in main (argc=11, argv=0x7fffe9c5b118) at main.c:1321 (gdb) print size $1 = 32 (gdb) quit -------------------------------------------- Core was generated by `/usr/local/sbin/kamailio -P /var/run/openser/openser.pid -m 32 -u openser -g op'. Program terminated with signal 11, Segmentation fault. #0 0x000000000046bf7b in fm_status (qm=0x72dc00) at mem/f_malloc.c:609 609 size+=f->size,f=f->u.nxt_free,i++,j++){ (gdb) backtrace #0 0x000000000046bf7b in fm_status (qm=0x72dc00) at mem/f_malloc.c:609 #1 0x000000000041feb3 in sig_usr (signo=15) at main.c:563 #2 <signal handler called> #3 0x00000039d8cd4a51 in __recvfrom_nocancel () from /lib64/libc.so.6 #4 0x0000000000467bf4 in udp_rcv_loop () at udp_server.c:408 #5 0x000000000042097b in main_loop () at main.c:774 #6 0x00000000004228b0 in main (argc=11, argv=0x7fffe9c5b118) at main.c:1321 (gdb) print i $1 = 402 (gdb) print j $2 = 1 (gdb) print size $3 = 7234295468789601279 (gdb) print f $4 = (struct fm_frag *) 0x3738656435393838 (gdb) print f->size Cannot access memory at address 0x3738656435393838 ------------------------------------------------------------------- Andrew O. Zhukov

13 years, 9 months

pdb module timeouts

by Thomas Baumann

Hello, I am using the PDB module and server components for number portability. 2 instances of PDB Server runs on (10.12.19.51/10001/10002), Kamailio on (10.12.19.21). With a small amount of traffic (-cmax 150 -cps 10 -callduration 3), where are timeouts: WARNING: pdb [pdb.c:260]: exceeded timeout while waiting for response. One requested number was 307111094, where the module prints out a timeout. The funny part is, that I can see the responses at least arriving at the 10.12.19.21 interface on time. Request send: 0,200855 s Answer received: 0,201027 s That are 0,172 ms and far away from a timeout. What could be the reason ? regards, Thomas ps. A small change on the server part was done: handle 4 digit carrier codes. level3_logs: Feb 9 17:19:42 node2 /openser/sbin/kamailio[21200]: DEBUG: pdb [pdb.c:201]: querying '307111094'... Feb 9 17:19:42 node2 /openser/sbin/kamailio[21200]: WARNING: pdb [pdb.c:260]: exceeded timeout while waiting for response. ___________________________________________________________ Schon gehört? WEB.DE hat einen genialen Phishing-Filter in die Toolbar eingebaut! http://produkte.web.de/go/toolbar

13 years, 9 months

Change transport=tls within Contact Header

by Bernhard Suttner

Hi, is there a function to change the transport field within the Contact Header? t_relay does relay it to the UDP port of the PBX but the transport within the Contact Header is still set to TLS. Later, the PBX does try to establish a TLS connection. The idea is now, that kamailio does set the transport of the Contact Header to UDP. Another possible way would to be, that I use the re.subst method but maybe there is a special function for that. Thanks in advance. Best regards, Bernhard

13 years, 9 months

NAT, TLS and location table

by Bernhard Suttner

Hi, I am using TLS and recognize the following problem: The TLS connection are build up successfully but the natping (natping_interval = 10) does not send small dummy packets to the phones. The phones are behind a firewall with NAT. Registered phones with NAT but UDP do work correctly. They are getting the natping every 10 seconds. After 120 seconds (should be the tcp_connection_timeout) kamailio does send a FIN to the TLS phone to close the TLS connection. Should I increase the tcp_connection_timeout to a value bigger than the registration timeout? I thought I do not need that, because of the natping_interval. Is it maybe better to use a SIP-Options Ping instead of the small dummy packets? I would prefer the dummy packets because they are much smaller. BTW: Kamailio 3.1.1 and snom360 with latest v8 firmware. Thanks in advance! Best regards, Bernhard

13 years, 9 months

handle_new_connect ... Too many open files

by Efelin Novak

Hi, today during two hours kamailio made 2G of a syslog messages. This message was repeated for 10 000 000 times. /sbin/kamailio[24272]: ERROR: <core> [tcp_main.c:3959]: WARNING: handle_new_connect: error while accepting connection(24): Too many open files It was preceded by following error. /sbin/kamailio[24265]: ERROR: <core> [tcp_read.c:269]: error reading: Connection reset by peer (104) /sbin/kamailio[24265]: ERROR: <core> [tcp_read.c:882]: ERROR: tcp_read_req: error reading Finally it stopped without any given reason. I'm using kamailio 3.1.0 (i386/linux) 1e204f, callcontrol 2.0.11 and clustered mysql. Was this some kind of attack, bug, error, misconfiguration or what? Thank for answer, Efelin

13 years, 9 months

TLS Support

by Bernhard Suttner

Hi, how could I compile the TLS module and only the TLS module - not the other sources. BTW: The documentation within the http://www.kamailio.org/docs/tls.html is not up-to-date. Thanks in advance. Best regards, Bernhard

13 years, 9 months

Kamailio as a sip client

by Amit Nepal

Hi, Is it possible to have kamailio register to a different proxy and route calls through that proxy ? -- Thank You Amit Nepal Systems Administrator Phoenix Internet Phone: 602-385-0731 602-234-0917#112 http://www.phoenixinternet.net

13 years, 9 months

Kamailio 1.5.4 and beyond - mhomed issue under Linux

by Sean O'Donnell

Hi all, I just started deploying Kamailio release 1.5.4, and I think there's an issue with how Kamailio identifies an outgoing interface when mhomed is enabled under Linux. I use Kamailio as a call distributor/proxy between a soft-switch/SBC and a voicemail platform. It runs on a CentOS 5.3 (Linux 2.6 kernel) host with two network interfaces and is configured such that it listens on both interfaces. One interface (public interface) handles traffic with the SBC, the other (private interface) handles with the VM platform. The 'mhomed' option is enabled. After upgrading from 1.5.3 to 1.5.4, I started noticing problems with UDP packets coming out of the public interface. After looking at some ngrep captures on that interface, I noticed that some packets had the source IP address of the private interface and also had Record-Route and Via headers for the private interface only - no headers for the public interface were there. Usually when I see the wrong source IP in a UDP packet, it's an issue with how routes are set up on the host. However, I had our network engineer double check them, and they seem fine (no ambiguous routes). The fact that I captured these messages on the public interface also indicates to me that the kernel is routing the message correctly. The missing Record-Route and Via for the public interface, however, lead me to believe that the proxy didn't correctly identify the outgoing interface in the first place. After looking at the ChangeLog for 1.5.4, I noticed that the some new logic was put in to improve performance when mhomed is enabled (r5971) in forward.c, and I think this is the issue. As I understand it, prior to 1.5.4, when mhomed was enabled, Kamailio determined the outgoing interface by creating a temporary UDP socket, invoking connect() on the socket with the packet destination, then checking the source IP of the socket that the kernel assigned using getsockname(). After the source address was determined, the temp socket was closed closed. As of 1.5.4, this was modified to reuse the temporary socket and just re-invoking connect() with a new destination address. The problem with the enhancement is that Linux (again, at least in the 2.6 kernels I'm using) doesn't seem to rebind a new source address to the socket when connect() is called more than once on a UDP socket. Instead, it keeps the original one, and thus the wrong interface is assumed. I wrote a small program to confirm this - basically creates a UDP socket, calls connect()/getsockname() multiple times using different destination addresses. I ran it on several 2.6 kernels, including Centos4.x and Centos5. The result was always that the source address of the socket wasn't changed after the first connect(), regardless of the destination address. The only way I could get it work as required was to first do a connect() using a zero'd out AF_UNSPEC address before doing the connect() to the remote address. I also ran it on Solaris and it worked. Go figure. I've downloaded the latest stable release (3.1.2) but I think the issue is still there, and I don't see anything in the user groups that addresses this. Any help would be appreciated. Thanks, Sean

13 years, 9 months

← Newer
1
...
7
8
9
10
11
12
13
14
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users February 2011