sr-dev October 2024

sr-dev@lists.kamailio.org

14 participants
110 discussions

[kamailio/kamailio] tcp_timer_check_connections() logs on CRITICAL and is not caught by event_route[tcp:timeout] (Issue #3995)

by Fritjof Höst

### Description Hi! We are in the progress of upgrading from Kamailio 5.5 to 5.8. During our testing we have noticed a new error being reported from Kamailio. We don’t see any other errors following it. ```jsx /usr/sbin/kamailio[201]: CRITICAL: <core> [core/tcp_main.c:5544]: tcp_timer_check_connections(): message processing timeout on connection id: 67896 (state: 3) - closing ``` It does seem to be [new code](https://github.com/kamailio/kamailio/blob/master/src/core/tcp_main.c#… in Kamailio reporting this issue. Given that this is a fairly expected thing, cleaning up a connection which receives no traffic within the given time, is there a need for it to be reported on CRITICAL? I’d also expect it to be caught by ``` event_route[tcp:timeout] { xlog("L_INFO","connection $conid timeouts (unanswered keepalives)"); } ``` given that [the description](https://www.kamailio.org/docs/modules/stable/modules/tcpops.ht… of this one is `Called for connection timeouts (unanswered keepalives).`. ### Troubleshooting We don't have any way to reproduce it, we are still investigating it to figure out the cause. It happens around every 2 hours, so we think there might some some scheduled test or job running in our test system causing this. ### Additional Information * **Kamailio Version** - 5.8.3 * **Operating System**: Debian 12 AMI from the AWS Marketplace. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3995 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3995(a)github.com>

9 hours, 6 minutes

[kamailio/kamailio] Possibly adjusting the SDP parser to be more lenient towards scenarios where a stream is being removed/rejected and connection-information "c=" is only available per media (no session-wide "c=") and the removed/rejected stream omits all fields (Issue #3982)

by thomas414

### Description I encountered an issue with a specific device that is receiving a T.38 fax. The call gets established towards the device normally with inband media, then the device requests T.38 media and tries to remove the audio media via sending port 0 in the ReInvite SDP. Also it sends connection-information only on the media level and there is no "c=" on the session level. Reading through the related RFCs and the kamailio code and discussing this on the mailing list, we came to the conclusion that kamailio is doing everything correct as per RFC. Though we were wondering if it would be possible to adjust the parser to be not as strict as it is right now, and allow a missing "c=" line on the media-level if the stream is removed/rejected via port 0, since i see no sense in requiring connection information. Of course we are also in contact with the vendor to hopefully adjust on their side. Here are the related RFCs: 1. RFC8866 5.7 `A session description MUST contain either at least one "c=" line in each media description or a single "c=" line at the session level. It MAY contain a single session-level "c=" line and additional media-level "c=" line(s) per-media-description, in which case the media-level values override the session-level settings for the respective media.` 2. RFC3264 8.2 `Existing media streams are removed by creating a new SDP with the port number for that stream set to zero. The stream description MAY omit all attributes present previously, and MAY list just a single media format.` At first i was especially confused by the RFC3264 8.2 part, since it seemed correct what the device is sending, but if you read carefully and keep the wording for SDP in mind only attributes ("a=") MAY be omitted. So a "c=" line should still be in the SDP for the removed media if it's not included on the session-level. Or do you see this differently? ### Expected behavior Kamailio allows and parses the SDP when there is no session-wide "c=", a media stream is being removed via port zero and there is no "c=" for this media stream and only the remaining media streams include a "c=" line. #### Actual observed behavior Kamailio throws an error when trying to parse the SDP. #### Log Messages ``` <core> [core/parser/sdp/sdp.c:523]: parse_sdp_session(): can't find media IP in the message ``` #### SIP Traffic ``` v=0 o=xmserver 1726638425 1726638427 IN IP4 169.254.1.1 s=xmserver t=0 0 m=audio 0 RTP/AVP 8 m=image 56002 udptl t38 c=IN IP4 169.254.1.1 a=sendrecv a=T38FaxVersion:0 a=T38MaxBitRate:14400 a=T38FaxFillBitRemoval:0 a=T38FaxTranscodingMMR:0 a=T38FaxTranscodingJBIG:0 a=T38FaxRateManagement:transferredTCF a=T38FaxMaxBuffer:200 a=T38FaxMaxDatagram:72 a=T38FaxUdpEC:t38UDPRedundancy ``` ### Possible Solutions ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.8.3 (x86_64/linux) flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_SEND_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: unknown compiled with gcc 12.2.0 ``` * **Operating System**: ``` Debian 12 Linux hostname 6.1.0-20-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.85-1 (2024-04-11) x86_64 GNU/Linux ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3982 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3982(a)github.com>

9 hours, 6 minutes

[kamailio/kamailio] Advertise in listen directive still gives port in headers even though it's not set or set to 0 (Issue #3933)

by Evgenii Buchnev

Reopening. (https://github.com/kamailio/kamailio/issues/3932#issuecomment-2252138364) It's bug. Please see highlighted on screenshot. ![image](https://github.com/user-attachments/assets/88b9671d-d2be-4d49-8596-3e6ab3a2d294) Hey Team, Thank you for the awesome software ### Description Neither option work: `listen=... advertise some.custom.hostname.io` `listen=... advertise some.custom.hostname.io:0` to make Kamailio present only hostname(without port) in Record-Route headers, affects NAPTR/SRV. ### Troubleshooting ============ _Hostname without port - still gives port 5081 in Record-Route_ **kamailio.cfg** ... `listen=tls:KAM_LOC_IP:5081 advertise some.custom.io name "provider_socket_tls"` ... **sngrep, 200 OK for INVITE** ... `Record-Route: <sip:some.custom.io:5081;transport=tls;r2=on;lr;did=494.6e51>` ... **kamcmd corex.list_sockets** ... ``` { af: IPv4 proto: tls name: 172.17.57.164 addrlist: { addr: 172.17.57.164 } port: 5081 sockstr: tls:172.17.57.164:5081 mcast: no mhomed: no virtual: no sockname: provider_socket_tls advertise: tls:some.custom.io:0 } ``` ... ======== _Hostname with port 0 - still gives port 5081 in Record-Route_ kamailio.cfg ... `listen=tls:KAM_LOC_IP:5081 advertise some.custom.io:0 name "provider_socket_tls"` ... sngrep, 200 OK for INVITE ... `Record-Route: <sip:some.custom.io:5081;transport=tls;r2=on;lr;did=042.7721>` ... kamcmd corex.list_sockets ... ``` { af: IPv4 proto: tls name: 172.17.57.164 addrlist: { addr: 172.17.57.164 } port: 5081 sockstr: tls:172.17.57.164:5081 mcast: no mhomed: no virtual: no sockname: provider_socket_tls advertise: tls:some.custom.io:0 } ``` ... ============ _Hostname with explicit different port 8888 - gives that port 8888 in Record-Route (to confirm config works)_ kamailio.cfg ... `listen=tls:KAM_LOC_IP:5081 advertise some.custom.io:8888 name "provider_socket_tls"` ... sngrep, 200 OK for INVITE ... `Record-Route: <sip:some.custom.io:8888;transport=tls;r2=on;lr;did=dae.ac31>` ... kamcmd corex.list_sockets ... ``` { af: IPv4 proto: tls name: 172.17.57.164 addrlist: { addr: 172.17.57.164 } port: 5081 sockstr: tls:172.17.57.164:5081 mcast: no mhomed: no virtual: no sockname: provider_socket_tls advertise: tls:some.custom.io:8888 } ``` ... #### Reproduction Please see Troubleshooting section #### Debugging Data Please see Troubleshooting section #### Log Messages N/A #### SIP Traffic Please see Troubleshooting section ### Possible Solutions N/A ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.8.2 (x86_64/linux) dbe51d flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_SEND_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: dbe51d compiled on 07:13:22 Jul 17 2024 with gcc 12.2.0) ``` * **Operating System**: ``` [dev]root@[voiceproxy]:~# lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 12 (bookworm) Release: 12 Codename: bookworm [dev]root@[voiceproxy]:~# uname -a Linux i-0875d7720d6152612 6.1.0-23-cloud-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.99-1 (2024-07-15) x86_64 GNU/Linux [dev]root@[voiceproxy]:~# cat /etc/*relea* ID=ec2 VERSION="20240702-1796" PRETTY_NAME="Debian GNU/Linux 12 (bookworm)" NAME="Debian GNU/Linux" VERSION_ID="12" VERSION="12 (bookworm)" VERSION_CODENAME=bookworm ID=debian HOME_URL="https://www.debian.org/" SUPPORT_URL="https://www.debian.org/support" BUG_REPORT_URL="https://bugs.debian.org/" ``` * **Might be related** : https://github.com/kamailio/kamailio/issues/1884 -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3933 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3933(a)github.com>

5 days, 2 hours

[kamailio/kamailio] htable: export table create api functions (PR #4010)

by Stefan Mititelu

#### Pre-Submission Checklist    - [X] Commit message has the format required by CONTRIBUTING guide - [X] Commits are split per component (core, individual modules, libs, utils, ...) - [X] Each component has a single commit (if not, squash them into one commit) - [X] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated) #### Type Of Change - [ ] Small bug fix (non-breaking change which fixes an issue) - [X] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality) #### Checklist:  - [ ] PR should be backported to stable branches - [X] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description  Looks like htable module already exports API functions, but currently no other module uses them. Added 2 more API functions for table creation (so other modules can be able to create their own hash tables if they want to) You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/4010 -- Commit Summary -- * htable: export table create api functions -- File Changes -- M src/modules/htable/api.c (10) M src/modules/htable/api.h (4) M src/modules/htable/ht_api.c (4) -- Patch Links -- https://github.com/kamailio/kamailio/pull/4010.patch https://github.com/kamailio/kamailio/pull/4010.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4010 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/4010(a)github.com>

1 week

[kamailio/kamailio] cdp: disconnect_serviced_peer Causing the service process to crash (Issue #3999)

by liangbaolin

### Description hi, I encountered a problem where the CDP module is extremely prone to process crashes. The following are screenshots of the logs and core files. I couldn't find the exception code that caused the problem, but I suspect that the TCP link was properly established, but the peer did not initialize or handle the exception properly, resulting in an exception when the packet was parsed incorrectly and disconnected later. In addition, since the socket is not a normal peer, it will constantly rebuild the chain, but the CDP does not recognize and process it properly. The socket will continue to grow, but the number of peers will not increase. <img width="1508" alt="微信图片_20241011175120" src="https://github.com/user-attachments/assets/88a0fc31-9ff6-4f46-9394-f49c7878…"> ### Troubleshooting #### Reproduction  #### Debugging Data ``` Core was generated by `/usr/sbin/kamailio -f /etc/kamailio_dra/kamailio_dra.cfg -P /var/run/kamailio_d'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007f9860fae336 in cc_acc_client_stateful_sm_process (s=0x7f9861bd8980, event=21874, msg=0x55720d57c702 <qm_free+8029>) at acctstatemachine.c:304 304 } (gdb) bt #0 0x00007f9860fae336 in cc_acc_client_stateful_sm_process (s=0x7f9861bd8980, event=21874, msg=0x55720d57c702 <qm_free+8029>) at acctstatemachine.c:304 #1 0x00007f9860fae391 in atomic_get_and_set_int (var=0x776f6e6b6e752072, v=32766) at ../../core/mem/../atomic/atomic_x86.h:242 #2 0x00007f9860fb16eb in disconnect_serviced_peer (sp=0x7f98e28287d0, locked=0) at receiver.c:232 #3 0x00007f9860fbd56b in receive_loop (original_peer=0x0) at receiver.c:942 #4 0x00007f9860fb4c02 in receiver_process (p=0x0) at receiver.c:488 #5 0x00007f9860f50c80 in diameter_peer_start (blocking=0) at diameter_peer.c:278 #6 0x00007f9860f413df in cdp_child_init (rank=0) at cdp_mod.c:274 #7 0x000055720d3df6c2 in init_mod_child (m=0x7f98e279b180, rank=0) at core/sr_module.c:920 #8 0x000055720d3df2b5 in init_mod_child (m=0x7f98e279be50, rank=0) at core/sr_module.c:912 #9 0x000055720d3df2b5 in init_mod_child (m=0x7f98e279c2c0, rank=0) at core/sr_module.c:912 #10 0x000055720d3df2b5 in init_mod_child (m=0x7f98e279cc40, rank=0) at core/sr_module.c:912 #11 0x000055720d3df2b5 in init_mod_child (m=0x7f98e279d130, rank=0) at core/sr_module.c:912 #12 0x000055720d3df2b5 in init_mod_child (m=0x7f98e279d6c0, rank=0) at core/sr_module.c:912 #13 0x000055720d3df2b5 in init_mod_child (m=0x7f98e279db10, rank=0) at core/sr_module.c:912 #14 0x000055720d3df2b5 in init_mod_child (m=0x7f98e279dff0, rank=0) at core/sr_module.c:912 #15 0x000055720d3df2b5 in init_mod_child (m=0x7f98e279fae0, rank=0) at core/sr_module.c:912 #16 0x000055720d3dfff0 in init_child (rank=0) at core/sr_module.c:999 #17 0x000055720d23d70a in main_loop () at main.c:1942 #18 0x000055720d2488f5 in main (argc=16, argv=0x7ffea4fde838) at main.c:3256 (gdb) bt full #0 0x00007f9860fae336 in cc_acc_client_stateful_sm_process (s=0x7f9861bd8980, event=21874, msg=0x55720d57c702 <qm_free+8029>) at acctstatemachine.c:304 x = 0x7f9861b97000 ret = 441 rc = 1627304660 record_type = 32664 __func__ = "cc_acc_client_stateful_sm_process" #1 0x00007f9860fae391 in atomic_get_and_set_int (var=0x776f6e6b6e752072, v=32766) at ../../core/mem/../atomic/atomic_x86.h:242 No locals. #2 0x00007f9860fb16eb in disconnect_serviced_peer (sp=0x7f98e28287d0, locked=0) at receiver.c:232 __llevel = 0 __func__ = "disconnect_serviced_peer" #3 0x00007f9860fbd56b in receive_loop (original_peer=0x0) at receiver.c:942 __llevel = -1526863824 rfds = {__fds_bits = {0, 0, 0, 0, 1024, 0 <repeats 11 times>}} efds = {__fds_bits = {0 <repeats 16 times>}} tv = {tv_sec = 0, tv_usec = 883496} n = 1 max = 298 cnt = 0 msg = 0x0 sp = 0x7f98e28287d0 sp2 = 0x7f98e2827e30 p = 0x0 fd = 295 fd_exchange_pipe_local = 28 __func__ = "receive_loop" #4 0x00007f9860fb4c02 in receiver_process (p=0x0) at receiver.c:488 __llevel = -990730168 __func__ = "receiver_process" #5 0x00007f9860f50c80 in diameter_peer_start (blocking=0) at diameter_peer.c:278 pid = 0 k = 1 seed = 1112701621 p = 0x0 __func__ = "diameter_peer_start" #6 0x00007f9860f413df in cdp_child_init (rank=0) at cdp_mod.c:274 __llevel = 0 __func__ = "cdp_child_init" #7 0x000055720d3df6c2 in init_mod_child (m=0x7f98e279b180, rank=0) at core/sr_module.c:920 ret = 0 __func__ = "init_mod_child" #8 0x000055720d3df2b5 in init_mod_child (m=0x7f98e279be50, rank=0) at core/sr_module.c:912 ret = 1 __func__ = "init_mod_child" #9 0x000055720d3df2b5 in init_mod_child (m=0x7f98e279c2c0, rank=0) at core/sr_module.c:912 ret = 0 __func__ = "init_mod_child" #10 0x000055720d3df2b5 in init_mod_child (m=0x7f98e279cc40, rank=0) at core/sr_module.c:912 ret = 0 __func__ = "init_mod_child" ---Type <return> to continue, or q <return> to quit--- #11 0x000055720d3df2b5 in init_mod_child (m=0x7f98e279d130, rank=0) at core/sr_module.c:912 ret = 0 __func__ = "init_mod_child" #12 0x000055720d3df2b5 in init_mod_child (m=0x7f98e279d6c0, rank=0) at core/sr_module.c:912 ret = 0 __func__ = "init_mod_child" #13 0x000055720d3df2b5 in init_mod_child (m=0x7f98e279db10, rank=0) at core/sr_module.c:912 ret = 32766 __func__ = "init_mod_child" #14 0x000055720d3df2b5 in init_mod_child (m=0x7f98e279dff0, rank=0) at core/sr_module.c:912 ret = 21874 __func__ = "init_mod_child" #15 0x000055720d3df2b5 in init_mod_child (m=0x7f98e279fae0, rank=0) at core/sr_module.c:912 ret = 12 __func__ = "init_mod_child" #16 0x000055720d3dfff0 in init_child (rank=0) at core/sr_module.c:999 ret = 0 type = 0x55720d6ece7b "PROC_MAIN" __func__ = "init_child" #17 0x000055720d23d70a in main_loop () at main.c:1942 i = 1639542784 pid = 50 si = 0x0 si_desc = "\240\233\"\rrU\000\000@\361\367a\230\177\000\000\000\343\375\244\376\177\000\000\327~2\rrU\000\000\000\343\375\244\376\177\000\000\025\t>\r\005\000\000\000\000\000\000\000\037\000\000\000\000;\213\222\213\017\r\202h\r\000\000\000\000\000\000\060\000\000\000\000\000\000\000\240\233\"\rrU\000\000\060\350\375\244\376\177", '\000' <repeats 18 times>, "\340\342\375\244\376\177\000\000 \351O\rrU\000" nrprocs = 21874 woneinit = 0 __func__ = "main_loop" #18 0x000055720d2488f5 in main (argc=16, argv=0x7ffea4fde838) at main.c:3256 cfg_stream = 0x55720ef75260 c = -1 r = 0 tmp = 0x7ffea4fdfee3 "" tmp_len = 32766 port = 5060 proto = 0 aproto = 0 ahost = 0x0 aport = 0 options = 0x55720d6b3698 ":f:cm:M:dVIhEeb:B:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:x:X:Y:" ret = -1 seed = 2959679812 rfd = 4 debug_save = 0 debug_flag = 0 dont_fork_cnt = 2 n_lst = 0x0 p = 0x7f996220a3d0 "" st = {st_dev = 50, st_ino = 2995745, st_nlink = 1, st_mode = 16877, st_uid = 103, st_gid = 105, __pad0 = 0, st_rdev = 0, st_size = 4096, st_blksize = 4096, st_blocks = 8, st_atim = {tv_sec = 1726638407, tv_nsec = 558385502}, st_mtim = {tv_sec = 1727831142, tv_nsec = 822744119}, st_ctim = {tv_sec = 1727831142, tv_nsec = 822744119}, __glibc_reserved = {0, 0, 0}} ---Type <return> to continue, or q <return> to quit--- l1 = 2048 tbuf = "pQ!b\231\177\000\000\070-\000b\231\177\000\000\020\347\375\244\376\177\000\000\367\344\376a\231\177", '\000' <repeats 18 times>, "\001\000\000\000\000\000\000\000(W!b\231\177\000\000\000Q!b\231\177\000\000\001\000\000\000\000\000\000\000\300\200 b\231\177\000\000\017Q\377a\231\177\000\000\020W!b\231\177", '\000' <repeats 19 times>, "S\376\244\376\177\000\000\300\212\225\001\000\000\000\000\207\026=a\231\177\000\000`\347\375\244\376\177\000\000\220Q\376\244\376\177\000\000\002\000\000\000\231\177\000\000\000\000\000\000\000\000\000\000\300\346\375\244\376\177\000\000\003\000\000\000\000\000\000\000\260\346\375\244\376\177\000\000\000\000\000\000\000\000\000\000"... option_index = 0 long_options = {{name = 0x55720d6b59f6 "help", has_arg = 0, flag = 0x0, val = 104}, {name = 0x55720d6b087c "version", has_arg = 0, flag = 0x0, val = 118}, {name = 0x55720d6b59fb "alias", has_arg = 1, flag = 0x0, val = 1024}, {name = 0x55720d6b5a01 "subst", has_arg = 1, flag = 0x0, val = 1025}, {name = 0x55720d6b5a07 "substdef", has_arg = 1, flag = 0x0, val = 1026}, {name = 0x55720d6b5a10 "substdefs", has_arg = 1, flag = 0x0, val = 1027}, {name = 0x55720d6b5a1a "server-id", has_arg = 1, flag = 0x0, val = 1028}, { name = 0x55720d6b5a24 "loadmodule", has_arg = 1, flag = 0x0, val = 1029}, {name = 0x55720d6b5a2f "modparam", has_arg = 1, flag = 0x0, val = 1030}, {name = 0x55720d6b5a38 "log-engine", has_arg = 1, flag = 0x0, val = 1031}, {name = 0x55720d6b5a43 "debug", has_arg = 1, flag = 0x0, val = 1032}, {name = 0x55720d6b5a49 "cfg-print", has_arg = 0, flag = 0x0, val = 1033}, {name = 0x55720d6b5a53 "atexit", has_arg = 1, flag = 0x0, val = 1034}, {name = 0x55720d6b5a5a "all-errors", has_arg = 0, flag = 0x0, val = 1035}, {name = 0x0, has_arg = 0, flag = 0x0, val = 0}} __func__ = "main" (gdb) (gdb) info locals cfg_stream = 0x55720ef75260 c = -1 r = 0 tmp = 0x7ffea4fdfee3 "" tmp_len = 32766 port = 5060 proto = 0 aproto = 0 ahost = 0x0 aport = 0 options = 0x55720d6b3698 ":f:cm:M:dVIhEeb:B:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:x:X:Y:" ret = -1 seed = 2959679812 rfd = 4 debug_save = 0 debug_flag = 0 dont_fork_cnt = 2 n_lst = 0x0 p = 0x7f996220a3d0 "" st = {st_dev = 50, st_ino = 2995745, st_nlink = 1, st_mode = 16877, st_uid = 103, st_gid = 105, __pad0 = 0, st_rdev = 0, st_size = 4096, st_blksize = 4096, st_blocks = 8, st_atim = {tv_sec = 1726638407, tv_nsec = 558385502}, st_mtim = {tv_sec = 1727831142, tv_nsec = 822744119}, st_ctim = {tv_sec = 1727831142, tv_nsec = 822744119}, __glibc_reserved = {0, 0, 0}} l1 = 2048 tbuf = "pQ!b\231\177\000\000\070-\000b\231\177\000\000\020\347\375\244\376\177\000\000\367\344\376a\231\177", '\000' <repeats 18 times>, "\001\000\000\000\000\000\000\000(W!b\231\177\000\000\000Q!b\231\177\000\000\001\000\000\000\000\000\000\000\300\200 b\231\177\000\000\017Q\377a\231\177\000\000\020W!b\231\177", '\000' <repeats 19 times>, "S\376\244\376\177\000\000\300\212\225\001\000\000\000\000\207\026=a\231\177\000\000`\347\375\244\376\177\000\000\220Q\376\244\376\177\000\000\002\000\000\000\231\177\000\000\000\000\000\000\000\000\000\000\300\346\375\244\376\177\000\000\003\000\000\000\000\000\000\000\260\346\375\244\376\177\000\000\000\000\000\000\000\000\000\000"... option_index = 0 long_options = {{name = 0x55720d6b59f6 "help", has_arg = 0, flag = 0x0, val = 104}, {name = 0x55720d6b087c "version", has_arg = 0, flag = 0x0, val = 118}, {name = 0x55720d6b59fb "alias", has_arg = 1, flag = 0x0, val = 1024}, {name = 0x55720d6b5a01 "subst", has_arg = 1, flag = 0x0, val = 1025}, {name = 0x55720d6b5a07 "substdef", has_arg = 1, flag = 0x0, val = 1026}, {name = 0x55720d6b5a10 "substdefs", has_arg = 1, flag = 0x0, val = 1027}, {name = 0x55720d6b5a1a "server-id", has_arg = 1, flag = 0x0, val = 1028}, { name = 0x55720d6b5a24 "loadmodule", has_arg = 1, flag = 0x0, val = 1029}, {name = 0x55720d6b5a2f "modparam", has_arg = 1, flag = 0x0, val = 1030}, {name = 0x55720d6b5a38 "log-engine", has_arg = 1, flag = 0x0, val = 1031}, {name = 0x55720d6b5a43 "debug", has_arg = 1, flag = 0x0, val = 1032}, {name = 0x55720d6b5a49 "cfg-print", has_arg = 0, flag = 0x0, val = 1033}, {name = 0x55720d6b5a53 "atexit", has_arg = 1, flag = 0x0, val = 1034}, {name = 0x55720d6b5a5a "all-errors", has_arg = 0, flag = 0x0, val = 1035}, {name = 0x0, has_arg = 0, flag = 0x0, val = 0}} __func__ = "main" (gdb) list 299 if(s) { 300 AAASessionsUnlock(s->hash); 301 } 302 303 return ret; 304 } ``` #### Log Messages  ``` 2024-10-11T08:23:20.234947572Z 21(60) ERROR: cdp [receiver.c:783]: receive_loop(): select_recv(): Bad file descriptor 2024-10-11T08:23:24.906121404Z 21(60) ERROR: cdp [receiver.c:783]: receive_loop(): select_recv(): Bad file descriptor 2024-10-11T08:23:41.857946233Z 21(60) ERROR: cdp [receiver.c:783]: receive_loop(): select_recv(): Bad file descriptor 2024-10-11T08:25:18.095639136Z 25(64) WARNING: cdp [peermanager.c:337]: peer_timer(): Inactivity on peer [scscf32.ims.mnc011.mcc460.3gppnetwork.org] and no DWA, Closing peer... 2024-10-11T08:43:38.138243609Z 31(70) CRITICAL: <core> [core/pass_fd.c:281]: receive_fd(): EOF on 34 2024-10-11T08:43:47.476315811Z 0(39) ALERT: <core> [main.c:805]: handle_sigs(): child process 60 exited by a signal 11 2024-10-11T08:43:47.476380054Z 0(39) ALERT: <core> [main.c:809]: handle_sigs(): core was generated 2024-10-11T08:43:47.503780368Z 0(39) CRITICAL: cdp [diameter_peer.c:447]: diameter_peer_destroy(): destroy_diameter_peer(): Bye Bye from C Diameter Peer test ``` * **Operating System**: version: kamailio 5.8.1 (x86_64/linux) 07b761 flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_SEND_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: 07b761 compiled on 10:00:57 Oct 9 2024 with gcc 7.5.0 -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3999 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3999(a)github.com>

1 week, 3 days

[kamailio/kamailio] Module snmpstats reporting inconsistent call success metrics on intense peaks of failed calls (Issue #4006)

by igorpotjevlesh

### Description We are plotting the call success rate on each of our proxies. Using the Kamailio snmpstats module, we try to obtain three counters in order to plot them on a graph: - Total Calls - Active Calls - Error Calls Most of the time, everything works well and we obtain sensible values: `snmpwalk -c mycommunity -v 2c W.X.Y.Z 1.3.6.1.4.1.34352.3.1.3.1.3.2 -O n` > .1.3.6.1.4.1.34352.3.1.3.1.3.2.1.0 = Gauge32: 309 -> Total Calls .1.3.6.1.4.1.34352.3.1.3.1.3.2.2.0 = Gauge32: 95 -> Active Calls .1.3.6.1.4.1.34352.3.1.3.1.3.2.3.0 = Gauge32: 214 -> Error calls However, **when our proxies are facing intense peaks of failed calls in a short timespan**, sometimes, the **"Error Calls"** counter returns a value **higher than "Total Calls"**. As a result, **"Active Calls"** suddenly reaches a value close to the **maximum of a _Gauge32_** (because ${TotalCalls} - {ErrorCalls} < 0$). `snmpwalk -c mycommunity -v 2c W.X.Y.Z 1.3.6.1.4.1.34352.3.1.3.1.3.2 -O n` > .1.3.6.1.4.1.34352.3.1.3.1.3.2.1.0 = Gauge32: 153 -> Total Calls .1.3.6.1.4.1.34352.3.1.3.1.3.2.2.0 = Gauge32: 4294967226 -> Active Calls .1.3.6.1.4.1.34352.3.1.3.1.3.2.3.0 = Gauge32: 223 -> Error calls As a result, our graphs make no more sense. ### Troubleshooting There seems to be a bug causing Total calls to be lower than Error calls when a high number of failed calls are received in a short time window. Moreover, there is an integer overflow resulting to the negative result of the substraction being converted to a _Gauge32_. Maybe setting it to 0 in case of a negative result would be safer ? #### Reproduction Using the following configuration for the snmpstats module of your Kamailio proxy: ``` # -------- snmpstats params ------- modparam("snmpstats", "snmpgetPath", "/usr/bin/") modparam("snmpstats", "snmpCommunity", "mycommunity") modparam("snmpstats", "sipEntityType", "proxyServer") ``` On intense peaks of failed calls, get the call success metrics using `snmpwalk` : `snmpwalk -c mycommunity -v 2c W.X.Y.Z 1.3.6.1.4.1.34352.3.1.3.1.3.2 -O n` > .1.3.6.1.4.1.34352.3.1.3.1.3.2.1.0 = Gauge32: 153 -> Total Calls .1.3.6.1.4.1.34352.3.1.3.1.3.2.2.0 = Gauge32: 4294967226 -> Active Calls .1.3.6.1.4.1.34352.3.1.3.1.3.2.3.0 = Gauge32: 223-> Error calls ### Additional Information **Kamailio Version**: `kamailio -v` > version: kamailio 5.6.4 (x86_64/linux) a004cf 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_S R_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, U SE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SI ZE 65535, DEFAULT PKG_SIZE 64MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: a004cf compiled on 16:10:41 May 22 2023 with gcc 4.4.7 * **Operating System**: `uname -r` > 2.6.32-279.el6.x86_64 `lsb_release -a` > LSB Version: :core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch Distributor ID: RedHatEnterpriseServer Description: Red Hat Enterprise Linux Server release 6.3 (Santiago) Release: 6.3 Codename: Santiago -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4006 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4006(a)github.com>

1 week, 4 days

[kamailio/kamailio] Memory usage increases everytime tls.reload is executed (Issue #3823)

by Sebastian Denz

### Description We are using Kamailio 5.7.4 on Debian 12 (from http://deb.kamailio.org/kamailio57) with rtpengine as an Edgeproxy for our clients. The instance terminates SIP/TLS (with Cliencertificates) and forwards the SIP Traffic to internal systems. After some days we are getting errors like this `tls_complete_init(): tls: ssl bug #1491 workaround: not enough memory for safe operation: shm=7318616 threshold1=8912896` First we thought Kamailio just doesnt have enough memory, so we doubled it.. But after some days the Logmessage (and Userissues) occured again. So we monitored the shmmem statistics and found that used and max_used are constantly growing til it reaches the limit. As i mentioned we are using client-certificates and so we are also using the CRL feature. We do have a systemd-timer which fetches the CRL every hour and runs 'kamcmd tls.reload' when finished. Our tls.cfg looks like this: ``` [server:default] method = TLSv1.2+ private_key = /etc/letsencrypt/live/hostname.de/privkey.pem certificate = /etc/letsencrypt/live/hostname.de/fullchain.pem ca_list = /etc/kamailio/ca_list.pem ca_path = /etc/kamailio/ca_list.pem crl = /etc/kamailio/combined.crl.pem verify_certificate = yes require_certificate = yes [client:default] verify_certificate = yes require_certificate = yes ``` After testing a bit we found that every time tls.reload is executed Kamailio consumes a bit more memory which eventually leads to all the memory being consumed which leads to issues for our users. See following example: ``` [0][root@edgar-dev:~]# while true ; do /usr/sbin/kamcmd tls.reload ; /usr/sbin/kamcmd core.shmmem ; sleep 1 ; done Ok. TLS configuration reloaded. { total: 268435456 free: 223001520 used: 41352552 real_used: 45433936 max_used: 45445968 fragments: 73 } Ok. TLS configuration reloaded. { total: 268435456 free: 222377960 used: 41975592 real_used: 46057496 max_used: 46069232 fragments: 78 } Ok. TLS configuration reloaded. { total: 268435456 free: 221748664 used: 42604992 real_used: 46686792 max_used: 46698080 fragments: 77 } Ok. TLS configuration reloaded. { total: 268435456 free: 221110832 used: 43242408 real_used: 47324624 max_used: 47335608 fragments: 81 } ^C [130][root@edgar-dev:~]# ``` ### Troubleshooting #### Reproduction Everytime tls.reload is called the memory consumptions grows.. #### Debugging Data  ``` If you let me know what would be interesting for tracking this down, i am happy to provide logs/debugging data! ``` #### Log Messages  ``` If you let me know what would be interesting for tracking this down, i am happy to provide logs/debugging data! ``` #### SIP Traffic SIP doesnt seem to be relevant here ### Possible Solutions Calling tls.reload less often or restart kamailio before memory is consumed ;) ### Additional Information ``` version: kamailio 5.7.4 (x86_64/linux) flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_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 12.2.0 ``` * **Operating System**: ``` * Debian GNU/Linux 12 (bookworm) * Linux edgar-dev 6.1.0-20-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.85-1 (2024-04-11) x86_64 GNU/Linux ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3823 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3823(a)github.com>

1 week, 5 days

[kamailio/kamailio] core: local TCP socket is bound on listening address (PR #3925)

by sergey-safarov

#### 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 As a local IP address for TCP sending operation the Kamailio service is taking the same network_interface/IP_address, which is used by the service for TCP listening. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3925 -- Commit Summary -- * core: local TCP socket is bound on listening address -- File Changes -- M src/core/tcp_main.c (24) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3925.patch https://github.com/kamailio/kamailio/pull/3925.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3925 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3925(a)github.com>

1 week, 5 days

[kamailio/kamailio] free_fixup functions in cmd_export_t are not called (Issue #3814)

by Xenofon Karamanos

### Description It seems that the fixup_free_* functions are not getting called when used with: ``` static cmd_export_t cmds[] = { {"acc_log_request", (cmd_function)w_acc_log_request, 1, acc_fixup, free_acc_fixup, ANY_ROUTE}, // ... {0, 0, 0, 0, 0, 0} }; static int free_acc_fixup(void **param, int param_no) { LM_CRIT("acc free fixup = %d\n", param_no); if(*param) { pkg_free(*param); *param = 0; } return 0; } ``` Nothing is getting logged from the function. Is this expected not to print in free_fixup due to the destruction of kamailio and the logging is not reliable? I also used gdb and added some breakpoints in `fixup` and `free_fixup` functions in some other modules (file_out) and the breakpoint was only found in `fixup` but not in `free_fixup`. When is the `free_fixup` supposed to be called, at kamailio destruction or after fixing it and before the main loop starts?  ### Troubleshooting #### Reproduction  Use any module that has a custom (maybe also provided from core) `free_fixup` function, and monitor if `free_fixup` is called using debug mode. #### Log Messages  ``` Apr 15 15:52:03 app01 kamailio[812169]: INFO: <core> [core/mem/q_malloc.c:402]: qm_malloc(): qm_malloc(0x7fcdcab18010, 56) called from file_out: file_out.c: fo_fixup_str_index(287) Apr 15 15:52:03 app01 kamailio[812169]: INFO: <core> [core/mem/q_malloc.c:449]: qm_malloc(): qm_malloc(0x7fcdcab18010, 64) returns address 0x7fcdcacc4280 frag. 0x7fcdcacc4240 (size=64) on 1 -th hit``` `0x7fcdcacc4240` fragment is not found anywhere in the logs reported that it was freed unlike other malloced resources. ``` ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.9.0-dev0 (x86_64/linux) 8bc64a flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_SEND_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: 8bc64a compiled on 15:32:09 Apr 15 2024 with gcc 10.5.0 ``` * **Operating System**:  ``` No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 20.04.6 LTS Release: 20.04 Codename: focal 5.4.0-176-generic #196-Ubuntu SMP Fri Mar 22 16:46:39 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3814 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3814(a)github.com>

2 weeks, 1 day

[kamailio/kamailio] Module dispatcher: ds_is_active() return incorrect. (Issue #4001)

by Minh Vũ

#### Kamailo 5.8 ### Description I use ```ds_is_active function()``` in ```dispatcher``` module. ``` $var(sip_url) = $sht(conf_fs=>$var(conf_id)); # sip:192.168.1.44:5060 if(ds_is_active("1", "$var(sip_url)")){ #### is allways run } ``` or ```ds_is_active("1", $var(sip_url))``` #### Debugging Data When I check dispatcher: ``` "DEST": { "URI": "sip:192.168.1.44:5060", "FLAGS": "IP", "PRIORITY": 0, "ATTRS": { "BODY": "rweight=50;weight=50;cc=1", "DUID": null, "MAXLOAD": 0, "WEIGHT": 50, "RWEIGHT": 50, "SOCKET": null, "SOCKNAME": null, "OBPROXY": null } } ``` Why is the flag set to ```IP```, but ```ds_is_active()``` returns true? -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4001 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4001(a)github.com>

2 weeks, 5 days

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev October 2024