sr-dev July 2021

sr-dev@lists.kamailio.org

13 participants
227 discussions

[kamailio/kamailio] app_lua: build warning (#2728)

by sergey-safarov

``` which: no lua-config in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin) which: no lua-config in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin) CC (gcc) [M app_lua.so] app_lua_api.o app_lua_api.c: In function 'lua_sr_kemi_register_libs': app_lua_api.c:1942:2: warning: implicit declaration of function 'luaL_openlib'; did you mean 'luaL_openlibs'? [-Wimplicit-f unction-declaration] 1942 | luaL_openlib(L, "KSR", _sr_crt_KSRMethods, 0); | ^~~~~~~~~~~~ | luaL_openlibs CC (gcc) [M app_lua.so] app_lua_kemi_export.o CC (gcc) [M app_lua.so] app_lua_mod.o LD (gcc) [M app_lua.so] app_lua.so which: no lua-config in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin) which: no lua-config in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin) CC (gcc) [M app_lua_sr.so] app_lua_sr_api.o app_lua_sr_api.c: In function 'lua_sr_core_openlibs': app_lua_sr_api.c:1614:2: warning: implicit declaration of function 'luaL_openlib'; did you mean 'luaL_openlibs'? [-Wimplici t-function-declaration] 1614 | luaL_openlib(L, "sr", _sr_core_Map, 0); | ^~~~~~~~~~~~ | luaL_openlibs CC (gcc) [M app_lua_sr.so] app_lua_sr_exp.o app_lua_sr_exp.c: In function 'lua_sr_exp_openlibs': app_lua_sr_exp.c:3686:3: warning: implicit declaration of function 'luaL_openlib'; did you mean 'luaL_openlibs'? [-Wimplici t-function-declaration] 3686 | luaL_openlib(L, "sr.sl", _sr_sl_Map, 0); | ^~~~~~~~~~~~ | luaL_openlibs CC (gcc) [M app_lua_sr.so] app_lua_sr_mod.o LD (gcc) [M app_lua_sr.so] app_lua_sr.so ``` -- 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/2728

2 years, 10 months

[kamailio/kamailio] DB_UNIXODBC always reports errors for sql queries with no result set (#2810)

by kdanderso

### Description SQL queries that do not return a result set (such as INSERT, DELETE, UPDATE) always report errors when using db_unixodbc. The query succeeds, but the log indicates a failure. #### Reproduction Use db_unixodbc.so for sql queries. Issue a valid query such as INSERT that is not expected to return a result set. #### Log Messages ERROR: db_unixodbc [res.c:52]: db_unixodbc_get_columns(): no columns returned from the query ERROR: db_unixodbc [res.c:253]: db_unixodbc_convert_result(): getting column names failed ERROR: db_unixodbc [dbase.c:271]: db_unixodbc_store_result(): failed to convert result ERROR: <core> [db_query.c:197]: db_do_raw_query(): error while storing result ERROR: sqlops [sql_api.c:297]: sql_do_query(): cannot do the query [DELETE FROM mytable WHERE id = 1] ### Additional Information Kamailio Version 5.5.0 This issue was also reported to SR-users, but that user did not open an issue. (See https://lists.kamailio.org/pipermail/sr-users/2018-March/100581.html) -- 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/2810

2 years, 11 months

[kamailio/kamailio] server crashes every 10 hours (#2101)

by ekke56

### Description  ### Troubleshooting coredump data below. #### Reproduction  #### Debugging Data  ``` (gdb) bt full #0 0x000000000046ccdd in get_hash1_raw (s=0x5da51296 <Address 0x5da51296 out of bounds>, len=9) at core/hashes.h:109 p = 0x5da51296 <Address 0x5da51296 out of bounds> v = 4100353960 h = 0 #1 0x000000000046cfb6 in str_hash_get (ht=0xa6d6c0 <cnts_hash_table>, key=0x5da51296 <Address 0x5da51296 out of bounds>, len=9) at core/str_hash.h:94 h = 0 e = 0x19 #2 0x000000000046debe in cnt_hash_lookup (group=0x7ffc2db9d7c0, name=0x7eff79693b80) at core/counters.c:420 e = 0x7eff80c48c88 first = 0xbd8191bc2e950d55 cnt_rec = 0x7eff80c48cb0 #3 0x000000000046e752 in counter_lookup_str (handle=0x7ffc2db9d7d0, group=0x7ffc2db9d7c0, name=0x7eff79693b80) at core/counters.c:541 cnt_rec = 0x19 #4 0x00007eff7d65b447 in get_stat (name=0x7eff79693b80) at ../../core/counters.h:197 h = {id = 13} grp = {s = 0x0, len = 0} #5 0x00007eff7d65c113 in statsc_svalue (name=0x7eff79693b80, res=0x7eff79693f4b) at statsc_mod.c:149 stat = 0xd __FUNCTION__ = "statsc_svalue" #6 0x00007eff7d65db79 in statsc_timer (ticks=113205942, param=0x0) at statsc_mod.c:274 sm = 0x7eff79693b70 tn = 1571099286 n = 115 __FUNCTION__ = "statsc_timer" #7 0x00000000005db7f9 in sr_wtimer_exec (ticks=113205942, param=0x0) at core/timer_proc.c:390 wt = 0x7eff80c56f48 wn = 0x0 wp = 0x0 cs = 0 __FUNCTION__ = "sr_wtimer_exec" #8 0x00000000005daa29 in fork_sync_timer (child_id=-1, desc=0x7c8a71 "secondary timer", make_sock=1, f=0x5db4f2 <sr_wtimer_exec>, param=0x0, interval=1000) at core/timer_proc.c:224 pid = 0 ts1 = 1811295077 ts2 = 1000 #9 0x00000000005dbb26 in sr_wtimer_start () at core/timer_proc.c:416 __FUNCTION__ = "sr_wtimer_start" #10 0x0000000000425a33 in main_loop () at main.c:1729 i = 8 pid = 3615 si = 0x0 si_desc = "udp receiver child=7 sock=91.216.86.57:5060\000\377~\000\000@۹-\374\177\000\000\020\207A\000\000\000\000\000\020\336\271-\374\177\000\000\323c{\000\000\000\000\000\031\000\000\000\000\000\000\000\000\000\000\004\000\000\000\000\000\000\200\000\000\000\000\000__:\201\377~\000\000\250\346\260v\377~\000\000\270\314À\377~\000" nrprocs = 8 woneinit = 1 __FUNCTION__ = "main_loop" #11 0x000000000042c72a in main (argc=7, argv=0x7ffc2db9def8) at main.c:2696 cfg_stream = 0x1ee3010 c = -1 r = 0 tmp = 0x7ffc2db9ef2c "" tmp_len = 0 port = 0 proto = 0 options = 0x76a9a0 ":f:cm:M:dVIhEeb:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:x:X:Y:" ret = -1 ---Type <return> to continue, or q <return> to quit--- info locals seed = 2620966285 rfd = 4 debug_save = 0 debug_flag = 0 dont_fork_cnt = 0 n_lst = 0x2 p = 0x0 st = {st_dev = 20, st_ino = 22346, st_nlink = 2, st_mode = 16832, st_uid = 0, st_gid = 0, __pad0 = 0, st_rdev = 0, st_size = 40, st_blksize = 4096, st_blocks = 0, st_atim = {tv_sec = 1568107728, tv_nsec = 458000000}, st_mtim = { tv_sec = 1571064422, tv_nsec = 57000000}, st_ctim = {tv_sec = 1571064422, tv_nsec = 57000000}, __unused = {0, 0, 0}} __FUNCTION__ = "main" (gdb) list 104 register unsigned v; 105 register unsigned h; 106 107 h=0; 108 109 hash_update_str(s, s+len, p, v, h); 110 return hash_finish(h); 111 } 112 113 ``` #### Log Messages  ``` no relevant messages ``` #### SIP Traffic  ``` seems to be triggered by internal timer ``` ### Possible Solutions  ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.2.4 (x86_64/linux) 759867 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: 759867 compiled on 12:20:22 Sep 11 2019 with gcc 4.8.5 ``` * **Operating System**:  ``` CentOS Linux release 7.4.1708 (Core) Linux xxx 3.10.0-957.12.2.el7.x86_64 #1 SMP Tue May 14 21:24:32 UTC 2019 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/2101

2 years, 11 months

[kamailio/kamailio] Infinity read from closed socket (#2658)

by sergey-safarov

### Description I observing a case when Kamailio stop processing calls. What is found: *Lot of connections with CLOSE_WAIT state* ``` [root@sbc-13 ~]# netstat -anp | grep 5060 tcp 129 0 100.85.118.66:5060 0.0.0.0:* LISTEN 56907/kamailio tcp 153 0 100.85.118.66:5060 3.101.84.132:21929 CLOSE_WAIT - tcp 153 0 100.85.118.66:5060 3.101.84.132:32738 CLOSE_WAIT - tcp 153 0 100.85.118.66:5060 3.101.84.132:39084 CLOSE_WAIT - tcp 153 0 100.85.118.66:5060 3.101.84.132:28843 CLOSE_WAIT - tcp 153 0 100.85.118.66:5060 3.101.84.132:57939 CLOSE_WAIT - tcp 153 0 100.85.118.66:5060 3.101.84.132:27823 CLOSE_WAIT - tcp 153 0 100.85.118.66:5060 3.101.84.132:15820 CLOSE_WAIT - tcp 0 0 100.85.118.66:5060 207.244.110.239:11587 ESTABLISHED 56907/kamailio tcp 153 0 100.85.118.66:5060 3.101.84.132:11972 CLOSE_WAIT - tcp 153 0 100.85.118.66:5060 3.101.84.132:57245 CLOSE_WAIT - tcp 153 0 100.85.118.66:5060 3.101.84.132:54344 CLOSE_WAIT - tcp 153 0 100.85.118.66:5060 3.101.84.132:41416 CLOSE_WAIT - tcp 153 0 100.85.118.66:5060 3.101.84.132:3644 CLOSE_WAIT - tcp 153 0 100.85.118.66:5060 3.101.84.132:61657 CLOSE_WAIT - tcp 153 0 100.85.118.66:5060 3.101.84.132:49325 CLOSE_WAIT - tcp 153 0 100.85.118.66:5060 3.101.84.132:65334 CLOSE_WAIT - tcp 153 0 100.85.118.66:5060 3.101.84.132:48657 CLOSE_WAIT - tcp 153 0 100.85.118.66:5060 3.101.84.132:1612 CLOSE_WAIT - tcp 153 0 100.85.118.66:5060 3.101.84.132:7879 CLOSE_WAIT - tcp 153 0 100.85.118.66:5060 3.101.84.132:56626 CLOSE_WAIT - tcp 153 0 100.85.118.66:5060 3.101.84.132:57247 CLOSE_WAIT - tcp 153 0 100.85.118.66:5060 3.101.84.132:30494 CLOSE_WAIT - ``` At this time on two core server, one core loaded 100% and another core is free. And top show ``` %Cpu(s): 29.4 us, 26.5 sy ``` As about 26% CPU cycles proceed kernel call, using `strace` utility I found Kamailio process (with top CSP usage) continusly make thus kernel calls. ``` recvfrom(58, 0x7ffdb46a5ab0, 232, MSG_PEEK, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable) recvfrom(58, 0x7ffdb46a5ab0, 232, MSG_PEEK, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable) recvfrom(58, 0x7ffdb46a5ab0, 232, MSG_PEEK, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable) recvfrom(58, 0x7ffdb46a5ab0, 232, MSG_PEEK, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable) recvfrom(58, 0x7ffdb46a5ab0, 232, MSG_PEEK, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable) recvfrom(58, 0x7ffdb46a5ab0, 232, MSG_PEEK, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable) recvfrom(58, 0x7ffdb46a5ab0, 232, MSG_PEEK, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable) recvfrom(58, 0x7ffdb46a5ab0, 232, MSG_PEEK, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable) recvfrom(58, 0x7ffdb46a5ab0, 232, MSG_PEEK, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable) ``` *Then I check 58 process file descriptor* ``` [root@sbc-13 ~]# ls -la /proc/56907/fd/58 lrwx------. 1 kamailio kamailio 64 Mar 3 10:49 /proc/56907/fd/58 -> 'socket:[3931924]' ``` *Info about open socket* ``` [root@sbc-13 ~]# lsof -a -p 56907| grep 3931924 kamailio 56907 kamailio 58u IPv4 3931924 0t0 TCP ip-100-85-118-66.us-west-1.compute.internal:sip->207.244.110.239:11495 (ESTABLISHED) ``` *Info about Kamailio 56907 process* ``` [root@sbc-13 ~]# kamcmd core.ps | tail 56903 tcp receiver (generic) child=4 56904 tcp receiver (generic) child=5 56905 tcp receiver (generic) child=6 56906 tcp receiver (generic) child=7 56907 tcp main process ``` Then using gdb I have created core file and back trace here ``` (gdb) bt full #0 0x00007f07d3639b1e in recv () from /lib64/libpthread.so.0 No symbol table info available. #1 0x0000000000528817 in tcpconn_read_haproxy (c=0x7f07ce98d930) at core/tcp_main.c:953 bytes = -1 retval = 0 size = 3454406656 port = 32519 p = 0x7ef068 "" end = 0x7f07d335c4c0 <syslog> "\363\017\036\372H\201\354", <incomplete sequence \330> src_ip = 0x6e9646 <qm_shm_malloc+103> dst_ip = 0x7ffdb46a5c20 v2sig = "\r\n\r\n\000\r\nQUIT\n" hdr = {v1 = {line = "\300\304\065\323\004", '\000' <repeats 11 times>, "\370ؘ\316\004\000\000\000t\251\205\000\000\000\000\000\320[j\264\375\177\000\000\004\331m\000\000\000\000\000\320[j\264\375\177\000\000\306\331m\000\000\000\000\000\b\342u\316\a\177\000\000\000\020\346\315\a\177\000\000\367b\201\000\000\000\000\000y\251\205\000n\004\000\000\260\235\201\000\000\000\000\000\247\227\201"}, v2 = {sig = "\300\304\065\323\004\000\000\000\000\000\000", ver_cmd = 0 '\000', fam = 0 '\000', len = 0, addr = {ip4 = {src_addr = 3466123512, dst_addr = 4, src_port = 43380, dst_port = 133}, ip6 = {src_addr = "\370ؘ\316\004\000\000\000t\251\205\000\000\000\000", dst_addr = "\320[j\264\375\177\000\000\004\331m\000\000\000\000", src_port = 23504, dst_port = 46186}, unx = {src_addr = "\370ؘ\316\004\000\000\000t\251\205\000\000\000\000\000\320[j\264\375\177\000\000\004\331m\000\000\000\000\000\320[j\264\375\177\000\000\306\331m\000\000\000\000\000\b\342u\316\a\177\000\000\000\020\346\315\a\177\000\000\367b\201\000\000\000\000\000y\251\205\000n\004\000\000\260\235\201\000\000\000\000\000\247\227\201\000\000\000\000\000\240C\000\000\000\000\000\000\000\020\346", <incomplete sequence \315>, dst_addr = "\a\177\000\000PB\226\316\a\177\000\000\000\020\346\315\a\177\000\000\274\332\366\312\a\177\000\000Ȧ\351͗\002\000\000\240\370\366\312\a\177\000\000S\342\366\312\a\177\000\000@\342u\316\a\177\000\000\000\000\000\000\000\000P\225\001\000\000\000\000\000\000\000\003\000\000\000\001\b\000\000\300[j\264\375\177\000\000R\031Q\000\000\000\000\000hV\313\322\a\177\000"}}}} __func__ = "tcpconn_read_haproxy" #2 0x0000000000529cc8 in tcpconn_new (sock=58, su=0x7ffdb46a5e00, local_addr=0x7f07d2cb5668, ba=0x7f07d2cb5610, type=2, state=3) at core/tcp_main.c:1164 c = 0x7f07ce98d930 rd_b_size = 16384 ret = 32519 __func__ = "tcpconn_new" #3 0x000000000055194e in handle_new_connect (si=0x7f07d2cb5610) at core/tcp_main.c:4259 su = {s = {sa_family = 2, sa_data = ",\347\317\364n\357\000\000\000\000\000\000\000"}, sin = {sin_family = 2, sin_port = 59180, sin_addr = {s_addr = 4017026255}, sin_zero = "\000\000\000\000\000\000\000"}, sin6 = {sin6_family = 2, sin6_port = 59180, sin6_flowinfo = 4017026255, sin6_addr = {__in6_u = {__u6_addr8 = "\000\000\000\000\000\000\000\000h\360~\000\000\000\000", __u6_addr16 = {0, 0, 0, 0, 61544, 126, 0, 0}, __u6_addr32 = {0, 0, 8319080, 0}}}, sin6_scope_id = 67108864}, sas = {ss_family = 2, __ss_padding = ",\347\317\364n\357\000\000\000\000\000\000\000\000h\360~\000\000\000\000\000\000\000\000\004\000\000\000\000\360^j\264\375\177\000\000\023FU\000\000\000\000\000\230_\226\316\a\177\000\000\300\225\264\000\000\000\000\000\377\377\377\377\001\000\000\000\060٘\316\a\177\000\000\060٘\316\a\177\000\000\377\377\377\377\377\377\377\377\220^j\264\375\177\000\000\000\000\000\000\000\000\000\000\300\304\065\323\a\177\000", __ss_align = 8235966803625406752}} sock_name = {s = {sa_family = 23984, sa_data = "j\264\375\177\000\000\376\023Q\000\000\000\000"}, sin = {sin_family = 23984, sin_port = 46186, sin_addr = {s_addr = 32765}, sin_zero = "\376\023Q\000\000\000\000"}, sin6 = {sin6_family = 23984, sin6_port = 46186, sin6_flowinfo = 32765, sin6_addr = {__in6_u = {__u6_addr8 = "\376\023Q\000\000\000\000\000\310ژ\316\a\177\000", __u6_addr16 = {5118, 81, 0, 0, 56008, 52888, 32519, 0}, __u6_addr32 = {5313534, 0, 3466123976, 32519}}}, sin6_scope_id = 3454980136}, sas = {ss_family = 23984, __ss_padding = "j\264\375\177\000\000\376\023Q\000\000\000\000\000\310ژ\316\a\177\000\000(\320\356\315\a\177\000\000\030\"\202\000_\376\377\377\000\000\000\000\000\000\000\000\300\304\065\323\a\177\000\000\363:\204\000\000\000\000\000h\360~\000\000\000\000\000\000\000\000\004\000\000\000\000\360^j\264\375\177\000\000\245\222T\000\000\000\000\000\250\376\314\322\002\000\000\000\000\000\000\000\002\000\000\000Dc\201\000\241\001\000", __ss_align = 0}} sock_name_len = 32519 dst_su = 0x7f07d2cb5668 tcpconn = 0xffffffffce98d930 su_len = 16 new_sock = 58 __func__ = "handle_new_connect" #4 0x0000000000554aac in handle_io (fm=0x7f07d2ccfa40, ev=1, idx=-1) at core/tcp_main.c:4517 ret = 16 __func__ = "handle_io" #5 0x000000000051c992 in io_wait_loop_epoll (h=0xaf4760 <io_h>, t=5, repeat=0) at core/io_wait.h:1070 n = 1 r = 0 fm = 0x7f07d2ccfa40 revents = 1 __func__ = "io_wait_loop_epoll" #6 0x000000000055800f in tcp_main_loop () at core/tcp_main.c:4808 si = 0x0 r = 8 __func__ = "tcp_main_loop" #7 0x000000000042ca0b in main_loop () at main.c:1788 i = 8 pid = 0 si = 0x0 si_desc = "udp receiver child=7 sock=[2600:1f1c:6d5:aa03::7]:5060\000\061\063\062:5060)\000\000\000\000\060\000\000\000\370bj\264\375\177\000\000\020bj\264\375\177\000\000\000\334ѯ\344lFߨE\201\000\000\000\000\000\250\203\306\322k\000\000\000\363:\204\000\000\000\000\000\270o\305\322\a\177\000" nrprocs = 8 woneinit = 1 __func__ = "main_loop" #8 0x0000000000435d95 in main (argc=11, argv=0x7ffdb46a6828) at main.c:2895 cfg_stream = 0x156b2a0 c = -1 r = 0 tmp = 0x7ffdb46a6ee3 "" tmp_len = 0 port = 0 proto = 0 ahost = 0x0 aport = 0 options = 0x7f1e48 ":f:cm:M:dVIhEeb:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:x:X:Y:" ret = -1 seed = 2702569434 rfd = 4 debug_save = 0 debug_flag = 0 dont_fork_cnt = 2 n_lst = 0x7ffdb46d4268 p = 0x7f07d3309db5 <handle_intel.constprop+197> "H\205\300uf\213t$\004M\215\216\244" st = {st_dev = 24, st_ino = 19244, st_nlink = 2, st_mode = 16832, st_uid = 985, st_gid = 979, __pad0 = 0, st_rdev = 0, st_size = 40, st_blksize = 4096, st_blocks = 0, st_atim = {tv_sec = 1613817804, tv_nsec = 114998890}, st_mtim = {tv_sec = 1614768566, tv_nsec = 7667804}, st_ctim = {tv_sec = 1614768566, tv_nsec = 7667804}, __glibc_reserved = {0, 0, 0}} tbuf = '\000' <repeats 16 times>, "\214\344'\323\a\177\000\000\330Am\264\375\177\000\000\000\000\000\000 ", '\000' <repeats 19 times>, "X_\376\323\a\177\000\000\000ej\264\375\177\000\000\a\000\000\000\000\000\000\000\020U\376\323\a\177\000\000\a\000\000\000\t\000\000\000\210\351 \324\a\177\000\000\034\021\377\323\a\177\000\000\000\000\000\000\000\000\000\000H\037\377\323\a\177\000\000Pdj\264\375\177\000\000\260\344'\323\a\177\000\000\300\363\037\324\a\177\000\000\000\000\000\000\000\000\000\000\320dj\264\375\177", '\000' <repeats 26 times>, "\200W\376\323\a\177\000\000"... option_index = 12 long_options = {{name = 0x7f4056 "help", has_arg = 0, flag = 0x0, val = 104}, {name = 0x7ef4e1 "version", has_arg = 0, flag = 0x0, val = 118}, {name = 0x7f405b "alias", has_arg = 1, flag = 0x0, val = 1024}, {name = 0x7f4061 "subst", has_arg = 1, flag = 0x0, val = 1025}, {name = 0x7f4067 "substdef", has_arg = 1, flag = 0x0, val = 1026}, {name = 0x7f4070 "substdefs", has_arg = 1, flag = 0x0, val = 1027}, {name = 0x7f407a "server-id", has_arg = 1, flag = 0x0, val = 1028}, {name = 0x7f4084 "loadmodule", has_arg = 1, flag = 0x0, val = 1029}, {name = 0x7f408f "modparam", has_arg = 1, flag = 0x0, val = 1030}, {name = 0x7f4098 "log-engine", has_arg = 1, flag = 0x0, val = 1031}, {name = 0x7f40a3 "debug", has_arg = 1, flag = 0x0, val = 1032}, {name = 0x7f40a9 "cfg-print", has_arg = 0, flag = 0x0, val = 1033}, {name = 0x7f40b3 "atexit", has_arg = 1, flag = 0x0, val = 1034}, {name = 0x0, has_arg = 0, flag = 0x0, val = 0}} __func__ = "main" ``` We use enabled haproxy protocol. Loos as Kamailio does not properly close the socket when the socket closed on the client-side. ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` [root@sbc-13 ~]# kamailio -v version: kamailio 5.5.0-dev4 (x86_64/linux) 06656a 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: 06656a compiled on 04:01:58 Mar 1 2021 with gcc 8.3.1 ``` * **Operating System**: ``` [root@sbc-13 ~]# 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/2658

2 years, 11 months

[kamailio/kamailio] module_db_mysql: Allow '@' in username/password for db_url URIs (#1346)

by Florian Floimair

#### 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:  - [x] PR should be backported to stable branches - [x] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description  - It is allowed to use '@' within a username and/or a password for MySQL. Database as a Service providers like e.g. Microsoft Azure use these in usernames by default. The existing URI parser always treated the '@' as a separator between username:password and host:port/db parts of the URI. The parser now checks how many '@' characters are present in the URI and only treats the last occurence as separator for the host:port/db part. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/1346 -- Commit Summary -- * module_db_mysql: Allow '@' in username/password for db_url URIs -- File Changes -- M src/modules/db_mysql/my_uri.c (35) -- Patch Links -- https://github.com/kamailio/kamailio/pull/1346.patch https://github.com/kamailio/kamailio/pull/1346.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/1346

2 years, 11 months

[kamailio/kamailio] hostname in kubernetes (#2119)

by lazedo

### Description gethostname not accurate in kubernetes  ### Troubleshooting #### Reproduction  on a recent test with kamailio in kubernetes, found that gethostname can return only the hostname and not the fqdn. this depends on the kind of object is used (deployment/statefulset) ### Possible Solutions  the below patch fixed the issues i was having ``` diff --git a/src/modules/ipops/ipops_pv.c b/src/modules/ipops/ipops_pv.c index 5f77aa9..f65b4dd 100644 --- a/src/modules/ipops/ipops_pv.c +++ b/src/modules/ipops/ipops_pv.c @@ -455,6 +455,11 @@ if (gethostname(hbuf, 512)<0) { LM_WARN("gethostname failed - host pvs will be null\n"); return -1; + } else { + struct hostent* h; + if((h = gethostbyname(hbuf)) != NULL) { + memcpy(hbuf, h->h_name, 512); + } } hlen = strlen(hbuf); ``` ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` latest master ``` * **Operating System**:  ``` buster & centos7 ``` -- 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/2119

2 years, 11 months

[kamailio/kamailio] erlang: getting null value in erl_xbuff in response of erl_rpc request (#2069)

by vipulpatel310

### Description **I did:** I have installed kamailio 5.2.4 in ubuntu system and configured kamailio script to connect with erlang node also it sends rpc request to erlang node and get response which I have printed in a logs. ... $erl_list(L) = "two"; $erl_list(L) = "one"; xlog("L_ALERT","Before RPC: $erl_list(args=>format)\n"); erl_rpc("erlang", "list_to_tuple", "$erl_list(args)", "$erl_xbuff(repl)"); xlogl("L_ALERT","type(reply): $erl_xbuff(repl=>type), format(repl): $erl_xbuff(repl=>format)\n"); ... **Expected to happen:** Response should be get from erlang node against RPC request and it should be store in erl_xbuff. And it should be print logs like: ALERT: <script>: 501:type(reply): tuple, format(repl): {"one", "two"} **Actually happened:** Response is getting properly. but the problem is to store data into xbuff so it print logs like: ALERT: <script>: 501:type(reply): <null>, format(repl): <null> ### Troubleshooting I have check with older version 4.3.0 and it works fine. getting this problem after 5.2.0 version So, I have compare 5.2.0 and 4.3.0 version code. I found one change in pv_xbuff.c file which is creating a problem when I revert the change then it works fine. #### Reproduction It will be reproducible everytime. Just sends rpc request and get the value in xbuff. check xbuff value #### Log Messages Problem logs: ``` ALERT: <script>: Before RPC: [["one", "two"]] WARNING: <core> [core/mem/q_malloc.c:480]: qm_free(): WARNING: free(0) called from erlang: pv_xbuff.c: xavp_decode(1209) ALERT: <script>: 501:type(reply): <null>, format(repl): <null> ``` logs after change: ``` ALERT: <script>: Before RPC: [["one", "two"]] WARNING: <core> [core/mem/q_malloc.c:480]: qm_free(): WARNING: free(0) called from erlang: pv_xbuff.c: xavp_decode(1209) ALERT: <script>: 501:type(reply): tuple, format(repl): {"one", "two"} ``` ### Possible Solutions revert the 6542a367638ec5f8a2b62994f8c309e7a2533962 commit. It will work fine ### Additional Information ``` version: kamailio 5.2.4 (x86_64/linux) 759867 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: 759867 compiled on 11:52:55 Sep 4 2019 with gcc 7.4.0 ``` * **Operating System**: ``` Distributor ID: Ubuntu Description: Ubuntu 18.04 LTS Release: 18.04 Codename: bionic Linux hostname.domain.com 4.15.0-20-generic #21-Ubuntu SMP Tue Apr 24 06:16:15 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/2069

2 years, 11 months

[kamailio/kamailio] kamailio can't support send Rx_AAR for origin call (#1793)

by lsm808

Hi All, When kamailio(kamailio-5.0) receive 200 OK message, we need to send Rx_AAR for origin and term call. Rx_AAR("MT_aar_reply", "origin","",2); for origin call Rx_AAR("MT_aar_reply", "term","",2); for term call. But from source code ims_qos_mod.c, we see lots of part like below to not support for a request. Even we comments them, there are still lots of issues, could we support the scenarios like below: when kamailio receive 200 OK, we can send Rx_AAR for term and origin call. //We don't ever do AAR on request for calling scenario... if (msg->first_line.type != SIP_REPLY) { // Added by vlv // LM_DBG("Can't do AAR for call session in request\n"); // return result; } -- 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/1793

2 years, 11 months

[kamailio/kamailio] while passing different callid then actual for rtpengine_offer, rtpengine_answer and rtpengine_delete, rtpstats will not populate the stastics of rtpengine (#1788)

by Surendra Tiwari

### Description  ### Troubleshooting #### Reproduction  #### 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**:  ``` (paste your output here) ``` -- 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/1788

2 years, 11 months

[kamailio/kamailio] siptrace: option ping from nathelper do not get duplicated (#1722)

by Roman Dissauer

### Description when using kamailio with mod siptrace in trace mode, option pings from nathelper module and tls encrypted packets do not get duplicated ### Troubleshooting #### Reproduction  version: kamailio 5.1.6 (x86_64/linux) modparam("nathelper", "ping_nated_only", 0) modparam("siptrace", "trace_mode", 1) modparam("siptrace", "duplicate_uri", "sip:10.1.1.1:5888") when listening on sip:10.1.1.1:5888 all the duplicated sip packets arrive except option pings from nathelper and tls encrypted traffic (which should then be already decrypted by kamailio) ### Possible Solutions  seems that core triggers are not evaluated when using tls or nathelper option pings ### 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 6.3.0 ``` * **Operating System**:  ``` Linux AT1LKAM04 4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u6 (2018-10-08) 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/1722

2 years, 11 months

← Newer
1
...
5
6
7
8
9
10
11
...
23
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev July 2021