sr-dev November 2011

sr-dev@lists.kamailio.org

31 participants
340 discussions

by Jijo

Hi All, Kamailio is resetting when we do TLS renegotiation dos attack using the tool available at http://www.thc.org/thc-ssl-dos/. Anybody looked at this issue? How we could resolve it. Any idea? The core generated for 3 pid's as below Pid 1: Core was generated by `/usr/sbin/kamailio -u swrun -g sw -m 120 -f /etc/kamailio/kamailio.cfg'. Program terminated with signal 11, Segmentation fault. #0 atomic_inc_int () at atomic/atomic_x86.h:225 (gdb) bt #0 atomic_inc_int () at atomic/atomic_x86.h:225 #1 cfg_update_local () at cfg/cfg_struct.h:228 #2 timer_main () at timer.c:994 #3 0x080b0579 in main_loop () at main.c:1632 #4 0x080b1be4 in main (argc=9, argv=0xbfd61e54) at main.c:2446 Pid 2: Core was generated by `/usr/sbin/kamailio -u swrun -g sw -m 120 -f /etc/kamailio/kamailio.cfg'. Program terminated with signal 11, Segmentation fault. #0 0x0819bfe8 in qm_insert_free (qm=0xaf6c5000, p=0xb05eec30, file=0xb6fb4140 "tls: tls_init.c", func=0xb6fb4ce0 "ser_free", line=296) at mem/q_malloc.c:184 184 if (frag->size <= f->size) break; (gdb) bt #0 0x0819bfe8 in qm_insert_free (qm=0xaf6c5000, p=0xb05eec30, file=0xb6fb4140 "tls: tls_init.c", func=0xb6fb4ce0 "ser_free", line=296) at mem/q_malloc.c:184 #1 qm_free (qm=0xaf6c5000, p=0xb05eec30, file=0xb6fb4140 "tls: tls_init.c", func=0xb6fb4ce0 "ser_free", line=296) at mem/q_malloc.c:518 #2 0xb6f95404 in ser_free (ptr=0xb05eec30) at tls_init.c:296 #3 0xb732e9ba in CRYPTO_free (str=0xb05eec30) at mem.c:391 #4 0xb7330bee in int_new_ex_data (class_index=5, obj=0xbfd414f4, ad=0xbfd41574) at ex_data.c:440 #5 0xb7330443 in CRYPTO_new_ex_data (class_index=5, obj=0xbfd414f4, ad=0xbfd41574) at ex_data.c:575 #6 0xb73dfde3 in X509_STORE_CTX_init (ctx=0xbfd414f4, store=0xafd8b3d0, x509=0xafe08ff0, chain=0x0) at x509_vfy.c:2114 #7 0xb74b0f31 in ssl3_output_cert_chain (s=0xb0553a10, x=0xafe08ff0) at s3_both.c:349 #8 0xb74a4728 in ssl3_send_server_certificate (s=0xb0553a10) at s3_srvr.c:3034 #9 0xb74a5879 in ssl3_accept (s=0xb0553a10) at s3_srvr.c:353 #10 0xb74afa8f in ssl3_read_bytes (s=0xb0553a10, type=23, buf=0xb0ad44ec "", len=4095, peek=0) at s3_pkt.c:1266 #11 0xb74ac9c9 in ssl3_read_internal (s=0xb0553a10, buf=0xb0ad44ec, len=4095, peek=0) at s3_lib.c:3265 #12 0xb74c24a9 in SSL_read (s=0xb0553a10, buf=0xb0ad44ec, num=4095) at ssl_lib.c:954 #13 0xb6fad1c3 in tls_read_f (c=0xb0ad431c, flags=0xbfd619c4) at tls_server.c:1058 #14 0x08171c0e in tcp_read_headers (c=0xb0ad431c, read_flags=0xbfd619c4) at tcp_read.c:406 #15 0x08171db8 in tcp_read_req (con=0xb0ad431c, bytes_read=0xbfd619cc, read_flags=0xbfd619c4) at tcp_read.c:885 #16 0x08172f67 in handle_io (fm=<value optimized out>, events=1, idx=<value optimized out>) at tcp_read.c:1234 #17 0x0817583b in io_wait_loop_epoll (unix_sock=89) at io_wait.h:1092 #18 tcp_receive_loop (unix_sock=89) at tcp_read.c:1345 #19 0x0816e2e9 in tcp_init_children () at tcp_main.c:4867 #20 0x080affb1 in main_loop () at main.c:1646 #21 0x080b1be4 in main (argc=9, argv=0xbfd61e54) at main.c:2446 Pid 3: Core was generated by `/usr/sbin/kamailio -u swrun -g sw -m 120 -f /etc/kamailio/kamailio.cfg'. Program terminated with signal 11, Segmentation fault. #0 0xb76c9e7c in memmove () from /lib/libc.so.6 (gdb) bt #0 0xb76c9e7c in memmove () from /lib/libc.so.6 #1 0x081724e7 in tcp_read_req (con=0xb022c8f0, bytes_read=0xbfd619cc, read_flags=0xbfd619c4) at tcp_read.c:1026 #2 0x08172f67 in handle_io (fm=<value optimized out>, events=1, idx=<value optimized out>) at tcp_read.c:1234 #3 0x0817583b in io_wait_loop_epoll (unix_sock=93) at io_wait.h:1092 #4 tcp_receive_loop (unix_sock=93) at tcp_read.c:1345 #5 0x0816e2e9 in tcp_init_children () at tcp_main.c:4867 #6 0x080affb1 in main_loop () at main.c:1646 #7 0x080b1be4 in main (argc=9, argv=0xbfd61e54) at main.c:2446

