sr-dev May 2024

sr-dev@lists.kamailio.org

15 participants
165 discussions

[kamailio/kamailio] core/resolve: Check dns_cache_init and choose appropriate functions (PR #3858)

by Xenofon Karamanos

#### Pre-Submission Checklist    - [ ] Commit message has the format required by CONTRIBUTING guide - [ ] Commits are split per component (core, individual modules, libs, utils, ...) - [ ] Each component has a single commit (if not, squash them into one commit) - [ ] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated) #### Type Of Change - [x] Small bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality) #### Checklist:  - [x] PR should be backported to stable branches - [x] Tested changes locally - [x] Related to issue #3350 #### Description  This PR fixes a crash when `dns_cache_init=off`. The issue is described in #3350 and the crash is caused when trying to search in `dns_cache.c` [LOCK_DNS_HASH();](https://github.com/kamailio/kamailio/blob/d4629be286fc6d3…. When `dns_cache_init=off`, the lock is never initialized and when trying to lock it crashes. Per my understanding, when `dns_cache_init=off`, no calls to `dns_cache.c` should be made and instead call the alternative ones from `resolve.c`, since the whole functions are compiled only when USE_DNS_CACHE definition is present. Just a question to clarify, what is the reasoning behind USE_DNS_CACHE definition and a separate `dns_cache_init` parameter? You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3858 -- Commit Summary -- * core/resolve: Check dns_cache_init and choose appropriate functions -- File Changes -- M src/core/resolve.c (16) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3858.patch https://github.com/kamailio/kamailio/pull/3858.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3858 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3858(a)github.com>

5 months

[kamailio/kamailio] rtpengine: multipart content dropped when used read_sdp_pv (Issue #3854)

by sergey-safarov

### Description When configured `read_sdp_pv` param for rtpengine module, then multipart content dropped in the body. And the message cannot be parsed because ``` Content-Type: multipart/mixed;boundary=level3-boundary ``` But the message body does not have a separator. ### Troubleshooting #### Reproduction To reproduce need to start Kamailio with config file ``` loadmodule "pv.so" loadmodule "ctl.so" loadmodule "corex.so" loadmodule "sdpops.so" loadmodule "rtpengine.so" modparam("rtpengine", "rtpengine_sock", "udp:localhost:2223") modparam("rtpengine", "read_sdp_pv", "$var(sdp_for_rtpengine)") listen=udp:x.x.x.x:5060 request_route { $var(sdp_for_rtpengine) = $sdp(body); rtpengine_manage("ICE=force"); forward(); } ``` And then send call using `sipp` script ```xml <scenario name="Basic Sipstone UAC">   <send retrans="500"> <![CDATA[ INVITE sip:[service]@example.com:[remote_port] SIP/2.0 Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch] From: sipp <sip:sipp@[local_ip]:[local_port]>;tag=[call_number] To: sut <sip:[service]@[remote_ip]:[remote_port]> Call-ID: [call_id] CSeq: 1 INVITE Contact: sip:sipp@[local_ip]:[local_port] Max-Forwards: 70 Subject: Performance Test Content-Type: multipart/mixed;boundary=level3-boundary Content-Length: [len] --level3-boundary Content-Type: application/sdp v=0 o=user1 53655765 2353687637 IN IP[local_ip_type] [local_ip] s=- c=IN IP[media_ip_type] [media_ip] t=0 0 m=audio [media_port] RTP/AVP 0 a=rtpmap:0 PCMU/8000 --level3-boundary Content-Type: application/isup;version=ansi Content-Disposition: session;handling=optional \x01\x18\x08\x10\x0a\x03\x06\x0d\x03\x80\x90\xa2\x07\x03\x10\x87\x36\x08\x14\x89 \x0a\x07\x03\x13\x27\x97\x45\x28\x49\xc0\x08\xc0\x03\x10\x65\x41\x17\x88\x67\x3d \x01\x11\xc4\x03\x01\x01\x00\xea\x01\x01\xc7\x01\x20\x01\x0d\x0a --level3-boundary-- ]]> </send> ``` If the `read_sdp_pv` param will be commented in the Kamailio config file, then the resulting message will be properly formatted and have the other multipart media. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3854 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3854(a)github.com>

5 months

[kamailio/kamailio] uac: add reload_delta parameter (PR #3829)

by Tyler Moore

#### Pre-Submission Checklist - [x] Commit message has the format required by CONTRIBUTING guide - [x] Commits are split per component (core, individual modules, libs, utils, ...) - [x] Each component has a single commit (if not, squash them into one commit) - [x] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated) #### Type Of Change - [ ] Small bug fix (non-breaking change which fixes an issue) - [x] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality) #### Checklist: - [ ] PR should be backported to stable branches - [x] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description Add support for setting a different RPC reload interval than the reg_gc_interval parameter. This allows the cleanup timer to match the user's re-transmission timeout without constraining RPC reload times to a large interval. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3829 -- Commit Summary -- * uac: add reload_delta parameter -- File Changes -- M src/modules/uac/doc/uac.xml (9) M src/modules/uac/doc/uac_admin.xml (37) M src/modules/uac/uac.c (5) M src/modules/uac/uac_reg.c (5) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3829.patch https://github.com/kamailio/kamailio/pull/3829.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3829 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3829(a)github.com>

5 months

[kamailio/kamailio] possible memory corruption in sipcapture module (Issue #3835)

by Sven Uhlig

### Description We send HEP3 data to the UDP listener in kamailio. In this HEP3 data, there are SIP requests and replies. We want to route these SIP messages through `request_route` and `onreply_route`. For this, we use the SipCapture module with the following settings: ``` modparam("sipcapture", "db_url", DBURL) modparam("sipcapture", "capture_on", 1) modparam("sipcapture", "hep_capture_on", 1) modparam("sipcapture", "insert_retries", 0) modparam("sipcapture", "insert_retry_timeout", 0) request_route { xlog("L_INFO", "Got new request ($ci) $rm: $si => $Ri\n"); } onreply_route { xlog("L_INFO", "Got new reply ($ci) $rm: $si => $Ri - Reply Code $rs\n"); } ``` In the past (version kamailio 5.1.x - 5.4.x), this worked as expected. From the logs: ``` 2(8) INFO: <script>: Got new request (7xkVDrAWegvcZl-ACaUb1HWHwiCYhAJR) INVITE: 217.116.121.230 => 172.20.21.4 3(9) INFO: <script>: Got new reply (7xkVDrAWegvcZl-ACaUb1HWHwiCYhAJR) INVITE: 172.20.21.4 => 217.116.121.230 - Reply Code 407 ``` Starting with kamailio 5.5.x, some pseudo variables are broken. From the logs: ``` 1(7) INFO: <script>: Got new request (7xkVDrAWegvcZl-ACaUb1HWHwiCYhAJR) INVITE: 217.116.121.230 => 217.116.121 2(8) INFO: <script>: Got new reply (7xkVDrAWegvcZl-ACaUb1HWHwiCYhAJR) INVITE: 172.20.21.4 => 172.20.21.4 3(9) INFO: <script>: ... ``` As you can see, the `$Ri` in the request is wrong. It looks like the first three octets of the `$si` and the fourth octet is missing entirely. And for the reply: - The `$Ri` is the `$si`. - The line is missing the static text `Reply Code`, the actual reply code. - The next log is on the same line (the new line is gone). (In this case, we simply sent a third HEP3 message.) To my untrained eye this looks like possible memory corruption. ### Troubleshooting #### Reproduction 1. Set up a kamailio 5.8.1 using the attached [kamailio.cfg](https://github.com/kamailio/kamailio/files/15161868/kamailio.… `/usr/sbin/kamailio -E -DD -dd -f "/etc/kamailio/kamailio.cfg"` 2. Send the HEP3 data using [heplify](https://github.com/sipcapture/heplify) `./heplify -t pcap -rf "sipcapture-bug.pcap" -hs localhost:9060 -e -eof-exit` #### Debugging Data #### Log Messages see above #### SIP Traffic see attached [sipcapture-bug.pcap](https://github.com/kamailio/kamailio/files/15161698/si… ### Possible Solutions Use kamailio 5.4.x or earlier versions. ### Additional Information When setting `nonsip_hook` = `1`, then the `$hep(...)` pseudo variables look fine. Unfortunately, we don't know how process the SIP messages after that point. ``` modparam("sipcapture", "nonsip_hook", 1) ... event_route[sipcapture:request] { xlog("L_INFO", "version: $hep(version)\n"); xlog("L_INFO", "src_ipv4: $hep(0x003)\n"); xlog("L_INFO", "dst_ipv4: $hep(0x004)\n"); xlog("L_INFO", "src_proto: $hep(0x007)\n"); xlog("L_INFO", "dst_proto: $hep(0x008)\n"); xlog("L_INFO", "proto: $hep(0x00b)\n"); } ``` * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.8.1 (x86_64/linux) flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_SEND_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: compiled with gcc 12.2.0 ``` Also tested with same error: 5.5.x, 5.6.x, 5.7.x * **Operating System**: ``` # lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 12 (bookworm) Release: 12 Codename: bookworm ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3835 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3835(a)github.com>

5 months

[kamailio/kamailio] Crash on shutdown after geoip2.reload (Issue #3861)

by Bastian Triller

5 months

[kamailio/kamailio] bad BYE message from endpoint when using topoh in kamailio 5.5.1 (Issue #3853)

by descartin

5 months

[kamailio/kamailio] Possible memory leak in siputils module (Issue #3857)

by giupand

5 months

[kamailio/kamailio] kamailio tls connection uses too much shared memory (Issue #3803)

by JiangHai2011

### Description a tls connection uses 52104 bytes. Among these memory, tcp_connection structure use 776 bytes and tcp_rd_buf use 6000 bytes, and the left part (45328 bytes) are all about SSL session with crypto. ### Expected behavior kamailio does some optimization for self defined BIO_TYPE_SOURCE_SINK bio type, to save more memory #### Actual observed behavior among this 45328 bytes, the biggest parts are BIO read buffer(16KB) and BIO write buffer(16KB). currently kamailio uses BIO_TYPE_SOURCE_SINK type bio, which needs kamailio manage the buffer by itself (there is no optimization). While nginx uses BIO_TYPE_MEM type bio, which is a openssl's internal bio type with memory optimization. As a result, nginx use less memory to accept more TLS connections than kamailio #### Debugging Data None #### Log Messages Mar 30 19:46:46 localhost.localdomain sipproxy[2273]: INFO: <core> [mem/tlsf_malloc.c:1219]: tlsf_sums(): pool (0x7f1a3eec1000) summarizing all alloc'ed. fragments: Mar 30 19:46:46 localhost.localdomain sipproxy[2273]: INFO: <core> [mem/tlsf_malloc.c:1235]: tlsf_sums(): count= 2 size= 336 bytes from tls: tls_init.c: crypto/evp/evp_enc.c(43) Mar 30 19:46:46 localhost.localdomain sipproxy[2273]: INFO: <core> [mem/tlsf_malloc.c:1235]: tlsf_sums(): count= 1 size= 80 bytes from tls: tls_init.c: crypto/bn/bn_blind.c(36) Mar 30 19:46:46 localhost.localdomain sipproxy[2273]: INFO: <core> [mem/tlsf_malloc.c:1235]: tlsf_sums(): count= 3 size= 360 bytes from tls: tls_init.c: crypto/bn/bn_mont.c(232) Mar 30 19:46:46 localhost.localdomain sipproxy[2273]: INFO: <core> [mem/tlsf_malloc.c:1235]: tlsf_sums(): count= 2 size= 1456 bytes from tls: tls_init.c: crypto/evp/evp_enc.c(129) Mar 30 19:46:46 localhost.localdomain sipproxy[2273]: INFO: <core> [mem/tlsf_malloc.c:1235]: tlsf_sums(): count= 1 size= 120 bytes from tls: tls_init.c: ssl/t1_lib.c(1784) Mar 30 19:46:46 localhost.localdomain sipproxy[2273]: INFO: <core> [mem/tlsf_malloc.c:1235]: tlsf_sums(): count= 1 size= 56 bytes from tls: tls_init.c: ssl/statem/extensions.c(959) Mar 30 19:46:46 localhost.localdomain sipproxy[2273]: INFO: <core> [mem/tlsf_malloc.c:1235]: tlsf_sums(): count= 2 size= 112 bytes from tls: tls_init.c: ssl/t1_lib.c(1811) Mar 30 19:46:46 localhost.localdomain sipproxy[2273]: INFO: <core> [mem/tlsf_malloc.c:1235]: tlsf_sums(): count= 1 size= 56 bytes from tls: tls_init.c: ssl/statem/../packet_local.h(462) Mar 30 19:46:46 localhost.localdomain sipproxy[2273]: INFO: <core> [mem/tlsf_malloc.c:1235]: tlsf_sums(): count= 1 size= 56 bytes from tls: tls_init.c: ssl/statem/../packet_local.h(485) Mar 30 19:46:46 localhost.localdomain sipproxy[2273]: INFO: <core> [mem/tlsf_malloc.c:1235]: tlsf_sums(): count= 1 size= 640 bytes from tls: tls_init.c: ssl/ssl_sess.c(72) Mar 30 19:46:46 localhost.localdomain sipproxy[2273]: INFO: <core> [mem/tlsf_malloc.c:1235]: tlsf_sums(): count= 1 size= 144 bytes from tls: tls_init.c: ssl/packet_local.h(462) Mar 30 19:46:46 localhost.localdomain sipproxy[2273]: INFO: <core> [mem/tlsf_malloc.c:1235]: tlsf_sums(): count= 1 size= 224 bytes from tls: tls_init.c: crypto/evp/digest.c(139) Mar 30 19:46:46 localhost.localdomain sipproxy[2273]: INFO: <core> [mem/tlsf_malloc.c:1235]: tlsf_sums(): count= 3 size= 168 bytes from tls: tls_init.c: crypto/evp/digest.c(62) Mar 30 19:46:46 localhost.localdomain sipproxy[2273]: INFO: <core> [mem/tlsf_malloc.c:1235]: tlsf_sums(): count= 1 size= 16496 bytes from tls: tls_init.c: ssl/record/ssl3_buffer.c(124) Mar 30 19:46:46 localhost.localdomain sipproxy[2273]: INFO: <core> [mem/tlsf_malloc.c:1235]: tlsf_sums(): count= 1 size= 16712 bytes from tls: tls_init.c: ssl/record/ssl3_buffer.c(63) Mar 30 19:46:46 localhost.localdomain sipproxy[2273]: INFO: <core> [mem/tlsf_malloc.c:1235]: tlsf_sums(): count= 1 size= 6280 bytes from tls: tls_init.c: ssl/ssl_lib.c(691) Mar 30 19:46:46 localhost.localdomain sipproxy[2273]: INFO: <core> [mem/tlsf_malloc.c:1235]: tlsf_sums(): count= 1 size= 6776 bytes from core: tcp_main.c: tcpconn_new(1148) Mar 30 19:46:46 localhost.localdomain sipproxy[2273]: INFO: <core> [mem/tlsf_malloc.c:1235]: tlsf_sums(): count= 1 size= 56 bytes from tls: tls_init.c: tls_bio.c(184) Mar 30 19:46:46 localhost.localdomain sipproxy[2273]: INFO: <core> [mem/tlsf_malloc.c:1235]: tlsf_sums(): count= 1 size= 120 bytes from tls: tls_init.c: crypto/bio/bio_lib.c(73) Mar 30 19:46:46 localhost.localdomain sipproxy[2273]: INFO: <core> [mem/tlsf_malloc.c:1235]: tlsf_sums(): count= 1 size= 536 bytes from tls: tls_init.c: ssl/ssl_cert.c(76) Mar 30 19:46:46 localhost.localdomain sipproxy[2273]: INFO: <core> [mem/tlsf_malloc.c:1235]: tlsf_sums(): count= 1 size= 56 bytes from tls: tls_init.c: ssl/ssl_lib.c(793) Mar 30 19:46:46 localhost.localdomain sipproxy[2273]: INFO: <core> [mem/tlsf_malloc.c:1235]: tlsf_sums(): count= 1 size= 72 bytes from tls: tls_init.c: crypto/bio/bio_meth.c(41) Mar 30 19:46:46 localhost.localdomain sipproxy[2273]: INFO: <core> [mem/tlsf_malloc.c:1235]: tlsf_sums(): count= 1 size= 96 bytes from tls: tls_init.c: crypto/bio/bio_meth.c(38) Mar 30 19:46:46 localhost.localdomain sipproxy[2273]: INFO: <core> [mem/tlsf_malloc.c:1235]: tlsf_sums(): count= 1 size= 1040 bytes from tls: tls_init.c: ssl/s3_lib.c(3296) Mar 30 19:46:46 localhost.localdomain sipproxy[2273]: INFO: <core> [mem/tlsf_malloc.c:1235]: tlsf_sums(): count= 1 size= 56 bytes from tls: tls_server.c: tls_complete_init(229) #### SIP Traffic None ### Possible Solutions None ### Additional Information [root@ip-10-23-0-191 ec2-user]# /opt/kamailio/sbin/kamailio -v version: kamailio 4.4.7 (aarch64/linux) flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT-NOSMP, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: unknown compiled on 12:18:05 Mar 28 2024 with gcc 7.3.1 * **Operating System**: Linux localhost.localdomain 4.18.0-425.3.1.el8.x86_64 #1 SMP Tue Nov 8 14:08:25 EST 2022 x86_64 x86_64 x86_64 GNU/Linux -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3803 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3803(a)github.com>

5 months

[kamailio/kamailio] Kamailio 5.8 core dumps with regex module (Issue #3812)

by Odorik.cz

### Description I tried to update to a new version of kamailio and it didn't start with the old configuration file, I found out that the regex module is responsible. Log after start: ` 0(713737) INFO: regex [regex_mod.c:417]: load_pcres(): num groups = 1 0(713737) INFO: regex [regex_mod.c:419]: load_pcres(): <group[0]>((^[1-9]\d{5}$)|(^ukrb[12]$)) </group[0]> (size = 29) 0(713735) ERROR: <core> [core/daemonize.c:302]: daemonize(): Main process exited before writing to pipe`  ### Troubleshooting #### Reproduction  grep regex /usr/local/etc/kamailio/kamailio.cfg loadmodule "regex.so" modparam("regex", "file", "/usr/local/etc/kamailio/regex_groups") cat /usr/local/etc/kamailio/regex_groups [0] #cislo linky (^[1-9]\d{5}$) (^ukrb[12]$) #### Debugging Data  ``` gdb /usr/local/sbin/kamailio /core GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git Copyright (C) 2021 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/local/sbin/kamailio... warning: Can't open file /dev/zero (deleted) during file-backed mapping note processing [New LWP 713740] warning: Section `.reg-xstate/713740' in core file too small. [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `/usr/local/sbin/kamailio -S -P /run/kamailio/kamailio.pid -f /usr/local/etc/kam'. Program terminated with signal SIGSEGV, Segmentation fault. warning: Section `.reg-xstate/713740' in core file too small. #0 load_pcres (action=0) at regex_mod.c:466 466 *pcres = *pcres_tmp; (gdb) bt full #0 load_pcres (action=0) at regex_mod.c:466 i = 1 j = 32 f = 0x55c5775ea6b0 line = '\000' <repeats 499 times> patterns = 0x7f7e7ad3a230 pcre_error_num = 100 pcre_error = '\000' <repeats 16 times>, "\277Fou\305U\000\000\000\000\000\000m\000\000\000(Hou\305U\000\000\332Gou\305U\000\000\220\000\000\000\000\000\000\000\020\240\303z~\177\000\000 \274$u\305U\000\000\037\000\000\000\004\000\000\000\001\000\000\000%\000\000\000\n\344\n\000\000\000\000\000 \274$u\305U\000\000\000\000\000\000\000\000\000\000\n\344\n\000\000\000\000\000\360\212\355\255\374\177\000" pcre_erroffset = 0 num_pcres_tmp = 1 pcres_tmp = 0x7f7e7ad62c00 llen = 19 __func__ = "load_pcres" #1 0x00007f7e79f62c92 in mod_init () at regex_mod.c:245 __func__ = "mod_init" #2 0x000055c5754a99f7 in init_mod (m=0x7f7e7adeb1f0) at core/sr_module.c:1036 ret = -2097389668 __func__ = "init_mod" #3 0x000055c5754a9687 in init_mod (m=0x7f7e7adeb6c0) at core/sr_module.c:1031 ret = 0 __func__ = "init_mod" #4 0x000055c5754a9687 in init_mod (m=0x7f7e7adebda0) at core/sr_module.c:1031 ret = -2097386271 __func__ = "init_mod" #5 0x000055c5754a9687 in init_mod (m=0x7f7e7adec3b0) at core/sr_module.c:1031 ret = 0 __func__ = "init_mod" #6 0x000055c5754a9687 in init_mod (m=0x7f7e7adec910) at core/sr_module.c:1031 ret = -1376937648 __func__ = "init_mod" #7 0x000055c5754a9687 in init_mod (m=0x7f7e7adece70) at core/sr_module.c:1031 ret = 0 __func__ = "init_mod" #8 0x000055c5754a9687 in init_mod (m=0x7f7e7aded520) at core/sr_module.c:1031 ret = 0 __func__ = "init_mod" #9 0x000055c5754a9687 in init_mod (m=0x7f7e7adedc10) at core/sr_module.c:1031 ret = 0 __func__ = "init_mod" #10 0x000055c5754a9687 in init_mod (m=0x7f7e7adee1f0) at core/sr_module.c:1031 ret = -1376937902 __func__ = "init_mod" #11 0x000055c5754a9687 in init_mod (m=0x7f7e7adeeaf0) at core/sr_module.c:1031 ret = 0 __func__ = "init_mod" #12 0x000055c5754a9687 in init_mod (m=0x7f7e7adef4d0) at core/sr_module.c:1031 ret = 16 __func__ = "init_mod" #13 0x000055c5754a9687 in init_mod (m=0x7f7e7adef8e0) at core/sr_module.c:1031 ret = 0 __func__ = "init_mod" #14 0x000055c5754a9687 in init_mod (m=0x7f7e7adefdd0) at core/sr_module.c:1031 ret = 0 __func__ = "init_mod" #15 0x000055c5754a9687 in init_mod (m=0x7f7e7adf3320) at core/sr_module.c:1031 ret = 2053729903 __func__ = "init_mod" #16 0x000055c5754a9687 in init_mod (m=0x7f7e7adf3770) at core/sr_module.c:1031 ret = -1 __func__ = "init_mod" #17 0x000055c5754a9687 in init_mod (m=0x7f7e7adf3ba0) at core/sr_module.c:1031 ret = 0 __func__ = "init_mod" #18 0x000055c5754a9687 in init_mod (m=0x7f7e7adf4140) at core/sr_module.c:1031 ret = 0 __func__ = "init_mod" #19 0x000055c5754a9687 in init_mod (m=0x7f7e7adf4550) at core/sr_module.c:1031 ret = 0 __func__ = "init_mod" #20 0x000055c5754a9687 in init_mod (m=0x7f7e7adf6140) at core/sr_module.c:1031 ret = 713738 __func__ = "init_mod" #21 0x000055c5754a9dc4 in init_modules () at core/sr_module.c:1067 t = 0xae40a i = -1 __func__ = "init_modules" #22 0x000055c57526927c in main (argc=12, argv=0x7ffcaded9fd8) at main.c:3202 cfg_stream = 0x55c57746a2a0 c = -1 r = 0 tmp = 0x7ffcadedae88 "" tmp_len = 832 port = 5060 proto = 0 aproto = 0 ahost = 0x0 aport = 0 options = 0x55c5756b8368 ":f:cm:M:dVIhEeb:B:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:x:X:Y:" ret = -1 seed = 4165046025 rfd = 4 debug_save = 0 debug_flag = 0 dont_fork_cnt = 0 n_lst = 0x98000000980 p = 0x180000000 <error: Cannot access memory at address 0x180000000> st = {st_dev = 115, st_ino = 321140, st_nlink = 2, st_mode = 16888, st_uid = 0, st_gid = 0, __pad0 = 0, st_rdev = 0, st_size = 40, st_blksize = 4096, st_blocks = 0, st_atim = {tv_sec = 1712844094, tv_nsec = 899597355}, st_mtim = {tv_sec = 1712844094, tv_nsec = 899597355}, st_ctim = {tv_sec = 1712844094, tv_nsec = 899597355}, __glibc_reserved = {0, 0, 0}} --Type <RET> for more, q to quit, c to continue without paging-- l1 = 2048 tbuf = "p\233\355\255\374\177\000\000\310%ǂ~\177\000\000\020D\373\202~\177\000\000\000\000\000\000\000\000\000\000\360\233\355\255\374\177\000\000\000\000\000\000\000\000\000\000\360\233\355\255\374\177", '\000' <repeats 18 times>, "`\307\373\202~\177\000\000\350\204\376\202~\177\000\000\204\311\373\202~\177\000\000\060\304\373\202~\177\000\000Hp\376\202~\177\000\000\000\300\373\202~\177\000\000\000\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000@\342ł~\177", '\000' <repeats 66 times>... option_index = 12 long_options = {{name = 0x55c5756ba886 "help", has_arg = 0, flag = 0x0, val = 104}, {name = 0x55c5756b554c "version", has_arg = 0, flag = 0x0, val = 118}, {name = 0x55c5756ba88b "alias", has_arg = 1, flag = 0x0, val = 1024}, {name = 0x55c5756ba891 "subst", has_arg = 1, flag = 0x0, val = 1025}, {name = 0x55c5756ba897 "substdef", has_arg = 1, flag = 0x0, val = 1026}, {name = 0x55c5756ba8a0 "substdefs", has_arg = 1, flag = 0x0, val = 1027}, {name = 0x55c5756ba8aa "server-id", has_arg = 1, flag = 0x0, val = 1028}, {name = 0x55c5756ba8b4 "loadmodule", has_arg = 1, flag = 0x0, val = 1029}, {name = 0x55c5756ba8bf "modparam", has_arg = 1, flag = 0x0, val = 1030}, {name = 0x55c5756ba8c8 "log-engine", has_arg = 1, flag = 0x0, val = 1031}, {name = 0x55c5756ba8d3 "debug", has_arg = 1, flag = 0x0, val = 1032}, { name = 0x55c5756ba8d9 "cfg-print", has_arg = 0, flag = 0x0, val = 1033}, {name = 0x55c5756ba8e3 "atexit", has_arg = 1, flag = 0x0, val = 1034}, {name = 0x55c5756ba8ea "all-errors", has_arg = 0, flag = 0x0, val = 1035}, {name = 0x0, has_arg = 0, flag = 0x0, val = 0}} __func__ = "main" ``` #### Log Messages  ``` 0(713842) WARNING: tls [tls_mod.c:747]: mod_register(): OpenSSL 1.1.1 setting cryptorand random engine 0(713842) INFO: rtimer [rtimer_mod.c:298]: stm_t_param(): created rtimer name=iptables interval=60 mode=1 0(713842) INFO: <core> [core/tcp_main.c:5205]: init_tcp(): using epoll_lt as the io watch method (auto detected) loading modules under config path: /usr/local/lib64/kamailio/modules/ Listening on udp: 81.31.45.42 [81.31.45.42]:5060 udp: 81.31.45.42 [81.31.45.42]:6688 udp: 81.31.45.42 [81.31.45.42]:443 udp: 81.31.45.42 [81.31.45.42]:6699 tcp: 81.31.45.42 [81.31.45.42]:5060 tcp: 81.31.45.42 [81.31.45.42]:443 tcp: 81.31.45.42 [81.31.45.42]:6688 tcp: 81.31.45.42 [81.31.45.42]:6699 tls: 81.31.45.42 [81.31.45.42]:5061 tls: 81.31.45.42 [81.31.45.42]:6689 tls: 81.31.45.42 [81.31.45.42]:6670 Aliases: *: sip2.gope.cz:* *: sipo.smartel.cz:* *: sipi.smartel.cz:* *: siptest.odorik.cz:* *: *.odorik.cz:* 0(713844) INFO: rr [../outbound/api.h:53]: ob_load_api(): unable to import bind_ob - maybe module is not loaded 0(713844) INFO: rr [rr_mod.c:185]: mod_init(): outbound module not available 0(713844) INFO: geoip2 [geoip2_mod.c:96]: mod_init(): using GeoIP database path /var/kamailio/GeoLite2-City-17.06.22.mmdb, library version 1.5.2 0(713844) INFO: cfgutils [cfgutils.c:829]: mod_init(): no hash_file given, disable hash functionality 0(713844) INFO: regex [regex_mod.c:417]: load_pcres(): num groups = 1 0(713844) INFO: regex [regex_mod.c:419]: load_pcres(): <group[0]>(((^[1-9]\d{5}$))|((^ukrb[12]$)))</group[0]> (size = 33) 0(713842) ERROR: <core> [core/daemonize.c:302]: daemonize(): Main process exited before writing to pipe ``` #### SIP Traffic  ``` (paste your sip traffic here) ``` ### Possible Solutions  ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` kamailio -v version: kamailio 5.8.1 (x86_64/linux) 215af5-dirty flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_SEND_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: 215af5 -dirty compiled on 15:32:24 Apr 11 2024 with gcc 10.2.1 ``` * **Operating System**:  ``` lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 11 (bullseye) Release: 11 Codename: bullseye uname -a Linux serZT 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-02-01) x86_64 GNU/Linux ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3812 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3812(a)github.com>

5 months

core dump on AWS with ~4000 TCP sockets

by David Villasmil

Hello all, I'm seeing core dumps (can't find them!) on AWS with lots of TCP sockets open (not related to load), kamailio dies randomly with: *May 30 14:31:03 sip-proxy /usr/sbin/kamailio[743739]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 142 May 30 14:31:03 sip-proxy /usr/sbin/kamailio[743542]: ALERT: <core> [main.c:788]: handle_sigs(): child process 743672 exited by a signal 11 May 30 14:31:03 sip-proxy /usr/sbin/kamailio[743542]: ALERT: <core> [main.c:791]: handle_sigs(): core was generated May 30 14:32:03 sip-proxy /usr/sbin/kamailio[743542]: CRITICAL: <core> [main.c:698]: sig_alarm_abort(): shutdown timeout triggered, dying...* before this happens, there's a ton of May 26 00:32:01 sip-proxy /usr/sbin/kamailio[74966]: ERROR: <core> [core/tcp_main.c:4591]: tcpconn_main_timeout(): connect 172.56.51.197:34846 failed (timeout) May 26 00:32:01 sip-proxy /usr/sbin/kamailio[74966]: ERROR: <core> [core/tcp_main.c:4591]: tcpconn_main_timeout(): connect 98.196.165.187:38593 failed (timeout) May 26 00:32:01 sip-proxy /usr/sbin/kamailio[74966]: ERROR: <core> [core/tcp_main.c:4591]: tcpconn_main_timeout(): connect 10.241.49.185:49372 failed (timeout) May 26 00:32:01 sip-proxy /usr/sbin/kamailio[74966]: ERROR: <core> [core/tcp_main.c:4591]: tcpconn_main_timeout(): connect 97.101.162.40:45248 failed (timeout) May 26 00:32:01 sip-proxy /usr/sbin/kamailio[74966]: ERROR: <core> [core/tcp_main.c:4591]: tcpconn_main_timeout(): connect 172.59.213.36:57074 failed (timeout) May 26 00:32:01 sip-proxy /usr/sbin/kamailio[74966]: ERROR: <core> [core/tcp_main.c:4591]: tcpconn_main_timeout(): connect 207.195.63.14:2521 failed (timeout) May 26 00:32:01 sip-proxy /usr/sbin/kamailio[74966]: ERROR: <core> [core/tcp_main.c:4591]: tcpconn_main_timeout(): connect 10.241.49.185:22155 failed (timeout) May 26 00:32:01 sip-proxy /usr/sbin/kamailio[74966]: ERROR: <core> [core/tcp_main.c:4591]: tcpconn_main_timeout(): connect 10.241.49.185:10339 failed (timeout) Regards, David Villasmil email: david.villasmil.work(a)gmail.com phone: +34669448337

5 months

← Newer
1
2
3
4
5
6
7
8
...
17
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev May 2024