sr-dev August 2016

sr-dev@lists.kamailio.org

25 participants
197 discussions

[kamailio] [4.2.6] kamailio does not work when Recv-Q is high... (#510)

by BroWater

Steps: (1) 9 users and 1 mcu registered the server (2) All 9 users connect to the mcu through the server (3) For a while, some users showed registration fail, we found Kamailio does not respond to any further SIP message. I checked this using `netstat -apn` and it showed: ``` Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 10.100.92.42:5060 0.0.0.0:* LISTEN 9384/kamailio tcp 0 0 10.100.92.42:5061 0.0.0.0:* LISTEN 9384/kamailio tcp 48963 0 10.100.92.42:5060 10.100.92.42:42177 ESTABLISHED 9375/kamailio tcp 29621 0 10.100.92.42:5060 10.100.92.40:34392 ESTABLISHED 9375/kamailio tcp 1617 0 10.100.92.42:43997 10.100.92.42:5062 ESTABLISHED 9375/kamailio tcp 2506 0 10.100.92.42:5060 10.100.92.68:37386 ESTABLISHED 9383/kamailio udp 0 0 127.0.0.1:50180 127.0.0.1:7722 ESTABLISHED 9384/kamailio udp 0 0 127.0.0.1:47125 127.0.0.1:7722 ESTABLISHED 9378/kamailio udp 0 0 127.0.0.1:55318 127.0.0.1:7722 ESTABLISHED 9375/kamailio udp 0 0 127.0.0.1:44595 127.0.0.1:7722 ESTABLISHED 9382/kamailio udp 0 0 127.0.0.1:41045 127.0.0.1:7722 ESTABLISHED 9383/kamailio udp 0 0 127.0.0.1:52901 127.0.0.1:7722 ESTABLISHED 9380/kamailio udp 0 0 127.0.0.1:39078 127.0.0.1:7722 ESTABLISHED 9376/kamailio udp 0 0 127.0.0.1:36548 127.0.0.1:7722 ESTABLISHED 9377/kamailio udp 0 0 127.0.0.1:55005 127.0.0.1:7722 ESTABLISHED 9374/kamailio udp 0 0 127.0.0.1:53049 127.0.0.1:7722 ESTABLISHED 9381/kamailio udp 0 0 127.0.0.1:44358 127.0.0.1:7722 ESTABLISHED 9374/kamailio udp 0 0 127.0.0.1:60253 127.0.0.1:7722 ESTABLISHED 9379/kamailio udp 0 0 10.100.92.42:5060 0.0.0.0:* 9374/kamailio udp 0 0 ::ffff:127.0.0.1:7722 :::* 9354/rtpengine raw 0 0 0.0.0.0:255 0.0.0.0:* 255 9374/kamailio ``` And I attached the gdb to the those processed which Recv-Q value were high, it showed: PID [9375] ``` #0 0x400a7450 in recvfrom () from /lib/libpthread.so.0 No symbol table info available. #1 0x00265848 in udp_rcv_loop () at udp_server.c:446 len = 472 buf = "REGISTER sip:10.100.92.42:5060 SIP/2.0\r\nVia: SIP/2.0/UDP 10.100.91.13:5060;rport;branch=z9hG4bK649620372\r\nFrom: <sip:DEMOROOM_2@10.100.92.42>;tag=658334621\r\nTo: <sip:DEMOROOM_2@10.100.92.42>\r\nCall-ID:"... tmp = 0x49fbfc "10.100.92.43" from = 0x402d5b24 fromlen = 16 ri = {src_ip = {af = 2, len = 4, u = {addrl = {224093194, 3200776404, 1935216, 1734536862}, addr32 = {224093194, 3200776404, 1935216, 1734536862}, addr16 = {25610, 3419, 63700, 48839, 34672, 29, 61086, 26466}, addr = "\nd[\r\324\370\307\276p\207\035\000\236\356bg"}}, dst_ip = {af = 2, len = 4, u = {addrl = {710697994, 0, 0, 0}, addr32 = {710697994, 0, 0, 0}, addr16 = {25610, 10844, 0, 0, 0, 0, 0, 0}, addr = "\nd\\*", '\000' <repeats 11 times>}}, src_port = 5060, dst_port = 5060, proto_reserved1 = 0, proto_reserved2 = 0, src_su = {s = {sa_family = 2, sa_data = "\023\304\nd[\r\000\000\000\000\000\000\000"}, sin = { sin_family = 2, sin_port = 50195, sin_addr = {s_addr = 224093194}, sin_zero = "\000\000\000\000\000\000\000"}, sin6 = {sin6_family = 2, sin6_port = 50195, sin6_flowinfo = 224093194, sin6_addr = {__in6_u = {__u6_addr8 = '\000' <repeats 15 times>, __u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}, sin6_scope_id = 0}}, bind_address = 0x40261e14, proto = 1 '\001'} __FUNCTION__ = "udp_rcv_loop" #2 0x000c90a0 in main_loop () at main.c:1629 i = 0 pid = 0 si = 0x40261e14 si_desc = "udp receiver child=0 sock=10.100.92.42:5060\000\244\372\307\276\304y2A\000\000,\000\000\000X\000 \000\062@ \313'@h\t;\000\230\325&@\000\000\000\000x\021\002\000\060K1@\000\000\000\000d\372\307\276\260\275'\000\230\331\070\000X\311\070\000\030\000\000\000\000PVA\000\000\000\000\000\000\a@Lu\223A" r = 1074200576 nrprocs = 1 __FUNCTION__ = "main_loop" #3 0x000d0830 in main (argc=5, argv=0xbec7fd04) at main.c:2581 cfg_stream = 0x4b5008 c = -1 r = 0 tmp = 0x40070ac4 "P\002\006@\a" tmp_len = -1094190232 port = 1074045560 proto = -1094190164 options = 0x383880 ":f:cm:M:dVIhEeb:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:" ret = -1 seed = 3985271057 rfd = 206 debug_save = 0 debug_flag = 0 dont_fork_cnt = 0 n_lst = 0x0 p = 0x5 <Address 0x5 out of bounds> __FUNCTION__ = "main" ``` PID [9383] ``` #0 0x400a6a04 in __lll_lock_wait () from /lib/libpthread.so.0 #1 0x400a10b8 in pthread_mutex_lock () from /lib/libpthread.so.0 #2 0x002145b4 in tcpconn_do_send (fd=21, c=0x41969534, buf=0x402cbcb0 "SIP/2.0 200 Keepalive\r\nVia: SIP/2.0/TCP 10.100.92.42:5062;rport=42177;branch=z9hG4bK416855936;received=10.100.92.42\r\nFrom: <sip:10.100.92.42:42177>;tag=1996784611\r\nTo: <sip:10.100.92.42:5060>;tag=e926"..., len=340, send_flags=..., resp=0xbec7daf8, locked=0) at tcp_main.c:2520 #3 0x002130f0 in tcpconn_send_put (c=0x41969534, buf=0x402cbcb0 "SIP/2.0 200 Keepalive\r\nVia: SIP/2.0/TCP 10.100.92.42:5062;rport=42177;branch=z9hG4bK416855936;received=10.100.92.42\r\nFrom: <sip:10.100.92.42:42177>;tag=1996784611\r\nTo: <sip:10.100.92.42:5060>;tag=e926"..., len=340, send_flags=...) at tcp_main.c:2377 #4 0x002105c0 in tcp_send (dst=0xbec7e38c, from=0x0, buf=0x402cbcb0 "SIP/2.0 200 Keepalive\r\nVia: SIP/2.0/TCP 10.100.92.42:5062;rport=42177;branch=z9hG4bK416855936;received=10.100.92.42\r\nFrom: <sip:10.100.92.42:42177>;tag=1996784611\r\nTo: <sip:10.100.92.42:5060>;tag=e926"..., len=340) at tcp_main.c:2133 #5 0x40e33164 in msg_send (dst=0xbec7e38c, buf=0x402cbcb0 "SIP/2.0 200 Keepalive\r\nVia: SIP/2.0/TCP 10.100.92.42:5062;rport=42177;branch=z9hG4bK416855936;received=10.100.92.42\r\nFrom: <sip:10.100.92.42:42177>;tag=1996784611\r\nTo: <sip:10.100.92.42:5060>;tag=e926"..., len=340) at ../../forward.h:225 #6 0x40e362e8 in sl_reply_helper (msg=0x40342814, code=200, reason=0x402e1d6c "Keepalive", tag=0x0) at sl_funcs.c:224 #7 0x40e373e0 in sl_send_reply (msg=0x40342814, code=200, reason=0x402e1d6c "Keepalive") at sl_funcs.c:327 #8 0x40e2b30c in w_sl_send_reply (msg=0x40342814, p1=0x40282108 "\244\324(@\001", p2=0x40282140 "d\320(@ ") at sl.c:236 #9 0x00029b90 in do_action (h=0xbec7f110, a=0x4028cf34, msg=0x40342814) at action.c:1100 #10 0x00036ce8 in run_actions (h=0xbec7f110, a=0x4028cf34, msg=0x40342814) at action.c:1583 #11 0x00029a2c in do_action (h=0xbec7f110, a=0x4028d120, msg=0x40342814) at action.c:1079 #12 0x00036ce8 in run_actions (h=0xbec7f110, a=0x40288ed8, msg=0x40342814) at action.c:1583 #13 0x000263ac in do_action (h=0xbec7f110, a=0x40279db8, msg=0x40342814) at action.c:712 #14 0x00036ce8 in run_actions (h=0xbec7f110, a=0x4027321c, msg=0x40342814) at action.c:1583 #15 0x00037538 in run_top_route (a=0x4027321c, msg=0x40342814, c=0x0) at action.c:1669 #16 0x0013ce80 in receive_msg ( buf=0x41969714 "OPTIONS sip:10.100.92.42:5060 SIP/2.0\r\nVia: SIP/2.0/TCP 10.100.92.42:5062;rport;branch=z9hG4bK416855936\r\nFrom: <sip:10.100.92.42:42177>;tag=1996784611\r\nTo: <sip:10.100.92.42:5060>\r\nCall-ID: 2059319404"..., len=404, rcv_info=0x4196955c) at receive.c:216 #17 0x00248fbc in receive_tcp_msg ( tcpbuf=0x41969714 "OPTIONS sip:10.100.92.42:5060 SIP/2.0\r\nVia: SIP/2.0/TCP 10.100.92.42:5062;rport;branch=z9hG4bK416855936\r\nFrom: <sip:10.100.92.42:42177>;tag=1996784611\r\nTo: <sip:10.100.92.42:5060>\r\nCall-ID: 2059319404"..., len=404, rcv_info=0x4196955c, con=0x41969534) at tcp_read.c:1230 #18 0x0024c484 in tcp_read_req (con=0x41969534, bytes_read=0xbec7f714, read_flags=0xbec7f70c) at tcp_read.c:1431 #19 0x0024fdd8 in handle_io (fm=0x403321ac, events=1, idx=-1) at tcp_read.c:1655 #20 0x0023f814 in io_wait_loop_epoll (h=0x47d90c, t=2, repeat=0) at io_wait.h:1073 #21 0x00250fc8 in tcp_receive_loop (unix_sock=22) at tcp_read.c:1764 #22 0x00234674 in tcp_init_children () at tcp_main.c:4879 #23 0x000c9dec in main_loop () at main.c:1714 #24 0x000d0830 in main (argc=5, argv=0xbec7fd04) at main.c:2581 ``` In process 9375, I found it got stuck in recvfrom () (udp_server.c:446), and the code is: `len=recvfrom(bind_address->socket, buf, BUF_SIZE, 0, &from->s,&fromlen);` It seems operate using blocking mode instead of a non-blocking one, why??? Or maybe I miss a packet-check function like select() or poll()?? Thanks in advance. :) --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/510