13 years

kamailio fail to start when there are many records in DB in location or in pua table

by laura testi

Hi all, when there many records in DB tables like location(usrloc use write back mode), pua etc, kamailio fail to start by complaining "no pkg memory left" when try to load (restore) all records from DB to hashtable of location/pua. The share momory are allocated enough for the hashtable, but the default compilation of the PKG_MEMORY_SIZE is 4MB, which allow only restore several thousands records. I know I can increase the PKG_MEMORY_SIZE, but anyway there is a limitation which may fail to restore all records from DB during the startup of kamailio if it reach the limit of the number of records in DB. Is there anyway to reload the hashtable from table by doing query n rows a time and loop until non more result from DB? this will avoid the kamailio startup problem when there are many records in hashtable which are save also in DB. Thank you very much in advanced! Laura

13 years

[tracker] Assignee added: Crash if t_release() is executed after t_relay_to(), when this last returns -1

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A user has added themself to the list of users assigned to this task. FS#184 - Crash if t_release() is executed after t_relay_to(), when this last returns -1 User who did this - Iñaki Baz Castillo (ibc) http://sip-router.org/tracker/index.php?do=details&task_id=184 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

13 years

[tracker] Task opened: textopsx:msg_apply_changes() can corrupt incoming TCP message buffer

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Hugh Waite (hugh.waite) Attached to Project - sip-router Summary - textopsx:msg_apply_changes() can corrupt incoming TCP message buffer Task Type - Bug Report Category - Module Status - Unconfirmed Assigned To - Operating System - All Severity - High Priority - Normal Reported Version - Development Due in Version - Undecided Due Date - Undecided Details - The msg_apply_changes function in textopsx module creates a new request in pkg memory and copies it back into the main message parse buffer. When data has been read from a TCP stream, it may include more than one message. The buffer and pointers will be corrupted if the new request is larger, causing failure to parse the subsequent messages. More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=185 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

13 years, 1 month

Memory corruption in textopsx

by Hugh Waite

