sr-dev October 2018

sr-dev@lists.kamailio.org

23 participants
274 discussions

[kamailio/kamailio] pipelimit module documentation error? (#1671)

by Rogelio Perez

As reported by Juan Priotti [here](https://lists.kamailio.org/pipermail/sr-users/2017-December/099727.ht… the way pipelimit actually works is: > limit * timer_interval = max req/sec However the [module documentation](https://www.kamailio.org/docs/modules/5.1.x/modules/pipelimi… can be interpreted as: > limit / timer_interval = max req/sec Is this just a documentation error or are we doing something wrong? Thanks. -- 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/1671

5 years, 4 months

[kamailio/kamailio] tr_lookup(): error parsing [{param.count, , }] (#1041)

by Sergey Lavrov

Kamailio can't parse construction like $(hdr(History-Info)[*]{param.count,,}) where delimiter is comma. I tried to use delimiter as , / ',' / "," wuthout success. ERROR: pv [pv_trans.c:2631]: tr_parse_paramlist(): invalid separator in transformation: count,,} ERROR: <core> [pvapi.c:1629]: tr_lookup(): error parsing [{param.count,,}] ERROR: <core> [pvapi.c:1010]: pv_parse_spec2(): bad tr in pvar name "hdr" ERROR: <core> [pvapi.c:1036]: pv_parse_spec2(): invalid parsing in [$(hdr(History-Info)[*]{param.count,,})] at (4) ERROR: pv [pv_trans.c:2639]: tr_parse_paramlist(): invalid name transformation: count,','}! ERROR: <core> [pvapi.c:1629]: tr_lookup(): error parsing [{param.count,','}] ERROR: <core> [pvapi.c:1010]: pv_parse_spec2(): bad tr in pvar name "hdr" ERROR: <core> [pvapi.c:1036]: pv_parse_spec2(): invalid parsing in [$(hdr(History-Info)[*]{param.count,','})] at (4) ERROR: bad config file (1 errors) ERROR: pv [pv_trans.c:2639]: tr_parse_paramlist(): invalid name transformation: count,","}! ERROR: <core> [pvapi.c:1629]: tr_lookup(): error parsing [{param.count,","}] ERROR: <core> [pvapi.c:1010]: pv_parse_spec2(): bad tr in pvar name "hdr" ERROR: <core> [pvapi.c:1036]: pv_parse_spec2(): invalid parsing in [$(hdr(History-Info)[*]{param.count,","})] at (4) kamailio -v version: kamailio 4.4.5 (x86_64/linux) f98162 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, 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: f98162 compiled on 03:47:31 Feb 27 2017 with gcc 4.8.5 -- 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/1041

5 years, 4 months

[kamailio/kamailio] sqlops blocks startup of kamailio if database unreachable (#1681)

by mihovilkolaric

### Description I´m using kamailio´s sqlops-module on a postgresql database. If the database server gets unreachable during operation, sqlops detects this and tries to reconnect: ``` 14:40:48.784 WARNING: db_postgres [km_dbase.c:259]: db_postgres_submit_query(): postgres query command failed, connection status 1, error [no connection to the server] 14:40:48.784 DEBUG: db_postgres [km_dbase.c:262]: db_postgres_submit_query(): resetting the connection to postgress server 14:40:48.784 ERROR: db_postgres [km_dbase.c:267]: db_postgres_submit_query(): 0x7f80a8093680 PQsendQuery Error: could not connect to server: Connection refused ``` and finally, when the DB comes up again, succeeds in executing queries: ``` 14:41:39.738 WARNING: db_postgres [km_dbase.c:259]: db_postgres_submit_query(): postgres query command failed, connection status 1, error [SSL connection has been closed unexpectedly] 14:41:39.739 DEBUG: db_postgres [km_dbase.c:262]: db_postgres_submit_query(): resetting the connection to postgress server 14:41:39.810 DEBUG: db_postgres [km_dbase.c:249]: db_postgres_submit_query(): sending query ok: 0x7f80a8093680 (1) ``` So, obviously the module can handle database outages well. But if the DB is already down when kamailio is started, the cyclic reconnect does not work. Instead, kamailio fails to start immediately: ``` 14:57:54.187 CRITICAL: <core> [main.c:1614]: main_loop(): Cannot fork 14:57:54.188 DEBUG: db_postgres [km_pg_con.c:112]: db_postgres_new_connection(): PQconnectdbParams(0x136bfb0) 14:57:54.188 DEBUG: <core> [core/sr_module.c:938]: init_mod_child(): idx 12 rank -1: rtimer [timer] 14:57:54.188 DEBUG: <core> [core/sr_module.c:938]: init_mod_child(): idx 12 rank -1: sqlops [timer] 14:57:54.188 DEBUG: <core> [core/sr_module.c:708]: find_mod_export_record(): found export of <db_bind_api> in module db_postgres [/usr/lib64/kamailio/modules/db_postgres.so] 14:57:54.188 DEBUG: <core> [db.c:209]: db_bind_mod(): using db bind api for db_postgres 14:57:54.188 DEBUG: <core> [db.c:314]: db_do_init2(): connection 0x7f23c0154120 not found in pool 14:57:54.188 DEBUG: db_postgres [km_pg_con.c:56]: db_postgres_new_connection(): db_id = 0x7f23c0154120 14:57:54.188 DEBUG: db_postgres [km_pg_con.c:70]: db_postgres_new_connection(): 0x7f23c0154380=pkg_malloc(80) 14:57:54.188 DEBUG: db_postgres [km_pg_con.c:84]: db_postgres_new_connection(): opening connection: postgres://xxxx:xxxx@xxxxxxxxxxxxxxxxxx 14:57:54.188 DEBUG: db_postgres [km_pg_con.c:112]: db_postgres_new_connection(): PQconnectdbParams(0x13a41e0) 14:57:54.188 ERROR: db_postgres [km_pg_con.c:115]: db_postgres_new_connection(): could not connect to server: Connection refused Is the server running on host "xxxxxxxxxxxx" () and accepting TCP/IP connections on port 5432? 14:57:54.188 ERROR: db_postgres [km_pg_con.c:148]: db_postgres_new_connection(): cleaning up 0x7f23c0154380=pkg_free() 14:57:54.188 ERROR: <core> [db.c:318]: db_do_init2(): could not add connection to the pool 14:57:54.188 ERROR: sqlops [sql_api.c:164]: sql_connect(): failed to connect to the database [cb] 14:57:54.188 ERROR: <core> [core/sr_module.c:942]: init_mod_child(): error while initializing module sqlops (/usr/lib64/kamailio/modules/sqlops.so) (idx: 12 rank: -1 desc: [timer]) 14:57:54.189 ERROR: <core> [core/pt.c:340]: fork_process(): init_child failed for process 12, pid 24036, "timer" 14:57:54.189 CRITICAL: <core> [main.c:1691]: main_loop(): cannot fork timer process 14:57:54.189 ALERT: <core> [main.c:743]: handle_sigs(): child process 24009 exited normally, status=255 14:57:54.190 ALERT: <core> [main.c:743]: handle_sigs(): child process 24010 exited normally, status=255 14:57:54.190 ALERT: <core> [main.c:743]: handle_sigs(): child process 24011 exited normally, status=255 14:57:54.191 ALERT: <core> [main.c:743]: handle_sigs(): child process 24013 exited normally, status=255 14:57:54.191 ALERT: <core> [main.c:743]: handle_sigs(): child process 24015 exited normally, status=255 14:57:54.191 ALERT: <core> [main.c:743]: handle_sigs(): child process 24019 exited normally, status=255 14:57:54.191 ALERT: <core> [main.c:743]: handle_sigs(): child process 24030 exited normally, status=255 14:57:54.192 INFO: <core> [main.c:771]: handle_sigs(): terminating due to SIGCHLD 14:57:54.192 INFO: <core> [main.c:826]: sig_usr(): signal 15 received 14:57:54.192 INFO: <core> [main.c:826]: sig_usr(): signal 15 received ``` #### Reproduction - use kamailio-script with sqlops - stop kamailio - stop database - try to start kamailio #### Log Messages see above ### Additional Information * **Kamailio Version** - output of `kamailio -v` kamailio 5.1.2 (x86_64/linux) * **Operating System**: RHEL 7.4 on x86_64 -- 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/1681

5 years, 4 months

[kamailio/kamailio] dialog: xmlrpc command to check call is alive or not. (#1697)

by Surendra Tiwari

### Description rightnow, we can check using dlg.dlg_list command whether call is alive or not but this command will return all data about dialog. There should be a xmlrpc command that will just return whether call is alive or not.  ### Expected behavior #### Actual observed behavior #### Debugging Data ``` (paste your debugging data here) ``` #### Log Messages  ``` (paste your log messages here) ``` #### SIP Traffic  ``` (paste your sip traffic here) ``` ### Possible Solutions  ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` (paste your output here) ``` * **Operating System**:  ``` root@ip-172-31-4-160:~# uname -a Linux ip-172-31-4-160 3.13.0-143-generic #192-Ubuntu SMP Tue Feb 27 10:45:36 UTC 2018 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/1697

5 years, 4 months

[kamailio/kamailio] Private memory leaking in case of topos(redis) and topoh modules enable together (#1682)

by alexey-khabulyak

### Description  I tested kamailio's topoh+topos modules. udp worker's private memory is leaking when i enable both. after a couple of hour kamailio stops and spams error messages. ### Troubleshooting kamcmd pkg.stats shows lots of real_used memory(only udp workers are leaking). #### Reproduction Enable both modules.  #### Debugging Data  #### Log Messages  ``` Oct 18 17:00:55 /usr/sbin/kamailio[20801]: ERROR: <core> [core/receive.c:162]: receive_msg(): no mem for sip_msg Oct 18 17:00:55 /usr/sbin/kamailio[20802]: ERROR: <core> [core/mem/q_malloc.c:291]: qm_find_free(): qm_find_free(0x7fe6f5bee010, 1776); Free fragment not found! Oct 18 17:00:55 /usr/sbin/kamailio[20802]: ERROR: <core> [core/mem/q_malloc.c:425]: qm_malloc(): qm_malloc(0x7fe6f5bee010, 1776) called from core: core/receive.c: receive_msg(160), module: core; Free fragment not found! ```  ### Possible Solutions  disable one of modules ### Additional Information * **/etc/default/kamailio** ``` SHM_MEMORY=512 PKG_MEMORY=64 ``` Number of children = 8 * **Parameters**: ``` loadmodule "topoh.so" modparam("topoh", "mask_key", "N2hkVvBTxJ6Y") modparam("topoh", "mask_callid", 0) modparam("topoh", "sanity_checks", 1) modparam("topoh", "uri_prefix_checks", 1) modparam("topoh", "mask_ip", MY_IP_ADDR) loadmodule "topos.so" loadmodule "topos_redis.so" modparam("topos", "storage", "redis") modparam("topos", "branch_expire", 300) modparam("topos", "dialog_expire", 10800) modparam("topos", "clean_interval", 30) modparam("topos_redis", "serverid", "topo") ``` * **Kamailio Version** - output of `kamailio -v` ``` # kamailio -v version: kamailio 5.1.6 (x86_64/linux) flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, 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, 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: unknown compiled with gcc 4.9.2 ``` * **Operating System**:  ``` Debian 8.10 ``` -- 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/1682

5 years, 5 months

[kamailio/kamailio] Crash using TLS with many child processes (#1670)

by Adrien Menella

### Description Started from the [minimal proxy config](https://github.com/kamailio/kamailio/blob/master/misc/examples/mixe…, we tried to run **more than 1** process using TLS, and, unforntunately it crashed. Everything is working fine **using TLS with 1 child**. Everything is working fine with **more than 1 child process without TLS**. To ease the reproduction, we set an env var called `TARGET` at container instanciation, its value is set to a reachable SIP address using TLS (without DNS resolution). To reproduce issue you will need pjsip/pjsua with SSL/TLS enabled: * install OpenSSL (`sudo apt-get install openssl` for ubuntu) * [install pjsip using autoconf](https://trac.pjsip.org/repos/wiki/Getting-Started/Autoconf) * [manually configure TLS support if necessary](https://trac.pjsip.org/repos/wiki/TLS) * [build and install pjsua](https://trac.pjsip.org/repos/wiki/Python_SIP/Build_Install) We've seen on some issues that a low memory allocation could be an issue using TLS, so we are running kamailio using more memory `kamailio -DD -E -M 256 -m 1024` (still crashing). ### Troubleshooting #### Reproduction Here are the steps to reproduce the issue: * start from [Kamailio minimal proxy config](https://github.com/kamailio/kamailio/blob/master/misc/examples/mixe… * enable TLS by adding/uncommenting following lines: ```diff @@ -1,4 +1,5 @@ #!KAMAILIO +#!define WITH_TLS # # Kamailio (OpenSER) SIP Server v5.2 - default configuration script # - web: https://www.kamailio.org @@ -28,7 +29,7 @@ ####### Global Parameters ######### ### LOG Levels: 3=DBG, 2=INFO, 1=NOTICE, 0=WARN, -1=ERR -debug=2 +debug=3 log_stderror=no memdbg=5 @@ -38,10 +39,13 @@ log_facility=LOG_LOCAL0 log_prefix="{$mt $hdr(CSeq) $ci} " /* number of SIP routing processes */ -children=2 +children=1 /* uncomment the next line to disable TCP (default on) */ # disable_tcp=yes +#!ifdef WITH_TLS +enable_tls=yes +#!endif /* uncomment the next line to disable the auto discovery of local aliases * based on reverse DNS on IPs (default on) */ @@ -65,6 +69,9 @@ children=2 ####### Modules Section ######## /* set paths to location of modules */ +#!ifdef WITH_TLS +loadmodule "tls.so" +#!endif loadmodule "jsonrpcs.so" loadmodule "kex.so" loadmodule "corex.so" @@ -85,6 +92,9 @@ loadmodule "counters.so" # ----------------- setting module-specific parameters --------------- +#!ifdef WITH_TLS +modparam("tls", "config", "/etc/kamailio/tls.cfg") +#!endif # ----- jsonrpcs params ----- modparam("jsonrpcs", "pretty_format", 1) @@ -180,7 +190,7 @@ request_route { } # update $du to set the destination address for proxying - $du = "sip:" + $rd + ":9"; + $du = $env(TARGET); route(RELAY); exit; } ``` * use a proper `tls.cfg` file with self-signed certificates: ```c [server:default] method = TLSv1 verify_certificate = no require_certificate = no private_key = /etc/kamailio/privkey.pem certificate = /etc/kamailio/server-cert.pem [client:default] #method = TLSv1 verify_certificate = no require_certificate = no ``` * use following `Dockerfile`: ```docker FROM kamailio/kamailio-ci:master-alpine # Override default kamailio configuration COPY kamailio.cfg /etc/kamailio/kamailio.cfg COPY tls.cfg /etc/kamailio/tls.cfg COPY privkey.pem /etc/kamailio/privkey.pem COPY server-cert.pem /etc/kamailio/server-cert.pem ``` * build docker image `docker build -f Dockerfile -t kamailio-tls-issue .` * launch docker container using your own `TARGET`: ```sh docker run -it -p 5061:5061/tcp -e "TARGET=sip:AA.BB.CC.DD;transport=tls" kamailio-tls-issue ``` * make a SIP call with pjsua: ```sh pjsua --stun-srv=stun.l.google.com:19302 --use-tls --no-tcp --no-udp --use-srtp=2 --local-port=5062 --id=sip:alice@localhost "sip:bob@localhost;transport=tls" ``` **Everything should work fine because we only used 1 child process** * stop everything * update your `kamailio.cfg` by setting `children=2` (or above) * reproduce steps (build docker image, launch container, make a SIP call) * kamailio should crash with specific logs (see `Log messages` section) #### Log Messages Log messages from kamailio proxy: ```c 11(16) DEBUG: {1 32554 INVITE 1k3Hcf7IVCnjmhjZIJXU5S0x-LRhyB2x} <script>: new branch [0] to sip:bob@localhost;transport=tls 11(16) DEBUG: {1 32554 INVITE 1k3Hcf7IVCnjmhjZIJXU5S0x-LRhyB2x} <core> [core/msg_translator.c:2933]: create_via_hf(): id added: <;i=1>, rcv proto=3 11(16) DEBUG: {1 32554 INVITE 1k3Hcf7IVCnjmhjZIJXU5S0x-LRhyB2x} <core> [core/tcp_main.c:1747]: tcp_send(): no open tcp connection found, opening new one 11(16) DEBUG: {1 32554 INVITE 1k3Hcf7IVCnjmhjZIJXU5S0x-LRhyB2x} <core> [core/ip_addr.c:229]: print_ip(): tcpconn_new: new tcp connection: 34.240.160.168 11(16) DEBUG: {1 32554 INVITE 1k3Hcf7IVCnjmhjZIJXU5S0x-LRhyB2x} <core> [core/tcp_main.c:999]: tcpconn_new(): on port 5061, type 3 11(16) DEBUG: {1 32554 INVITE 1k3Hcf7IVCnjmhjZIJXU5S0x-LRhyB2x} <core> [core/tcp_main.c:1305]: tcpconn_add(): hashes: 1752:0:0, 2 11(16) DEBUG: {1 32554 INVITE 1k3Hcf7IVCnjmhjZIJXU5S0x-LRhyB2x} tls [tls_server.c:199]: tls_complete_init(): completing tls connection initialization 11(16) DEBUG: {1 32554 INVITE 1k3Hcf7IVCnjmhjZIJXU5S0x-LRhyB2x} tls [tls_server.c:162]: tls_get_connect_server_name(): xavp with outbound server name not found 11(16) DEBUG: {1 32554 INVITE 1k3Hcf7IVCnjmhjZIJXU5S0x-LRhyB2x} tls [tls_server.c:142]: tls_get_connect_server_id(): xavp with outbound server id not found 11(16) DEBUG: {1 32554 INVITE 1k3Hcf7IVCnjmhjZIJXU5S0x-LRhyB2x} tls [tls_server.c:228]: tls_complete_init(): Using initial TLS domain TLSc<default> (dom 0x7fe7740bdaf0 ctx 0x55d98553ca40 sn []) 11(16) DEBUG: {1 32554 INVITE 1k3Hcf7IVCnjmhjZIJXU5S0x-LRhyB2x} tls [tls_domain.c:1155]: tls_lookup_private_key(): Private key lookup for SSL_CTX-0x55d98553ca40: 0 11(16) DEBUG: {1 32554 INVITE 1k3Hcf7IVCnjmhjZIJXU5S0x-LRhyB2x} tls [tls_domain.c:737]: sr_ssl_ctx_info_callback(): SSL handshake started 11(16) DEBUG: {1 32554 INVITE 1k3Hcf7IVCnjmhjZIJXU5S0x-LRhyB2x} <core> [core/tcp_main.c:2641]: tcpconn_1st_send(): pending write on new connection 0x7fe7742cd200 (-1/122 bytes written) (err: 11 - Resource temporarily unavailable) 13(18) DEBUG: <core> [core/tcp_main.c:3540]: handle_ser_child(): read response= 7fe7742cd200, 5, fd 29 from 11 (16) 13(18) DEBUG: <core> [core/io_wait.h:380]: io_watch_add(): DBG: io_watch_add(0x55d984d52f20, 29, 2, 0x7fe7742cd200), fd_no=18 11(16) DEBUG: {1 32554 INVITE 1k3Hcf7IVCnjmhjZIJXU5S0x-LRhyB2x} tm [t_funcs.c:372]: t_relay_to(): new transaction forwarded 11(16) DEBUG: {1 32554 INVITE 1k3Hcf7IVCnjmhjZIJXU5S0x-LRhyB2x} <core> [core/receive.c:353]: receive_msg(): request-route executed in: 10827 usec 11(16) DEBUG: {1 32554 INVITE 1k3Hcf7IVCnjmhjZIJXU5S0x-LRhyB2x} <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list 0 11(16) DEBUG: {1 32554 INVITE 1k3Hcf7IVCnjmhjZIJXU5S0x-LRhyB2x} <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list 0 11(16) DEBUG: {1 32554 INVITE 1k3Hcf7IVCnjmhjZIJXU5S0x-LRhyB2x} <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list 0 11(16) DEBUG: {1 32554 INVITE 1k3Hcf7IVCnjmhjZIJXU5S0x-LRhyB2x} <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list 0 11(16) DEBUG: {1 32554 INVITE 1k3Hcf7IVCnjmhjZIJXU5S0x-LRhyB2x} <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list 0 11(16) DEBUG: {1 32554 INVITE 1k3Hcf7IVCnjmhjZIJXU5S0x-LRhyB2x} <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list 0 11(16) DEBUG: {1 32554 INVITE 1k3Hcf7IVCnjmhjZIJXU5S0x-LRhyB2x} <core> [core/xavp.c:495]: xavp_destroy_list(): destroying xavp list 0 11(16) DEBUG: {1 32554 INVITE 1k3Hcf7IVCnjmhjZIJXU5S0x-LRhyB2x} <core> [core/receive.c:457]: receive_msg(): cleaning up 13(18) DEBUG: <core> [core/io_wait.h:777]: io_watch_chg(): DBG: io_watch_chg (0x55d984d52f20, 29, 0x1, 0xffffffff) fd_no=19 called 13(18) DEBUG: <core> [core/io_wait.h:602]: io_watch_del(): DBG: io_watch_del (0x55d984d52f20, 29, -1, 0x0) fd_no=19 called 13(18) DEBUG: <core> [core/tcp_main.c:4196]: handle_tcpconn_ev(): sending to child, events 1 13(18) DEBUG: <core> [core/tcp_main.c:3875]: send2child(): selected tcp worker 1 12(17) for activity on [tls:172.17.0.2:5061], 0x7fe7742cd200 12(17) DEBUG: <core> [core/tcp_read.c:1767]: handle_io(): received n=8 con=0x7fe7742cd200, fd=7 13(18) DEBUG: <core> [core/tcp_main.c:3279]: handle_tcp_child(): dead tcp child 1 (pid 17, no 12) (shutting down?) 13(18) DEBUG: <core> [core/io_wait.h:602]: io_watch_del(): DBG: io_watch_del (0x55d984d52f20, 27, -1, 0x0) fd_no=18 called 13(18) CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 24 13(18) DEBUG: <core> [core/tcp_main.c:3512]: handle_ser_child(): dead child 12, pid 17 (shutting down?) 13(18) DEBUG: <core> [core/io_wait.h:602]: io_watch_del(): DBG: io_watch_del (0x55d984d52f20, 24, -1, 0x0) fd_no=17 called 0(1) ALERT: <core> [main.c:740]: handle_sigs(): child process 17 exited by a signal 11 0(1) ALERT: <core> [main.c:743]: handle_sigs(): core was generated 0(1) INFO: <core> [main.c:766]: handle_sigs(): terminating due to SIGCHLD 0(1) DEBUG: <core> [main.c:768]: handle_sigs(): terminating due to SIGCHLD 10(15) INFO: <core> [main.c:821]: sig_usr(): signal 15 received 1(6) INFO: <core> [main.c:821]: sig_usr(): signal 15 received 8(13) INFO: <core> [main.c:821]: sig_usr(): signal 15 received 7(12) INFO: <core> [main.c:821]: sig_usr(): signal 15 received 6(11) INFO: <core> [main.c:821]: sig_usr(): signal 15 received 5(10) INFO: <core> [main.c:821]: sig_usr(): signal 15 received 4(9) INFO: <core> [main.c:821]: sig_usr(): signal 15 received 3(8) INFO: <core> [main.c:821]: sig_usr(): signal 15 received 13(18) INFO: <core> [main.c:821]: sig_usr(): signal 15 received 9(14) INFO: <core> [main.c:821]: sig_usr(): signal 15 received 11(16) INFO: <core> [main.c:821]: sig_usr(): signal 15 received 2(7) INFO: <core> [main.c:821]: sig_usr(): signal 15 received 0(1) DEBUG: tm [t_funcs.c:85]: tm_shutdown(): start 0(1) DEBUG: tm [t_funcs.c:88]: tm_shutdown(): emptying hash table 0(1) DEBUG: tm [h_table.c:133]: free_cell_helper(): freeing transaction 0x7fe7742c9580 from h_table.c:465 0(1) DEBUG: tm [t_funcs.c:90]: tm_shutdown(): removing semaphores 0(1) DEBUG: tm [t_funcs.c:92]: tm_shutdown(): destroying tmcb lists 0(1) DEBUG: tm [t_funcs.c:95]: tm_shutdown(): done ``` ### Additional Information * **Kamailio Version** : Kamailio (OpenSER) SIP Server v5.2 * **Operating System**: Kamailio was running on Linux Alpine from [kamailio/kamailio-ci:master-alpine](https://hub.docker.com/r/kamailio/kamai… docker image. -- 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/1670

5 years, 5 months

[kamailio/kamailio] Wrong QOP value in UAC auth_alg (#1684)

by Sebastian Lauwers

### Description While trying to setup a handoff to a third party SIP trunk with authentication, I ran into some issues with said authentication. I'm using qop auth on the inbound leg (and `consume_credentials()`), and then UAC to authenticate against the SIP trunk with different credentials. The third party SIP trunk offers qop auth/auth-int. I manually tried to verify the digest that Kamailio was sending, but couldn't. I added some logging to the `auth_alg.c` file, and ran the whole thing again. HA1 is calculated correctly, and so is HA2. However, the final step of the algorithm produced an incorrect value. After further debugging, I realised that the issue comes from https://github.com/kamailio/kamailio/blob/master/src/modules/uac/auth_alg.c…. More specifically, in my case, the value passed on to `MD5Update` is `auth,auth-int`, instead of the simple `auth` I was expecting (uac doesn't support auth-int). ### Troubleshooting #### SIP Traffic I have PCAPs demonstrating the issue and the hack/fix below. I'd rather not post them publicly, however, I am happy to share them privately with Kamailio devs. In essence: ``` -> INVITE sip:12345@someprovider.org:5060;transport=tcp <- 401 Unauthorized WWW-Authenticate: Digest realm="someprovider.org", qop="auth,auth-int", nonce="5BCF48671749b873534dc63e76d5594f3988555f" -> INVITE sip:12345@someprovider.org:5060;transport=tcp Authorization: Digest username="redacted", realm="someprovider.org", nonce="5BCF48671749b873534dc63e76d5594f3988555f", uri="sip:12345@eu.out.didww.com:5060;transport=tcp", qop=auth, nc=00000001, cnonce="2106889321", response="redacted71d4c9ce119dcf3ec56209e", algorithm=MD5 ``` ### Possible Solutions The hack I've used for the time being is to replace: ```c MD5Update(&Md5Ctx, ":", 1); MD5Update(&Md5Ctx, auth->qop.s, auth->qop.len); MD5Update(&Md5Ctx, ":", 1); ``` with: ```c MD5Update(&Md5Ctx, ":auth:", 6); ``` Obviously, I realise this is not the correct fix, but I figured I'd let the experts fix the value of `auth->qop.len`. I can spend more time on this, if required, but I don't know exactly what the "correct" solution is. ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.1.6 (x86_64/linux) flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, 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, 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: unknown compiled with gcc 5.3.1 ``` * **Operating System**: Dockerized version of Kamailio on Ubuntu xenial: ``` kamailio/kamailio:5.1.6-xenial ``` -- 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/1684

5 years, 5 months

[kamailio/kamailio] erlang: build fails on alpha (#1373)

by Victor Seva

>From 5.1.0 official Debian build ``` /usr/bin/make every-module group_include="kerlang" quiet=verbose make[1]: Entering directory '/<<PKGBUILDDIR>>' /usr/bin/make -C src/ every-module make[2]: Entering directory '/<<PKGBUILDDIR>>/src' config.mak loaded Makefile.defs defs skipped Makefile.defs defs skipped Makefile.defs defs skipped beam.smp: allocatestack.c:480: allocate_stack: Assertion `size != 0' failed. Aborted beam.smp: allocatestack.c:480: allocate_stack: Assertion `size != 0' failed. Aborted Makefile:16: *** Not found Erlang. Stop. ``` -- 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/1373

5 years, 5 months

error in Makefile.modules

by Juha Heinanen

When building debian package from master, I noticed this kind of error message: s ../../../doc/stylesheets/serdoc2man.xsl auth.xml make[3]: s: Command not found ../../Makefile.modules:283: recipe for target 'auth.7' failed The line in Makefile.modules is here: $(MOD_NAME).7: $(MOD_NAME).xml $(DOCBOOK) -s ../../../doc/stylesheets/serdoc2man.xsl $< Could it be that variable $(DOCBOOK) has not been defined? -- Juha

5 years, 5 months

[kamailio/kamailio] Crash ims_diameter_server module (#1686)

by iman432

Hi dears When the below format from restful is sent, kamailio crashes List List List (Json with 3 lists), With 2 lists it works properly, When diameter is translated to json with 3 lists by this module it also works properly, Json format is correct too. Where is problem? Thanks -- 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/1686

5 years, 5 months

← Newer
1
...
4
5
6
7
8
9
10
...
28
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev October 2018