sr-dev January 2021

sr-dev@lists.kamailio.org

17 participants
185 discussions

[kamailio/kamailio] xavp set in event_route[tm:local-request] are not used in SIP transaction (#2413)
by arkadiam 31 Mar '21

31 Mar '21

### Description I'm using dispatcher module like: ``` loadmodule "dispatcher.so" modparam("dispatcher", "list_file", "/etc/kamailio/dispatcher.list") modparam("dispatcher", "ds_probing_mode", 1) modparam("dispatcher", "ds_ping_interval", 60) ``` With records like: ``` 1 sip:sip.host.com;transport=tls 0 1 socket=tls:111.222.233.10:5061;ping_from=sip:my-domain-01.com 2 sip:sip.host.com;transport=tls 0 1 socket=tls:111.222.233.20:5061;ping_from=sip:my-domain-02.com ``` In event_route[tm:local-request] I'm modifying 'Contact' and would like to specify what client TLS profile to use via server name or server id. ``` event_route[tm:local-request] { if(is_method("OPTIONS")) { append_hf("Contact: <sip:some-host.com;transport=tls>\r\n"); $xavp(tls=>server_name)=$fd; $xavp(tls[0]=>server_id)=$fd; } } ``` Setting 'tls' xavp doesn't make any difference and default client TLS profile is being used. It happens because in src/modules/tm/uac.c there is a code: ``` t_run_local_req() ... tm_xdata_swap(new_cell, &backup_xd, 0); ... /* restore original environment */ tm_xdata_swap(new_cell, &backup_xd, 1); ``` which resets any xavp changes done in event_route[tm:local-request]. Expected behaviour: ability to use xavp in tm:local-request route. That would allow to choose TLS client profile for dispatcher initiated requests. ### Possible Solutions As a hack, in tm_xdata_swap() for mode=1, don't restore xavp list if it was NULL. ``` if (x->xavps_list != NULL && *x->xavps_list==NULL) { // .... don't restore empty list... } else { xavp_set_list(x->xavps_list); } ``` This change allows to select required TLS profile for dispatcher requests. ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.3.5 (x86_64/linux) ff2f8c-dirty flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, 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_BLACKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_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: ff2f8c -dirty compiled on 10:19:05 Jul 28 2020 with gcc 7.5.0 ``` * **Operating System**: ``` Linux xx 4.15.0-111-generic #112-Ubuntu SMP Thu Jul 9 20:32:34 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2413

2 4

[kamailio/kamailio] DMQ memory leak with dmq_bcast_message function (#2600)
by jklingenmeyer 26 Mar '21

26 Mar '21

### Description We noticed a PKG memory leak when using DMQ module's function _dmq_bcast_message_ . ### Troubleshooting #### Reproduction Issue can be reproduced with configuration below. * 3 Kamailio nodes each one listening on dedicated port 5070 for DMQ on their private IP address. * A dns name _[KAMAILIO_DNS]_ resolving these 3 nodes: ``` # dig +short A [KAMAILIO_DNS] 10.234.97.169 10.234.97.170 10.234.92.126 ``` DMQ module configured as below (example for node 1) ``` loadmodule "dmq.so" ... modparam("dmq", "server_address", "sip:10.234.97.169:5070") modparam("dmq", "notification_address", "sip:[KAMAILIO_DNS]:5070") modparam("dmq", "ping_interval", 10) modparam("dmq", "multi_notify", 1) ``` Each time an INVITE comes in, we use function below to broadcast custom message to all of the nodes: ``` ... if(is_method("INVITE")) { dmq_bcast_message("invitenotification", "invite received", "text/plain"); } ... ``` This custom message is handled as below: ``` request_route { ... if(is_method("KDMQ")) { if($Rp == 5070) route(DMQHANDLE); else drop; } ... } ... route[DMQHANDLE] { if($tU == "invitenotification") { # Doing some additional stuff here, but not the cause of the leak send_reply("200", "OK"); } else { dmq_handle_message(); } } ``` Using **sipp** to send lots of messages, we can easily notice the free PKG memory decreasing over time (using `kamcmd pkg.stats`) #### Debugging Data Processes impacted by the leak are the ones processing SIP messages. In case of TCP, it is one of the tcp receivers. When doing a dump of such processes with command below: ``` kamcmd cfg.set_now_int core mem_dump_pkg [PID] ``` Results are full of records like these ones: ``` ALERT: qm_status: alloc'd from core: core/parser/parse_from.c: parse_from_header(63) ALERT: qm_status: alloc'd from core: core/parser/parse_addr_spec.c: parse_to_param(285) ``` We are sure that the leak is generated by this DMQ broadcast function: we isolated it and noticed no leaks when removing it from a basic script configuration. We tried different configurations: * disabling multi_notify => memory leak still present * using an IP address instead of the DNS name => memory leak still present Valgrind did not help us to find out more precisely where the issue in the code could be located. ### Possible Solutions Would a _free_ of _msg->from->parsed_ be missing somewhere in DMQ code? Behavior looks very similar to https://github.com/kamailio/kamailio/pull/59 ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.3.7 (x86_64/linux) c16b3f-dirty flags: , EXTRA_DEBUGUSE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, TIMER_DEBUG, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES ``` * **Operating System**: ``` Debian 9.13 under docker Linux 4.9.0-9-amd64 ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2600

2 4

[kamailio/kamailio] starting kamailio takes too long (#2613)
by kristina258 09 Mar '21

09 Mar '21

### Description Hi, I am migrating from Kamailio 4.4.7 (debian 8.1) to 5.4.3 (debian 10.7). I changed the neccessary changes in configuration (replaced MI with RPC) and I tried to start the kamailio. The issue is that it takes about 3minutes to start. On the older version 4.4.7 it started aproximetly in 20s. The modules I am using are: ``` "cfgutils.so","db_mysql.so","kex.so","tm.so","tmx.so","sl.so","rr.so","pv.so","maxfwd.so","textops.so","siputils.so","xlog.so","sanity.so","ctl.so","jsonrpcs.so","exec.so","carrierroute.so","avpops.so","sqlops.so","dmq.so","htable.so","dialog.so","acc.so","acc_radius.so","dispatcher.so","dialplan.so","textopsx.so","statsd.so","app_perl.so","http_async_client.so". ``` I assume the issue is caused by carrierroute module. It takes also about 3 minutes to reload routes (when the kamailio service is running) using rpc command cr.reload_routes. I did not change anything in configuration related to carrierroute module. ``` modparam("carrierroute", "config_source", "db") modparam("carrierroute", "db_url", DBURL) modparam("carrierroute", "match_mode", 128) modparam("carrierroute", "avoid_failed_destinations", 0) modparam("carrierroute", "carrierroute_table", "carrierroute_view") ``` Carrierroute module loading on version 4.4.7 needed: - INFO: carrierroute [cr_db.c:317]: load_route_data_db(): **took 1s** - INFO: carrierroute [cr_carrier.c:100]: add_domain_data(): and INFO: carrierroute [cr_data.c:414]: get_domain_data_or_add(): **took 8s** - INFO: carrierroute [cr_data.c:655]: rule_fixup(): **took 3s** Carrierroute module loading on version 5.4.3 needed: - INFO: carrierroute [cr_db.c:317]: load_route_data_db(): **took 1s** - INFO: carrierroute [cr_carrier.c:100]: add_domain_data(): and INFO: carrierroute [cr_data.c:414]: get_domain_data_or_add(): **took 2min 23s** - INFO: carrierroute [cr_data.c:655]: rule_fixup(): **took 17s** I have also compiled kamailio version 5.0 on both (debian 8.1 and debian 10.7), but it also took so long to start on both machines. ### Additional Information ``` version: kamailio 5.4.3 (x86_64/linux) 06bd17 flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, 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_BLACKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_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: 06bd17 compiled on 16:10:30 Jan 25 2021 with gcc 8.3.0 ``` * **Operating System**: ``` Linux 4.19.0-13-amd64 #1 SMP Debian 4.19.160-2 (2020-11-28) x86_64 GNU/Linux Debian 10.7 ``` Thank you for your help. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2613

3 6

[kamailio/kamailio] lreproxy module (#2208)
by mojtabaesfandiari 03 Mar '21

03 Mar '21

lreproxy: add new lreproxy module   #### 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 - [ ] 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:  - [ ] PR should be backported to stable branches - [ ] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description  You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/2208 -- Commit Summary -- * lreproxy module -- File Changes -- A src/modules/lreproxy/README.md (1) A src/modules/lreproxy/lreproxy.c (1976) A src/modules/lreproxy/lreproxy.h (120) A src/modules/lreproxy/lreproxy_funcs.c (460) A src/modules/lreproxy/lreproxy_funcs.h (41) A src/modules/lreproxy/lreproxy_hash.c (521) A src/modules/lreproxy/lreproxy_hash.h (70) -- Patch Links -- https://github.com/kamailio/kamailio/pull/2208.patch https://github.com/kamailio/kamailio/pull/2208.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/2208

9 59

[kamailio/kamailio] ndb_redis: cluster support broken (#2461)
by Kritarth 02 Mar '21

02 Mar '21

### Description ndb_redis is treating MOVED reply from redis cluster as error and breaking out even before the cluster handling code gets a chance to process this. ``` if(rpl->rplRedis->type == REDIS_REPLY_ERROR) { LM_ERR("Redis error:%.*s\n", (int)rpl->rplRedis->len, rpl->rplRedis->str); goto error_exec; } if (check_cluster_reply(rpl->rplRedis, &rsrv)) { ... } ``` ### Troubleshooting #### Reproduction Setup a redis cluster with at least 2 nodes. Set modparam cluster=1 and allow_dynamic_nodes=1 fire redis get commands #### Log Messages ``` ERROR: ndb_redis [redis_client.c:1037]: redisc_exec(): Redis error:MOVED 1090 10.4.20.69:6379 ``` ### Possible Solutions revert https://github.com/kamailio/kamailio/commit/d00b14704805d728f5a845a6af900ef… or Add another check to ignore the above logic if cluster support is enabled. or Do not treat MOVED replies as of type REDIS_REPLY_ERROR ### Additional Information ``` kamailio built from branch 5.4.1 ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2461

3 7

[kamailio/kamailio] core on broken config (#2599)
by sergey-safarov 02 Mar '21

02 Mar '21

### Description I have created a broken config with construction ``` if (is_request()) { } ``` When I try to check config I get the core ``` 0(66437) CRITICAL: <core> [core/cfg.y:3665]: yyerror_at(): parse error in config file proxy-media.cfg, line 18, column 5: syntax error 0(66437) CRITICAL: <core> [core/cfg.y:3665]: yyerror_at(): parse error in config file proxy-media.cfg, line 18, column 5: bad command 0(66437) CRITICAL: <core> [core/cfg.y:3662]: yyerror_at(): parse error in config file proxy-media.cfg, line 20, column 5-6: ERROR: bad config file (3 errors) (parsing code: 1) 0(66437) ERROR: <core> [core/ppcfg.c:243]: pp_ifdef_level_error(): different number of preprocessor directives: 1 more #!if[n]def as #!endif 0(66437) INFO: <core> [core/sctp_core.c:53]: sctp_core_destroy(): SCTP API not initialized Program received signal SIGSEGV, Segmentation fault. 0x00007fffee8589ca in BN_clear_free () from /lib64/libcrypto.so.1.1 Missing separate debuginfos, use: yum debuginfo-install brotli-1.0.6-2.el8.x86_64 cyrus-sasl-lib-2.1.27-5.el8.x86_64 hiredis-0.13.3-13.el8.x86_64 jansson-2.11-3.el8.x86_64 keyutils-libs-1.5.10-6.el8.x86_64 krb5-libs-1.18.2-5.el8.x86_64 libcom_err-1.45.6-1.el8.x86_64 libcurl-7.61.1-14.el8.x86_64 libidn2-2.2.0-1.el8.x86_64 libnghttp2-1.33.0-3.el8_2.1.x86_64 libpsl-0.20.2-6.el8.x86_64 libselinux-2.9-4.el8_3.x86_64 libssh-0.9.4-2.el8.x86_64 libunistring-0.9.9-3.el8.x86_64 libxcrypt-4.1.1-4.el8.x86_64 libxml2-2.9.7-8.el8.x86_64 openldap-2.4.46-15.el8.x86_64 openssl-libs-1.1.1g-11.el8.x86_64 pcre2-10.32-2.el8.x86_64 xz-libs-5.2.4-3.el8.x86_64 zlib-1.2.11-16.el8_2.x86_64 (gdb) bt full #0 0x00007fffee8589ca in BN_clear_free () from /lib64/libcrypto.so.1.1 No symbol table info available. #1 0x00007fffecec5825 in ssh_dh_finalize.part () from /lib64/libssh.so.4 No symbol table info available. #2 0x00007fffeceb6e4d in libssh_destructor () from /lib64/libssh.so.4 No symbol table info available. #3 0x00007ffff7de4386 in _dl_fini () from /lib64/ld-linux-x86-64.so.2 No symbol table info available. #4 0x00007ffff708df8c in __run_exit_handlers () from /lib64/libc.so.6 No symbol table info available. #5 0x00007ffff708e0c0 in exit () from /lib64/libc.so.6 No symbol table info available. #6 0x00007ffff70777ba in __libc_start_main () from /lib64/libc.so.6 No symbol table info available. #7 0x000000000041c39e in _start () No symbol table info available. (gdb) ``` On host installed ``` [root@bcf-a0 config]# rpm -qf /lib64/libcrypto.so.1.1 openssl-libs-1.1.1g-11.el8.x86_64 ``` ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` [root@bcf-a0 config]# kamailio -v version: kamailio 5.5.0-dev3 (x86_64/linux) aff06f flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, 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_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: aff06f compiled on 04:01:30 Jan 7 2021 with gcc 8.3.1 ``` * **Operating System**: ``` [root@host ~]# cat /etc/os-release NAME="CentOS Linux" VERSION="8" ID="centos" ID_LIKE="rhel fedora" VERSION_ID="8" PLATFORM_ID="platform:el8" PRETTY_NAME="CentOS Linux 8" ANSI_COLOR="0;31" CPE_NAME="cpe:/o:centos:centos:8" HOME_URL="https://centos.org/" BUG_REPORT_URL="https://bugs.centos.org/" CENTOS_MANTISBT_PROJECT="CentOS-8" CENTOS_MANTISBT_PROJECT_VERSION="8" ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2599

3 18

issue using evapi module with evapi_relay
by David Escartin 26 Feb '21

26 Feb '21

Dear all we have been testing this module with the following setup kamailio 5.3.2 evapi params modparam("evapi", "workers", 4) modparam("evapi", "netstring_format", 0) modparam("evapi", "bind_addr", "127.0.0.1:8448") modparam("evapi", "max_clients", 32) then in the configuration we do evapi_relay of avp including a json data (which can be quite long), like this {"key" : "aarp2q0tcpqhs0cpucuhukjs2ah2j00q(a)10.18.5.64" , "msg" : {"rg_in":"701","ani_init":{"ani_source":"pai", ....... }}} We have an application listening on the tcp socket and writing those messages to a kafka cluster, and this works ok, and in the previous manual tests we have done no issue was found. But when making some load tests, and passing some live traffic we see some issues seems like some times, when there are messages to be sent to the tcp socket at the same time, they are sent in the same message, when normally each data sent using evapi_relay is sent in 1 message We do sometimes see something like this on the application consuming from the tcp socket 2020-11-25 15:20:01.744 UTC [error] <0.706.0>@evapi_kafka_listener:handle_info:167 body "{\"key\" : \" 6142651aa63616c6c04a783cd(a)72.21.24.130\" , \"msg\" : {\"rg_in\":\"677\",\"ani_init\":{\"ani_source\":\"fro\",.......}}}{\"key\" : \"isbc7caT4001915251VabcGhEfHdNiF0i(a)172.16.120.1\" , \"msg\" : {\"rg_in\":\"22\",\"ani_init\":{\"ani_source\":\"pai\", ....... ,\"translate" not valid json; error = {691,invalid_trailing_data} 2020-11-25 15:20:01.745 UTC [error] <0.706.0>@evapi_kafka_listener:handle_info:167 body "dPartition\":\"-1\",......}}}" not valid json; error = {1,invalid_json} and we do see that the application cannot parse the json message fine, because we have like 2 json objects together ......{\"ani_source\":\"fro\",.......}}}{\"key\" : \"isbc7caT4001915251Vabc............ This happens with 2 different UDP receivers processing messages and calling evapi_relay at the same time. But i don't think this happens all the time. Seems like some issue when several processes try to use evapi workers at the same time. We tried to increase evapi workers and it's the same We also saw another issue I think. Seems when the avp sent to evapi socket is bigger than ~1680 char, the json is also truncated, and also happens when we use the socket in Lo interface which has an MTU of 65535. Could you please take a look to see if there is any problem or limitation, or if we are using something wrong? thanks and best regards david -- [image: Logo] David Escartín Almudévar VoIP/Switch Engineer descartin(a)sonoc.io *SONOC* C/ Josefa Amar y Borbón, 10, 4ª · 50001 Zaragoza, España Tlf: +34 917019888 · www.sonoc.io

3 5

[kamailio/kamailio] TLS crashes Kamailio 5.4 branch on Ubuntu 20.04 and Debian Buster (#2560)
by Dylan 11 Feb '21

11 Feb '21

### Description Kamailio crashes on launch with TLS enabled on both Ubuntu 20.04 and Debian Buster. ### Troubleshooting #### Reproduction  1. cloned `https://github.com/kamailio/kamailio` 2. checked out `5.4` 3. make cfg 4. include_modules=app_python3 crypto db_mongodb db_postgres dialplan http_async_client http_client jansson json jsonrpcc log_systemd outbound regex tls utils xcap_client xhttp_pi uuid 5. make all 6. make install 7. make install-systemd-debian 8. turn on TLS (WITH_TLS), copy certs & keys. 9. sudo systemctl start kamailio #### Log Messages ``` Nov 20 00:20:06 kamailio-stage-3 /usr/local/sbin/kamailio[12570]: INFO: tls [tls_mod.c:389]: mod_init(): With ECDH-Support! Nov 20 00:20:06 kamailio-stage-3 /usr/local/sbin/kamailio[12570]: INFO: tls [tls_mod.c:392]: mod_init(): With Diffie Hellman Nov 20 00:20:06 kamailio-stage-3 kamailio[12569]: DIGEST-MD5 common mech free Nov 20 00:20:06 kamailio-stage-3 /usr/local/sbin/kamailio[12570]: INFO: auth [auth_mod.c:345]: mod_init(): qop set, but nonce-count (nonce_count) support disabled Nov 20 00:20:06 kamailio-stage-3 /usr/local/sbin/kamailio[12570]: INFO: rr [../outbound/api.h:52]: ob_load_api(): unable to import bind_ob - maybe module is not loaded Nov 20 00:20:06 kamailio-stage-3 /usr/local/sbin/kamailio[12570]: INFO: rr [rr_mod.c:185]: mod_init(): outbound module not available Nov 20 00:20:06 kamailio-stage-3 kamailio[12568]: ERROR: <core> [core/daemonize.c:303]: daemonize(): Main process exited before writing to pipe Nov 20 00:20:06 kamailio-stage-3 kamailio[12568]: CRITICAL: <core> [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer (0x7f09fdb43de8), called from tls: tls_init.c: ser_free(323), first free tls: tls_init.c: ser_free(323) - ignoring Nov 20 00:20:06 kamailio-stage-3 kamailio[12568]: CRITICAL: <core> [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer (0x7f09fdb44098), called from tls: tls_init.c: ser_free(323), first free tls: tls_init.c: ser_malloc(293) - ignoring Nov 20 00:20:06 kamailio-stage-3 kamailio[12568]: CRITICAL: <core> [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer (0x7f09fdb94230), called from tls: tls_init.c: ser_free(323), first free tls: tls_init.c: ser_free(323) - ignoring Nov 20 00:20:06 kamailio-stage-3 kamailio[12568]: CRITICAL: <core> [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer (0x7f09fdb41890), called from tls: tls_init.c: ser_free(323), first free tls: tls_init.c: ser_free(323) - ignoring Nov 20 00:20:06 kamailio-stage-3 kamailio[12568]: CRITICAL: <core> [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer (0x7f09fdb34998), called from tls: tls_init.c: ser_free(323), first free tls: tls_init.c: ser_free(323) - ignoring Nov 20 00:20:06 kamailio-stage-3 kamailio[12568]: CRITICAL: <core> [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer (0x7f09fdb347b8), called from tls: tls_init.c: ser_free(323), first free tls: tls_init.c: ser_free(323) - ignoring Nov 20 00:20:06 kamailio-stage-3 kamailio[12568]: CRITICAL: <core> [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer (0x7f09fdb34858), called from tls: tls_init.c: ser_free(323), first free tls: tls_init.c: ser_malloc(293) - ignoring Nov 20 00:20:06 kamailio-stage-3 kamailio[12568]: CRITICAL: <core> [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer (0x7f09fdb348f8), called from tls: tls_init.c: ser_free(323), first free tls: tls_init.c: ser_malloc(293) - ignoring Nov 20 00:20:06 kamailio-stage-3 systemd[1]: kamailio.service: Control process exited, code=killed, status=11/SEGV Nov 20 00:20:06 kamailio-stage-3 systemd[1]: kamailio.service: Failed with result 'signal'. Nov 20 00:20:06 kamailio-stage-3 systemd[1]: Failed to start kamailio (OpenSER) - the Open Source SIP Server. Nov 20 00:20:06 kamailio-stage-3 systemd[1]: kamailio.service: Service RestartSec=100ms expired, scheduling restart. Nov 20 00:20:06 kamailio-stage-3 systemd[1]: kamailio.service: Scheduled restart job, restart counter is at 57. Nov 20 00:20:06 kamailio-stage-3 systemd[1]: Stopped kamailio (OpenSER) - the Open Source SIP Server. Nov 20 00:20:06 kamailio-stage-3 systemd[1]: kamailio.service: Start request repeated too quickly. Nov 20 00:20:06 kamailio-stage-3 systemd[1]: kamailio.service: Failed with result 'signal'. Nov 20 00:20:06 kamailio-stage-3 systemd[1]: Failed to start kamailio (OpenSER) - the Open Source SIP Server. ``` ### Possible Solutions As a hack, we manually downgraded to https://www.openssl.org/source/openssl-1.0.2r.tar.gz and that seemed to allow the system to launch, but this is obviously not a stable, long-term solution. ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.4.2 (x86_64/linux) 2d733e flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, 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_BLACKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_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: 2d733e compiled on 23:01:51 Nov 19 2020 with gcc 8.3.0 ``` * **Operating System**:  ``` root@kamailio-stage-3:/home/admin# lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 10 (buster) Release: 10 Codename: buster root@kamailio-stage-3:/home/admin# uname -a Linux kamailio-stage-3 4.19.0-12-cloud-amd64 #1 SMP Debian 4.19.152-1 (2020-10-18) x86_64 GNU/Linux ubuntu@kamailio-stage-2:~$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 20.04.1 LTS Release: 20.04 Codename: focal ubuntu@kamailio-stage-2:~$ uname -a Linux kamailio-stage-2 5.4.0-1029-aws #30-Ubuntu SMP Tue Oct 20 10:06:38 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2560

3 18

[kamailio/kamailio] http_client: http_client_request to include default clientcert, clien… (#2612)
by Wolfgang Kampichler 05 Feb '21

05 Feb '21

- the lost module uses http_client API functions and in the course of NG112 client certificates are used for authentication when querying LIS or ECRF, the fix allows these to be read out via http_client module parameters.   #### 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 - [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 - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description  To use client certificates for authentication when sending HTTP requests via the http_client API function `http_client_request`, the auth. specific module parameters (default values) are not passed to curl. The fix allows these to be read out via http_client module parameters to set proper curl config parameters. Maybe it's a new feature rather than a fix. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/2612 -- Commit Summary -- * http_client: http_client_request to include default clientcert, clientkey,... -- File Changes -- M src/modules/http_client/functions.c (12) -- Patch Links -- https://github.com/kamailio/kamailio/pull/2612.patch https://github.com/kamailio/kamailio/pull/2612.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/2612

3 6

[kamailio/kamailio] Catch exceptions in cfg event_route when using tcp to transmit sip (#2614)
by zhangyang 29 Jan '21

29 Jan '21

### Description When we use tcp to transmit the regester message of softphone and kamailio, we want to check whether the softphone is disconnected in real time. At present, we can get the broken link in the log, but cannot process it from the cfg file. Can we add an Event Routes? ### Expected behavior add an Event Routes when sip tcp broke #### Log Messages this is we get log ![image](https://user-images.githubusercontent.com/16113837/106254191-661e4700-6253-11eb-9d3c-6d2a8a800ff5.png) ### Additional Information version: kamailio 5.4.2 (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, 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_BLACKLIST, HAVE_RESOLV_RES ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_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 on 20:13:39 Nov 9 2020 with gcc 4.8.5 * **Operating System**: CentOS Linux release 7.8.2003 (Core) -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2614

1 2

← Newer
1
...
6
7
8
9
10
11
12
...
19
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev January 2021