Hi, I've discovered a bug within textopsx to do with msg_apply_changes. After creating the new request in pkg memory it is memcpy'ed back into msg->buf. This is a issue when more than one SIP message has been read from a TCP stream. If the new request is larger it will corrupt the following message. I don't know the best way to resolve this immediately, but I felt it was worth mentioning here as you are about to release 3.2.1. Best regards, Hugh Code path to recreate bug: Send in 3 requests very quickly on a TCP stream, this is read as a single block. tcp_read.c: tcp_read_req() first message is parsed. receive_msg() -> In the cfg, insert a header (e.g. Max-Forwards: 10), msg_apply_changes() and forward. More data exists in buffer, which is shifted to the start of the buffer, however this has been overwritten. Parse fails on second request.

13 years, 1 month

[tracker] Task closed: dialplan replacement with AVPs doesn't work

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task is now closed: FS#153 - dialplan replacement with AVPs doesn't work User who did this - Daniel-Constantin Mierla (miconda) Reason for closing: Fixed Additional comments about closing: Backported to 3.1 as well. More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=153 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

13 years, 1 month

git:3.1: dialplan: fix usage of avps in replacement expression

by Daniel-Constantin Mierla

Module: sip-router Branch: 3.1 Commit: 8371befc51d8a0db7e57e686a77d9e700f609239 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=8371bef… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Mon Oct 17 18:27:42 2011 +0200 dialplan: fix usage of avps in replacement expression - clone the replacement expression to shared memory before parsing it in order to have variables names available at runtime - most of variables should be safe to use now in replacement expressions, including avps with string name. This fixes FS#153 reported by Andrew Pogrebennyk - variables with dynamic name have no easy way to clone at this moment, thus avoid using them directly. Use instead avps or script vars ($var(...)), copying the value from initial variable to it. Variables pointing to sip message attributes are safe to use. --- modules/dialplan/dialplan.c | 101 ++++++++++++++++++------------------ modules/dialplan/dp_db.c | 122 +++++++++++++++++++++---------------------- modules/dialplan/dp_repl.c | 108 +++++++++++++++++++++----------------- 3 files changed, 170 insertions(+), 161 deletions(-) Diff: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commitdiff;h=837…

13 years, 1 month

git:3.1: dialplan: cfg functions can be used in ANY_ROUTE

by Daniel-Constantin Mierla

Module: sip-router Branch: 3.1 Commit: 5aab052eb3af4edea6a5a583001d7ab25d80fc5f URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=5aab052… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Sun Apr 17 13:48:14 2011 +0200 dialplan: cfg functions can be used in ANY_ROUTE (cherry picked from commit 63d4ae1463eb36a13adda76de8ee963588cddbdc) --- modules/dialplan/dialplan.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/modules/dialplan/dialplan.c b/modules/dialplan/dialplan.c index 4c86778..4ce3557 100644 --- a/modules/dialplan/dialplan.c +++ b/modules/dialplan/dialplan.c @@ -107,9 +107,9 @@ static mi_export_t mi_cmds[] = { static cmd_export_t cmds[]={ {"dp_translate",(cmd_function)dp_translate_f, 2, dp_trans_fixup, 0, - REQUEST_ROUTE|FAILURE_ROUTE|LOCAL_ROUTE|BRANCH_ROUTE}, + ANY_ROUTE}, {"dp_translate",(cmd_function)dp_translate_f, 1, dp_trans_fixup, 0, - REQUEST_ROUTE|FAILURE_ROUTE|LOCAL_ROUTE|BRANCH_ROUTE}, + ANY_ROUTE}, {0,0,0,0,0,0} };

13 years, 1 month

[tracker] Comment added: tls module error on initialization when used together with the dialog module

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#183 - tls module error on initialization when used together with the dialog module User who did this - Daniel-Constantin Mierla (miconda) ---------- I will try to get a solution for it. ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=183#comment431 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

13 years, 1 month

[tracker] User took ownership: tls module error on initialization when used together with the dialog module

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. Daniel-Constantin Mierla has taken ownership of the following task: FS#183 - tls module error on initialization when used together with the dialog module More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=183 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

13 years, 1 month

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev November 2011