8 years, 3 months

[kamailio/kamailio] textops: get_body_part doesn't detect multipart headers ending (#564)

by foucse

When I use get_body_part on a multipart body, it doesn't detect properly the ending of multipart headers: For instance in: ``` --vvemeemm0wqr7ayc5h367f3v8e66mc9t Content-Type: application/sdp Content-Length: 479 v=0 o=- 3669362310 3669362310 IN IP4 192.168.2.4 [...] ``` "Content-Length: 479" is taken into get_body_part("application/sdp", "$var(sdp)"); I will try to provide more details later. --- 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/564

8 years, 3 months

[kamailio/kamailio] Calling jsonrpc_notification fail in failure route when fr_timer timeout (#713)

by Ian Yu-Hsun Lin

## Environment Kamailio 4.3.3 Ubuntu 14.04.1 x86_64 ## Problem I'm using `t_suspend()` and `t_continue()` for mobile push notification scenario. Before calling `t_suspend()` I set the `fr_timer` to 12 seconds and `t_on_failure()` to my custom failure route (e.g. `failure_route[MY_FAILURE_ROUTE]`). The scenario is fairly similar to [[SR-Users] Timeout after t_suspend and failure route][1], the only difference is I try to use `jsonrpc_notificaion()` to notify the user asynchronously in my custom failure route. There are 2 different results depending on how it goes to the failure route: 1. Caller cancel the call before `fr_timer` expires - `jsonrpc_notification` can successfully be called in failure route 2. The `fr_timer` did timeout after 12 seconds - An error occurred while calling `jsonrpc_notification`: - `jsonrpc_notification(): failed to write to io pipe: Bad file descriptor` ## Investigation For the first case that perform normally, the IDs of Kamailio processes being used are the same for both **calling t_suspend()** and **entering failure route**, while in the second case the processes are different. Following added some debug messages in Kamailio's `main.c` it showed that the process being used in the failure route of case 2 is `slow timer process`, and from `jsonrpc_mod.c`'s `child_init()` function, the rank of `slow timer process` is **-1** therefore it doesn't assign the `fd` to this process. My workaround was just assigning the `fd` to each child during `child_init()` in `jsonrpc_mod.c` but that's definitely not a good way to go. I am appreciated if you can give me some advice to solve this problem correctly. Cheers, Ian [1]: http://lists.sip-router.org/pipermail/sr-users/2015-March/087519.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/713

8 years, 3 months

[kamailio/kamailio] Kamailio 4.4) sipcapture_module: ERROR: parse_msg: message=<HEP3#003�> (#599)

by goseeped

The sipcapture module works great when you send hepv3 packets over the UDP transport however if kamailio start listening those hepv3 packtes on TCP and sending those hepv3 on TCP it will concern about it. **This is what Kamilio receives over TCP.** > T 52.10.155.177:47283 -> 172.19.8.21:9060 [AP] > HEP3.0................... > ......... > ...........[............. > W*y6... > . > ..h...... > .................OPTIONS sip:edge.rarevase.com;transport=tcp SIP/2.0. > Via: SIP/2.0/TCP 172.19.16.130:53083;rport;branch=z9hG4bKPj66df463f-ca4b-4f98-ba17-722fe3fc4a92;alias. > From: <sip:asterisk@172.19.16.130>;tag=86ebab1d-eb4e-4986-898d-c7392b6b747b. > To: <sip:edge.rarevase.com>. > Contact: <sip:asterisk@172.19.16.130:53083;transport=TCP>. > Call-ID: ed24ab3c-4f42-4a9d-8e2d-9a3acd5b5b70. > CSeq: 3809 OPTIONS. > Max-Forwards: 70. > User-Agent: Asterisk PBX 13.8.0. > Content-Length: 0. > . > > ## > T 52.10.155.177:47283 -> 172.19.8.21:9060 [AP] > HEP3.\................... > ......... > ...................[..... > W*y6... > . > ..|...... > .................SIP/2.0 200 OK. > Via: SIP/2.0/TCP 172.19.16.130:53083;rport=53083;received=172.19.16.130;branch=z9hG4bKPj66df463f-ca4b-4f98-ba17-722fe3fc4a92;alias. > From: <sip:asterisk@172.19.16.130>;tag=86ebab1d-eb4e-4986-898d-c7392b6b747b. > To: <sip:edge.rarevase.com>;tag=24voZr. > Call-ID: ed24ab3c-4f42-4a9d-8e2d-9a3acd5b5b70. > CSeq: 3809 OPTIONS. > Max-Forwards: 70. > Content-Length: 0. > Supported: path,gruu,outbound. > Accept: */*. > Allow: INVITE,ACK,CANCEL,BYE,OPTIONS,INFO,UPDATE,SUBSCRIBE,NOTIFY,REFER,MESSAGE,REGISTER. > . > **This are the logs on the Kamailio.** `May 4 22:44:05 ip-172-19-8-21 /usr/sbin/kamailio[19285]: INFO: <core> [parser/parse_fline.c:144]: parse_first_line(): ERROR:parse_first_line: method not followed by SP May 4 22:44:05 ip-172-19-8-21 /usr/sbin/kamailio[19285]: ERROR: <core> [parser/parse_fline.c:257]: parse_first_line(): parse_first_line: bad message (offset: 0) May 4 22:44:05 ip-172-19-8-21 /usr/sbin/kamailio[19285]: DEBUG: <core> [parser/msg_parser.c:604]: parse_msg(): parse_msg: invalid message May 4 22:44:05 ip-172-19-8-21 /usr/sbin/kamailio[19285]: ERROR: <core> [parser/msg_parser.c:690]: parse_msg(): ERROR: parse_msg: message=<HEP3#003<98>> May 4 22:44:05 ip-172-19-8-21 /usr/sbin/kamailio[19285]: ERROR: <core> [receive.c:173]: receive_msg(): core parsing of SIP message failed (52.10.155.177:59607/2)` --- 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/599

8 years, 3 months

[kamailio/kamailio] move kamailio/utils/misc/vim/ to a git submodule (#763)

by Marcelo D Montu

The Vim plugin is very nice, and its use isn't restricted to machines where Kamailio is installed, as the config file can be edited via network (e.g.: using netrw plugin). Currently the most common approach to retrieve a Vim plugin is to clone its GitHub repo and use some plugin manager, such as [pathogen](https://github.com/tpope/vim-pathogen). But it clearly doesn't make sense to retrieve the complete Kamailio repo only to use the vim plugin; this probably caused the creation of [duplicates](https://github.com/eloycoto/vim-ser). I actually find that duplicate first, and then noticed on its README that there is an official (and newer) version here. Do you find acceptable to move it to a [git submodule](https://git-scm.com/book/en/v2/Git-Tools-Submodules)? -- 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/763

8 years, 3 months

[kamailio/kamailio] preprocessor directives and !trydef names (#743)

by lazedo

hi, in top level kamailio config file (kamailio.cfg) i have this defined ``` #!ifdef TRAFFIC_FILTER-ROLE include_file "traffic-filter-role.cfg" #!endif ... ####### Routing Logic ######## route { ... #!ifdef TRAFFIC_FILTER-ROLE route(TRAFFIC_FILTER); #!endif ... } ``` and in "traffic-filter-role.cfg" i have ``` route[TRAFFIC_FILTER] { ... } ``` it seems that kamailio thinks that `TRAFFIC_FILTER-ROLE` and `TRAFFIC_FILTER` are the same. ``` 0(8619) : <core> [cfg.y:3368]: yyerror_at(): parse error in config file traffic-filter-role.cfg, line 1, column 7: syntax error 0(8619) : <core> [cfg.y:3368]: yyerror_at(): parse error in config file traffic-filter-role.cfg, line 1, column 7: invalid route statement 0(8619) : <core> [cfg.y:3365]: yyerror_at(): parse error in config file traffic-filter-role.cfg, line 1, column 8-11: ERROR: bad config file (3 errors) 0(8619) WARNING: <core> [ppcfg.c:221]: pp_ifdef_level_check(): different number of preprocessor directives: N(#!IF[N]DEF) - N(#!ENDIF) = 1 ``` if i change `TRAFFIC_FILTER-ROLE` to `TRAFFIC_FILTER_ROLE` then all is good. is '-' character reserved in the syntax and kamailio assumes the string ended there ? kamailio should either accept '-' has part of the defines or throw error when parsing the `TRAFFIC_FILTER-ROLE` and send something like 'invalid name in trydef' to the output -- 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/743

8 years, 3 months

[kamailio/kamailio] Segfault when working as sipcapture node (#723)

by Sebastian Damm

We are running Kamailio 4.4.2 as a sipcapture node and every now and then it crashes. This is what the backtrace says: ``` (gdb) bt #0 get_str_fparam (dst=dst@entry=0x7ffe50aa0610, msg=msg@entry=0x7f105b8654b8, param=param@entry=0x1a) at sr_module.c:1650 #1 0x00007f1059213346 in w_report_capture (_m=0x7f105b8654b8, _table=0x7f105b8648b8 " \250q[\020\177", _corr=0x7f105b864938 "\230\237q[\020\177", _data=0x1a <Address 0x1a out of bounds>) at sipcapture.c:1040 #2 0x000000000042b618 in do_action (h=h@entry=0x7ffe50aa3ab0, a=a@entry=0x7f105b719640, msg=msg@entry=0x7f105b8654b8) at action.c:1060 #3 0x000000000042a10a in run_actions (h=h@entry=0x7ffe50aa3ab0, a=0x7f105b718530, msg=msg@entry=0x7f105b8654b8) at action.c:1549 #4 0x000000000042bcf2 in do_action (h=h@entry=0x7ffe50aa3ab0, a=a@entry=0x7f105b71a1e8, msg=msg@entry=0x7f105b8654b8) at action.c:1049 #5 0x000000000042a10a in run_actions (h=h@entry=0x7ffe50aa3ab0, a=0x7f105b71a1e8, msg=msg@entry=0x7f105b8654b8) at action.c:1549 #6 0x000000000042bcf2 in do_action (h=h@entry=0x7ffe50aa3ab0, a=a@entry=0x7f105b71a318, msg=msg@entry=0x7f105b8654b8) at action.c:1049 #7 0x000000000042a10a in run_actions (h=h@entry=0x7ffe50aa3ab0, a=0x7f105b71a318, msg=msg@entry=0x7f105b8654b8) at action.c:1549 #8 0x000000000042bcf2 in do_action (h=h@entry=0x7ffe50aa3ab0, a=a@entry=0x7f105b71a448, msg=msg@entry=0x7f105b8654b8) at action.c:1049 #9 0x000000000042a10a in run_actions (h=h@entry=0x7ffe50aa3ab0, a=0x7f105b71a448, msg=msg@entry=0x7f105b8654b8) at action.c:1549 #10 0x000000000042bcf2 in do_action (h=h@entry=0x7ffe50aa3ab0, a=a@entry=0x7f105b71a578, msg=msg@entry=0x7f105b8654b8) at action.c:1049 #11 0x000000000042a10a in run_actions (h=h@entry=0x7ffe50aa3ab0, a=0x7f105b71a578, msg=msg@entry=0x7f105b8654b8) at action.c:1549 #12 0x000000000042bcf2 in do_action (h=h@entry=0x7ffe50aa3ab0, a=a@entry=0x7f105b719888, msg=msg@entry=0x7f105b8654b8) at action.c:1049 #13 0x000000000042a10a in run_actions (h=h@entry=0x7ffe50aa3ab0, a=0x7f105b719888, msg=msg@entry=0x7f105b8654b8) at action.c:1549 #14 0x000000000042bcf2 in do_action (h=h@entry=0x7ffe50aa3ab0, a=a@entry=0x7f105b7199b8, msg=msg@entry=0x7f105b8654b8) at action.c:1049 #15 0x000000000042a10a in run_actions (h=h@entry=0x7ffe50aa3ab0, a=0x7f105b7199b8, msg=msg@entry=0x7f105b8654b8) at action.c:1549 #16 0x000000000042bcf2 in do_action (h=h@entry=0x7ffe50aa3ab0, a=a@entry=0x7f105b719ae8, msg=msg@entry=0x7f105b8654b8) at action.c:1049 #17 0x000000000042a10a in run_actions (h=h@entry=0x7ffe50aa3ab0, a=0x7f105b719ae8, msg=msg@entry=0x7f105b8654b8) at action.c:1549 #18 0x000000000042bcf2 in do_action (h=h@entry=0x7ffe50aa3ab0, a=a@entry=0x7f105b719c18, msg=msg@entry=0x7f105b8654b8) at action.c:1049 #19 0x000000000042a10a in run_actions (h=h@entry=0x7ffe50aa3ab0, a=a@entry=0x7f105b6abc80, msg=msg@entry=0x7f105b8654b8) at action.c:1549 #20 0x00000000004375d0 in run_top_route (a=0x7f105b6abc80, msg=msg@entry=0x7f105b8654b8, c=c@entry=0x0) at action.c:1635 #21 0x0000000000504386 in receive_msg ( buf=buf@entry=0xa366b7 "PUBLISH sip:collector@109.68.96.98:5099 SIP/2.0\r\nVia: SIP/2.0/UDP 192.168.178.32:5060;branch=z9hG4bK122ceb41cd4777873\r\nRoute: <sip:proxy.live.sipgate.de:5060;lr>\r\nMax-Forwards: 70\r\nFrom: \"2362760e6\" <"..., len=<optimized out>, len@entry=728, rcv_info=rcv_info@entry=0x7ffe50aa3e80) at receive.c:240 #22 0x00007f105920ce17 in parsing_hepv3_message (buf=<optimized out>, len=<optimized out>) at hep.c:498 #23 0x00007f105920e80d in hepv3_received (buf=<optimized out>, len=<optimized out>, ri=<optimized out>) at hep.c:230 #24 0x00000000005f6e17 in udp_rcv_loop () at udp_server.c:446 #25 0x00000000004b2625 in main_loop () at main.c:1600 #26 0x0000000000427e2b in main (argc=<optimized out>, argv=<optimized out>) at main.c:2616 (gdb) ``` Does anybody see anything already? We can provide more info if needed. (And since it's the sipcapture module: @adubovikov) --- 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/723

8 years, 3 months

[kamailio/kamailio] Kamailio crushes when tcp errors invalid fd -1 (#748)

by mbike2000ru

Hi Kamailio crushes with lots of such CRITICAL errors: Aug 16 15:09:48 kam-fe1 kamailio[8485]: CRITICAL: <core> [tcp_read.c:1654]: handle_io(): io_watch_del failed for 0x7f3e610a3a70 id 105 fd -1, state -1, flags 4028, main fd -1, refcnt -2117 ([178.209.103.226]:40855 -> [178 .209.103.226]:5060) Aug 16 15:09:48 kam-fe1 kamailio[8479]: CRITICAL: <core> [io_wait.h:594]: io_watch_del(): invalid fd -1, not in [0, 23) Aug 16 15:09:48 kam-fe1 kamailio[8481]: WARNING: <core> [tcp_read.c:1629]: handle_io(): F_TCPCONN connection marked as bad: 0x7f3e608454e8 id 78 refcnt -257 Aug 16 15:09:48 kam-fe1 kamailio[8379]: INFO: <script>: 52373459-303f6c6b(a)192.168.2.2|log|source 128.204.55.172:5160 Aug 16 15:09:48 kam-fe1 kamailio[8485]: WARNING: <core> [tcp_read.c:1629]: handle_io(): F_TCPCONN connection marked as bad: 0x7f3e610a3a70 id 105 refcnt -2117 Aug 16 15:09:48 kam-fe1 kamailio[8479]: CRITICAL: <core> [tcp_read.c:1654]: handle_io(): io_watch_del failed for 0x7f3e63c73d90 id 984 fd -1, state -1, flags 5022, main fd -1, refcnt -126097 ([81.211.54.218]:51642 -> [81. 211.54.218]:5060) Aug 16 15:09:48 kam-fe1 kamailio[8481]: CRITICAL: <core> [io_wait.h:594]: io_watch_del(): invalid fd -1, not in [0, 2) Aug 16 15:09:48 kam-fe1 kamailio[8379]: INFO: <script>: 52373459-303f6c6b(a)192.168.2.2|log|from sip:Menedzher1_UYHPQ@29161.ztpbx.ru Aug 16 15:09:48 kam-fe1 kamailio[8485]: CRITICAL: <core> [io_wait.h:594]: io_watch_del(): invalid fd -1, not in [0, 2) Aug 16 15:09:48 kam-fe1 kamailio[8377]: ALERT: <core> [main.c:728]: handle_sigs(): child process 8504 exited by a signal 11 +++++++++++++++++++++++++++++++++ kamailio -v version: kamailio 4.3.5 (x86_64/linux) flags: STATS: Off, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, DBG_QM_MALLOC, 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: unknown compiled on 17:51:55 Mar 8 2016 with gcc 4.4.7 -- 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/748

8 years, 3 months

[kamailio/kamailio] Permissions module RPC array issue (#747)

by kelchy

using 4.4.2 on kamctl kamcmd permissions.addressDump { table: 80 group: 5 item: { ip: 6x.x4.1x7.10 port: 50060 tag: 0 } table: 120 group: 8 item: { ip: 1x8.1x4.1x6.19 port: 50060 tag: 0 } table: 122 group: 7 item: { ip: 1x8.1x4.1x6.17 port: 50060 tag: 0 } table: 122 group: 6 item: { ip: 1x8.1x4.1x6.17 port: 50060 tag: 0 } } on jsonrpc-s { jsonrpc: '2.0', result: { table: 122, group: 6, item: { ip: '1x8.1x4.1x6.17', port: 50060, tag: '0' } } } -- 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/747

8 years, 3 months

[kamailio/kamailio] 4.3 (#758)

by Kevin Scott Adams

Terminated all LM_-based statement messages with new line characters You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/758 -- Commit Summary -- * Code formatting changes. * Terminate all LM_* statement messages with a new line. -- File Changes -- M modules/sca/sca.c (567) M modules/sca/sca.h (36) M modules/sca/sca_appearance.c (2242) M modules/sca/sca_appearance.h (187) M modules/sca/sca_call_info.c (3555) M modules/sca/sca_call_info.h (42) M modules/sca/sca_common.h (7) M modules/sca/sca_db.c (250) M modules/sca/sca_db.h (71) M modules/sca/sca_dialog.c (151) M modules/sca/sca_dialog.h (18) M modules/sca/sca_event.c (73) M modules/sca/sca_event.h (16) M modules/sca/sca_hash.c (450) M modules/sca/sca_hash.h (78) M modules/sca/sca_notify.c (597) M modules/sca/sca_notify.h (6) M modules/sca/sca_reply.c (54) M modules/sca/sca_reply.h (2) M modules/sca/sca_rpc.c (809) M modules/sca/sca_rpc.h (44) M modules/sca/sca_subscribe.c (2662) M modules/sca/sca_subscribe.h (71) M modules/sca/sca_util.c (718) M modules/sca/sca_util.h (32) -- Patch Links -- https://github.com/kamailio/kamailio/pull/758.patch https://github.com/kamailio/kamailio/pull/758.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/758

8 years, 3 months

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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev August 2016