October 2025 - sr-dev - kamailio.org

[kamailio/kamailio] Issue with usrloc 'handle_lost_tcp' and dmq_usrloc 'usrloc_delete' (Issue #3479)
by alternatenetwork 02 May '26

02 May '26

### Description When a TLS connection is closed and handle_lost_tcp=1 the entry is deleted for usrloc. This deletion is not synced via DMQ even though usrloc_delete=1. There is also an issue on the same server if a re-registration happens right after before the timeout was supposed to expire then $var(sv_res) = 2 even though the usrloc table is empty. So it seems like the way handle_lost_tcp deletes is not deleting fully in registrar. usrloc db_mode is 0 ### Troubleshooting #### Reproduction Setup 2 servers with DMQ and close the TCP connection. ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.6.1 (x86_64/linux) d8f98b 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: d8f98b compiled on 19:05:04 Aug 16 2022 with gcc 8.3.0 ``` * **Operating System**:  ``` Debian 10 ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3479 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3479(a)github.com>

3 6

[kamailio/kamailio] http_async_client [http_multi.c:88]: event_cb(): Cell for handler 0x7f78f8c79b10 not found in table (Issue #4431)
by fulhade 20 Apr '26

20 Apr '26

fulhade created an issue (kamailio/kamailio#4431) Testing 6.0.3 noticed that log is filled with INFO log messages from title (every 5s). No errors in logs, usual stuff except info on tcpcon ``` Oct 12 00:40:24 kamailio[4350]: INFO: <core> [core/tcp_main.c:3124]: tcpconn_1st_send(): quick connect for 0x7f78f8c79b10 sock 38 Oct 12 22:42:26 kamailio[4355]: INFO: <core> [core/tcp_main.c:3124]: tcpconn_1st_send(): quick connect for 0x7f78f8c79b10 sock 32 ... Oct 13 07:42:12 kamailio[4355]: INFO: http_async_client [http_multi.c:88]: event_cb(): Cell for handler 0x7f78f8c79b10 not found in table Oct 13 07:42:17 kamailio[4355]: INFO: http_async_client [http_multi.c:88]: event_cb(): Cell for handler 0x7f78f8c79b10 not found in table Oct 13 07:42:22 kamailio[4355]: INFO: http_async_client [http_multi.c:88]: event_cb(): Cell for handler 0x7f78f8c79b10 not found in table Oct 13 07:42:27 kamailio[4355]: INFO: http_async_client [http_multi.c:88]: event_cb(): Cell for handler 0x7f78f8c79b10 not found in table Oct 13 07:42:32 kamailio[4355]: INFO: http_async_client [http_multi.c:88]: event_cb(): Cell for handler 0x7f78f8c79b10 not found in table Oct 13 07:42:37 kamailio[4355]: INFO: http_async_client [http_multi.c:88]: event_cb(): Cell for handler 0x7f78f8c79b10 not found in table ``` Using docker image built on trixie: https://pastebin.com/0wZ0X9wb Not sure how to reproduce, it just appear on testing machine after couple of days. Unfortunately we used 5.6.3 before this, so not sure when did it break for us. http_async_client usage: ``` $http_req(hdr) = "Content-Type: application/json"; $http_req(hdr) = "Expect: "; $http_req(body) = $dlg_var(http_body); http_async_query("${URL}/RoutingService/route", "ROUTING_RESPONSE"); ``` Memory looks fine, but one of four CPU core spike to 96%. <img width="1119" height="955" alt="Image" src="https://github.com/user-attachments/assets/ffff8680-84ad-4866-9892-a6e6eefd…" /> core.tcp_info, mod.stats all shm, mod.stats all pkg https://pastebin.com/QLZ8mZdD -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4431 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4431(a)github.com>

4 8

[kamailio/kamailio] topos: Allow contact a/b host like user part (PR #4246)
by Xenofon Karamanos 16 Apr '26

16 Apr '26

#### 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  In this PR we introduce a new mode and two new parameters for accomplishing the same thing for user part also in domain part. Docs incoming if no significant changes are needed. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/4246 -- Commit Summary -- * topos: Add new contact_mode=3 and 2 new modparam for contact host domains * topos: Refactor contact_mode handling * topos: Append port and protocol param -- File Changes -- M src/modules/topos/topos_mod.c (13) M src/modules/topos/tps_storage.c (428) M src/modules/topos/tps_storage.h (2) -- Patch Links -- https://github.com/kamailio/kamailio/pull/4246.patch https://github.com/kamailio/kamailio/pull/4246.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4246 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/4246(a)github.com>

4 8

[kamailio/kamailio] jwt module - build by default and upload to deb.kamailio.org (Issue #4416)
by Michael Kanchuker 07 Apr '26

07 Apr '26

mkl262 created an issue (kamailio/kamailio#4416) Hello, Im asking to add the JWT Module to the default list of modules that are being built and uploaded to [deb.kamailio.org](https://deb.kamailio.org/). Will editing the CMAKE scripts will be enough (in which case I can open a PR for it), or does it require modifying the Jenkins pipelines? Thanks, Michael. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4416 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4416(a)github.com>

3 9

[kamailio/kamailio] Kamailio 5.4.x dialog profiles functionality dead-lock on certain high-load scenarios (Issue #2923)
by Henning Westerholt 03 Apr '26

03 Apr '26

### Description The Kamailio 5.4.x dialog profiles functionality can lead to dead-lock on certain high-load scenarios. The Kamailio dialog profiles are used to track parallel channels for about 200 outgoing PSTN carrier interconnections. During high traffic times (like several thousands parallel calls) the Kamailio server will frequently (e.g. hourly) goes into an end-less loop while executing get_profile_size in the configuration script. This causes the locking for the dialog profiles never be released and Kamailio will stop serving traffic. Internal monitoring tools and RPC commands stay working, as long as they do not touch the dialog functionality. A similar (dedicated) Kamailio setup is used for tracking parallel channels for customers. Here the dead-lock is not observed that frequently, but aparentely also some crashes happens in a much longer time interval. ### Troubleshooting After analysis of the back-traces with GDB the get_profile_size() function was removed from the configuration script. After this change the crash did not happened anymore for several days. #### Reproduction Issue could not be reproduced so far. #### Debugging Data ##### bt 1 (some data removed) (gdb) bt \# 0 0x00007f57cf3b00da in get_profile_size (profile=0x7f50ccbc7e80, value=0x7ffd9928f300) at dlg_profile.c:859 n = 364 i = 12 ph = 0x7f50d3e4b7d0 \# 1 0x00007f57cf419c67 in w_get_profile_size_helper (msg=0x7f57d699d418, profile=0x7f50ccbc7e80, value=0x7ffd9928f300, spd=0x7f57d6916960) at dialog.c:941 \# 2 0x00007f57cf41a459 in w_get_profile_size3 (msg=0x7f57d699d418, profile=0x7f50ccbc7e80, value=0x7f57d6935118, result=0x7f57d6916960) at dialog.c:982 \# 3 0x0000000000463fea in do_action (h=0x7ffd99293610, a=0x7f57d6936488, msg=0x7f57d699d418) at core/action.c:1094 \# 4 0x00000000004711ee in run_actions (h=0x7ffd99293610, a=0x7f57d6936488, msg=0x7f57d699d418) at core/action.c:1581 \# 5 0x000000000046058b in do_action (h=0x7ffd99293610, a=0x7f57d690fda8, msg=0x7f57d699d418) at core/action.c:700 The first back-trace was taking from a running process with gdb. The counter in f0 does not increased that much during this time, probably due the overflow of the loop counter. ##### bt2 (analysis with data structure with gdb scripts) Here the loop counter in f0 showed a really high value. Expected size of dialog profiles hash table: (gdb) p profile->entries[3] $4 = {first = 0x7f9bfd4aad98, content = 2068} (gdb) p profile->entries[7] $3 = {first = 0x7f9c12079f70, content = 784} (gdb) p profile->entries[12] $6 = {first = 0x7f9c02be5d50, content = 7600} (gdb) p profile->entries[14] $2 = {first = 0x7f9bff636de8, content = 6764} hash table bucket 14 shows a lot of corruption and the loop never ends (carrier names and IPs replaced). The list for hash bucket 7 got linked to the list for hash bucket 14: counter 6755: prev 0x7f9c0b9dcde0 - current 0x7f9c02e5b378 - next 0x7f9c0a5f9ba0 - value carrier1-XX.XX - hash 14 counter 6756: prev 0x7f9c02e5b378 - current 0x7f9c0a5f9ba0 - next 0x7f9c0860b968 - value carrier1-XX.XX▒▒▒▒ - hash 14 counter 6757: prev 0x7f9c0a5f9ba0 - current 0x7f9c0860b968 - next 0x7f9bfe3f3a78 - value carrier1-XX.XX▒▒▒▒ - hash 14 counter 6758: prev 0x7f9c0860b968 - current 0x7f9bfe3f3a78 - next 0x7f9c10d977f0 - value carrier1-XX.XX - hash 14 counter 6759: prev 0x7f9bfe3f3a78 - current 0x7f9c10d977f0 - next 0x7f9c0ae198b0 - value carrier2-XX.XX▒▒▒▒ - hash 7 counter 6760: prev 0x7f9c10d977f0 - current 0x7f9c0ae198b0 - next 0x7f9c12079f70 - value carrier3-XX.XX - hash 7 counter 6761: prev 0x7f9c0ae198b0 - current 0x7f9c12079f70 - next 0x7f9c011f2540 - value-carrier2-XX.XX▒▒▒▒ - hash 7 counter 6762: prev 0x7f9c12079f70 - current 0x7f9c011f2540 - next 0x7f9bfff886f0 - value carrier2-XX.XX▒▒▒▒ - hash 7 counter 6763: prev 0x7f9c011f2540 - current 0x7f9bfff886f0 - next 0x7f9c05db00a8 - value carrier3-XX.XX= - hash 7 [...] counter 28270: prev 0x7f9c019d06e8 - current 0x7f9bfaf18290 - next 0x7f9c12c90680 - value carrier2-XX.XX▒▒▒▒ - hash 7 counter 28271: prev 0x7f9bfaf18290 - current 0x7f9c12c90680 - next 0x7f9c086a2b58 - value-carrier2-XX.XX▒▒▒▒ - hash 7 counter 28272: prev 0x7f9c12c90680 - current 0x7f9c086a2b58 - next 0x7f9c0b4f09e8 - value carrier2-XX.XX▒▒▒▒ - hash 7 [...] hash table bucket 7 is still consistent regarding the loop, but already shows initial sign of corruption. There is one item of the list for hash bucket 14 visible: counter 780: prev 0x7f9c0db57ac8 - current 0x7f9c02225700 - next 0x7f9bfbf7db08 - value carrier2-XX.XX▒▒▒▒ - hash 7 counter 781: prev 0x7f9c02225700 - current 0x7f9bfbf7db08 - next 0x7f9c10d977f0 - value carrier1-XX.XX- hash 14 counter 782: prev 0x7f9bfe3f3a78 - current 0x7f9c10d977f0 - next 0x7f9c0ae198b0 - value carrier2-XX.XX▒▒▒▒ - hash 7 counter 783: prev 0x7f9c10d977f0 - current 0x7f9c0ae198b0 - next 0x7f9c12079f70 - value carrier3-XX.XX - hash 7 total size of hash table is 784 #### Log Messages No special log messages observed. #### SIP Traffic SIP traffic looked ok during analysis of the core dumps. ### Possible Solutions * adding additional safe-guards for the get_profile_size function to not access data from other hash buckets * stopping the loop counter after some threshold * finding and fixing the source of the internal data corruption (obviously) * refactoring the dialog modules to use another approach for storing the dialog profile information ### Additional Information * **Kamailio version**: Kamailio 5.4.7, compiled from git repository * **Operating System**: CentOS 7.9 -- 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/2923

3 8

[kamailio/kamailio] http_client leaks TLS shared memory (Issue #4231)
by Alexander Bakker 01 Apr '26

01 Apr '26

alexbakker created an issue (kamailio/kamailio#4231) ### Description Performing an HTTPS request using the ``http_client`` module results in a shared memory leak, seemingly related to TLS. ### Troubleshooting #### Reproduction Our use case for ``http_client`` is to update an htable with the latest banned IP's from APIBAN as described here: https://github.com/apiban/apiban?tab=readme-ov-file#integration-into-kamail…. Normally, we refresh the list of banned IP's once every 15 minutes, so the shared memory usage grows fairly slowly. The issue can be reproduced using the Kamailio configuration file below. To demonstrate the issue and make the shared memory usage grow faster, we set up a timer that calls ``http_client_query`` in a tight loop. To prevent unnecessary load on the APIBAN infrastructure, we request an example file from my personal server instead. ``` #!KAMAILIO debug=2 log_stderror=yes fork=yes enable_tls=1 loadmodule "tls.so" loadmodule "cfg_rpc.so" loadmodule "pv.so" loadmodule "xlog.so" loadmodule "ctl.so" loadmodule "rtimer.so" loadmodule "http_client.so" modparam("tls", "certificate", "") modparam("tls", "private_key", "") modparam("rtimer", "timer", "name=apiban;interval=100u;mode=1;") modparam("rtimer", "exec", "timer=apiban;route=APIBAN;") route[APIBAN] { xinfo("running apiban refresh\n"); http_client_query("https://alexbakker.me/u/7bvjn9jfas.txt", "$var(banned)"); } ``` Start Kamailio: ``` kamailio -f kamailio.cfg -DD ``` And then watch the shared memory usage grow rapidly: ``` watch -n1 -- kamcmd core.shmmem ``` #### Log Messages Eventually, Kamailio will run out of shared memory and print the following messages to the log: ``` 21(184184) INFO: <script>: running apiban refresh 21(184184) ERROR: http_client [functions.c:471]: curL_request_url(): failed to perform curl (56) (url: https://alexbakker.me/u/7bvjn9jfas.txt) 21(184184) INFO: <script>: running apiban refresh 21(184184) ERROR: http_client [functions.c:471]: curL_request_url(): failed to perform curl (56) (url: https://alexbakker.me/u/7bvjn9jfas.txt) 21(184184) INFO: <script>: running apiban refresh 21(184184) WARNING: http_client [functions.c:453]: curL_request_url(): TLS error in curl connection (url: https://alexbakker.me/u/7bvjn9jfas.txt) 21(184184) INFO: <script>: running apiban refresh 21(184184) WARNING: http_client [functions.c:453]: curL_request_url(): TLS error in curl connection (url: https://alexbakker.me/u/7bvjn9jfas.txt) 21(184184) INFO: <script>: running apiban refresh 21(184184) WARNING: http_client [functions.c:453]: curL_request_url(): TLS error in curl connection (url: https://alexbakker.me/u/7bvjn9jfas.txt) 21(184184) INFO: <script>: running apiban refresh 21(184184) WARNING: http_client [functions.c:453]: curL_request_url(): TLS error in curl connection (url: https://alexbakker.me/u/7bvjn9jfas.txt) 21(184184) INFO: <script>: running apiban refresh 21(184184) ERROR: <core> [core/mem/q_malloc.c:758]: qm_realloc(): qm_realloc(0x7585c73c4000, 1024) called from tls: tls_init.c: ser_realloc(372), module: tls; qm_malloc() failed! 21(184184) INFO: <script>: running apiban refresh 21(184184) INFO: <script>: running apiban refresh 21(184184) ERROR: <core> [core/mem/q_malloc.c:758]: qm_realloc(): qm_realloc(0x7585c73c4000, 1024) called from tls: tls_init.c: ser_realloc(372), module: tls; qm_malloc() failed! 21(184184) WARNING: http_client [functions.c:453]: curL_request_url(): TLS error in curl connection (url: https://alexbakker.me/u/7bvjn9jfas.txt) 21(184184) INFO: <script>: running apiban refresh 21(184184) INFO: <script>: running apiban refresh 21(184184) WARNING: http_client [functions.c:463]: curL_request_url(): TLS CA certificate read error (url: https://alexbakker.me/u/7bvjn9jfas.txt) ``` ``mem_dump_shm`` reports a large list of TLS-related allocations. Just sharing the last few lines here, as they're seemingly all from the same location. ``` 20(204914) ALERT: qm_status: qm_status(): 28500. N address=0x705ab3178710 frag=0x705ab31786d0 size=112 used=1 20(204914) ALERT: qm_status: qm_status(): alloc'd from tls: tls_init.c: ser_malloc(364) 20(204914) ALERT: qm_status: qm_status(): start check=f0f0f0f0, end check= c0c0c0c0, abcdefed 20(204914) ALERT: qm_status: qm_status(): 28501. N address=0x705ab31787f0 frag=0x705ab31787b0 size=48 used=1 20(204914) ALERT: qm_status: qm_status(): alloc'd from tls: tls_init.c: ser_malloc(364) 20(204914) ALERT: qm_status: qm_status(): start check=f0f0f0f0, end check= c0c0c0c0, abcdefed 20(204914) ALERT: qm_status: qm_status(): 28502. N address=0x705ab3178890 frag=0x705ab3178850 size=32 used=1 20(204914) ALERT: qm_status: qm_status(): alloc'd from tls: tls_init.c: ser_malloc(364) 20(204914) ALERT: qm_status: qm_status(): start check=f0f0f0f0, end check= c0c0c0c0, abcdefed 20(204914) ALERT: qm_status: qm_status(): 28503. N address=0x705ab3178920 frag=0x705ab31788e0 size=32 used=1 20(204914) ALERT: qm_status: qm_status(): alloc'd from tls: tls_init.c: ser_malloc(364) 20(204914) ALERT: qm_status: qm_status(): start check=f0f0f0f0, end check= c0c0c0c0, abcdefed 20(204914) ALERT: qm_status: qm_status(): 28504. N address=0x705ab31789b0 frag=0x705ab3178970 size=32 used=1 20(204914) ALERT: qm_status: qm_status(): alloc'd from tls: tls_init.c: ser_malloc(364) 20(204914) ALERT: qm_status: qm_status(): start check=f0f0f0f0, end check= c0c0c0c0, abcdefed 20(204914) ALERT: qm_status: qm_status(): 28505. N address=0x705ab3178a40 frag=0x705ab3178a00 size=48 used=1 20(204914) ALERT: qm_status: qm_status(): alloc'd from tls: tls_init.c: ser_malloc(364) 20(204914) ALERT: qm_status: qm_status(): start check=f0f0f0f0, end check= c0c0c0c0, abcdefed 20(204914) ALERT: qm_status: qm_status(): 28506. N address=0x705ab3178ae0 frag=0x705ab3178aa0 size=48 used=1 20(204914) ALERT: qm_status: qm_status(): alloc'd from tls: tls_init.c: ser_malloc(364) 20(204914) ALERT: qm_status: qm_status(): start check=f0f0f0f0, end check= c0c0c0c0, abcdefed 20(204914) ALERT: qm_status: qm_status(): 28507. N address=0x705ab3178b80 frag=0x705ab3178b40 size=144 used=1 20(204914) ALERT: qm_status: qm_status(): alloc'd from tls: tls_init.c: ser_malloc(364) 20(204914) ALERT: qm_status: qm_status(): start check=f0f0f0f0, end check= c0c0c0c0, abcdefed 20(204914) ALERT: qm_status: qm_status(): 28509. N address=0x705ab3178d00 frag=0x705ab3178cc0 size=32 used=1 20(204914) ALERT: qm_status: qm_status(): alloc'd from tls: tls_init.c: ser_malloc(364) 20(204914) ALERT: qm_status: qm_status(): start check=f0f0f0f0, end check= c0c0c0c0, abcdefed 20(204914) ALERT: qm_status: qm_status(): 28510. N address=0x705ab3178d90 frag=0x705ab3178d50 size=32 used=1 20(204914) ALERT: qm_status: qm_status(): alloc'd from tls: tls_init.c: ser_realloc(372) 20(204914) ALERT: qm_status: qm_status(): start check=f0f0f0f0, end check= c0c0c0c0, abcdefed 20(204914) ALERT: qm_status: qm_status(): 28512. N address=0x705ab3178ea0 frag=0x705ab3178e60 size=16 used=1 20(204914) ALERT: qm_status: qm_status(): alloc'd from tls: tls_init.c: ser_malloc(364) 20(204914) ALERT: qm_status: qm_status(): start check=f0f0f0f0, end check= c0c0c0c0, abcdefed 20(204914) ALERT: qm_status: qm_status(): 28513. N address=0x705ab3178f20 frag=0x705ab3178ee0 size=32 used=1 20(204914) ALERT: qm_status: qm_status(): alloc'd from tls: tls_init.c: ser_malloc(364) 20(204914) ALERT: qm_status: qm_status(): start check=f0f0f0f0, end check= c0c0c0c0, abcdefed 20(204914) ALERT: qm_status: qm_status(): 28515. N address=0x705ab317a3c0 frag=0x705ab317a380 size=112 used=1 20(204914) ALERT: qm_status: qm_status(): alloc'd from tls: tls_init.c: ser_malloc(364) 20(204914) ALERT: qm_status: qm_status(): start check=f0f0f0f0, end check= c0c0c0c0, abcdefed 20(204914) ALERT: qm_status: qm_status(): 28516. N address=0x705ab317a4a0 frag=0x705ab317a460 size=512 used=1 20(204914) ALERT: qm_status: qm_status(): alloc'd from tls: tls_init.c: ser_malloc(364) 20(204914) ALERT: qm_status: qm_status(): start check=f0f0f0f0, end check= c0c0c0c0, abcdefed 20(204914) ALERT: qm_status: qm_status(): 28517. N address=0x705ab317a710 frag=0x705ab317a6d0 size=1504 used=1 20(204914) ALERT: qm_status: qm_status(): alloc'd from tls: tls_init.c: ser_malloc(364) 20(204914) ALERT: qm_status: qm_status(): start check=f0f0f0f0, end check= c0c0c0c0, abcdefed 20(204914) ALERT: qm_status: qm_status(): 28518. N address=0x705ab317ad60 frag=0x705ab317ad20 size=1040 used=1 20(204914) ALERT: qm_status: qm_status(): alloc'd from tls: tls_init.c: ser_malloc(364) 20(204914) ALERT: qm_status: qm_status(): start check=f0f0f0f0, end check= c0c0c0c0, abcdefed ``` ### Possible Solutions I'm not aware of a workaround for this issue. For our specific use case, I'll move the APIBAN polling out of Kamailio to a separate process for now. ### Additional Information I've verified that this issue is reproducible on ``5.5.7``, ``5.6.6``, ``5.7.6``, ``5.8.6`` and ``6.0.1``. * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 6.0.1 (x86_64/linux) fce50d 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: fce50d compiled on 06:42:29 May 6 2025 with gcc 12.2.0 ``` * **Operating System**: ``` $ lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 12 (bookworm) Release: 12 Codename: bookworm $ uname -a Linux ip-10-146-128-121 6.1.0-32-cloud-arm64 #1 SMP Debian 6.1.129-1 (2025-03-06) aarch64 GNU/Linux ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4231 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4231(a)github.com>

6 26

[kamailio/kamailio] cmake glitches (Issue #4317)
by Дилян Палаузов 25 Mar '26

25 Mar '26

dilyanpalauzov created an issue (kamailio/kamailio#4317) In the 6.0 branch the FLAVOUR option allows in cmake-gui (ccmake) setting `kamailio` as only option. As it is no-op, it should not be displayed in cmake-gui. The option MODULE_GROUP_NAME is documented as „Group of modules to build (one or multiple space seperated group)“. In cmake-gui it allows with enter to toggle between several values: DEFAULT, STANDARD, COMMON, KSTANDARD, KMINI, KPCRE, KMYSQL, KPOSTGRES, …. Using ccmake it is not possible to to set multiple values. The help string should mention all possible values. It should be plural: groups. The options in ccmake-gui `XSLT_VALIDATE,` and `XSLT_VERBOSE,` have a comma in their names too much. The option `CMAKE_BUILD_TYPE` allows in Kamailio toggling between four possible values: Debug, Release, MinSizeRel and RelWithDebInfo. ClamAV adds one more value for cmake-gui: `None`. This toggling is not yet available in the build system of cmake (when building cmake using cmake) - https://gitlab.kitware.com/cmake/cmake/-/issues/26434 . Is it reasonable to have for CMAKE_BUILD_TYPE also `None` as permitted value? I do not know the answer, that is why I am raising this question. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4317 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4317(a)github.com>

3 10

[kamailio/kamailio] tls_wolfssl: assertion (Issue #4391)
by Dennis 18 Mar '26

18 Mar '26

Den4t created an issue (kamailio/kamailio#4391) Hi ! Kamailio v.5.8.6, used as webrtc registrar/GW, wolfssl v.5.7.4, high call load, OS: Ubuntu 22 Periodically kamailio dumps core with assertion: ``` Program terminated with signal SIGABRT, Aborted. #0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=140585212159808) at ./nptl/pthread_kill.c:44 44 ./nptl/pthread_kill.c: No such file or directory. (gdb) backtrace #0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=140585212159808) at ./nptl/pthread_kill.c:44 #1 __pthread_kill_internal (signo=6, threadid=140585212159808) at ./nptl/pthread_kill.c:78 #2 __GI___pthread_kill (threadid=140585212159808, signo=signo@entry=6) at ./nptl/pthread_kill.c:89 #3 0x00007fdc8ba5f476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #4 0x00007fdc8ba457f3 in __GI_abort () at ./stdlib/abort.c:79 #5 0x00007fdc8ba4571b in __assert_fail_base (fmt=0x7fdc8bbfa130 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x7fdc7a6b299f "nw == bytes_read", file=0x7fdc7a6b089a "tls_server.c", line=1056, function=<optimized out>) at ./assert/assert.c:94 #6 0x00007fdc8ba56e96 in __GI___assert_fail (assertion=0x7fdc7a6b299f "nw == bytes_read", file=0x7fdc7a6b089a "tls_server.c", line=1056, function=0x7fdc7a6b5068 "tls_h_read_f") at ./assert/assert.c:103 #7 0x00007fdc7a48cd89 in tls_h_read_f () from /usr/lib64/kamailio/modules/tls_wolfssl.so #8 0x00005622baa30e8e in ?? () #9 0x00005622baa3273b in tcp_read_req () #10 0x00005622baa3c7c2 in ?? () #11 0x00005622babf61d6 in ?? () #12 0x00005622baa42b87 in tcp_receive_loop () #13 0x00005622baa24188 in tcp_init_children () #14 0x00005622ba7b1b33 in main_loop () #15 0x00005622ba7a5888 in main () ``` I couldn't reproduce this issue in a lab, but I think that possibly the issue depends on TLS traffic burst behavior. We have some buggy webrtc clients, which floods using MESSAGE requests with high CPS periodically. I assume that might be this traffic somehow fills the BIO buffers in wolfssl. As result wolfSSL_BIO_write function returns with error. I have no time to debug deeply, so I made a quick fix here: https://github.com/Den4t/kamailio/commit/20579f02354356dedb5f5ac1f9bff65314… I see following logs after the fix has been applied: ``` 2025-09-02T09:24:04.393019+03:00 iptel /usr/sbin/kamailio[892554]: BUG: tls_wolfssl [tls_server.c:1058]: tls_h_read_f(): tls_h_read_f assertion check nw == bytes_read (nw=-1, bytes_read=7115, npos=-1) 2025-09-02T10:44:21.556481+03:00 iptel /usr/sbin/kamailio[892559]: BUG: tls_wolfssl [tls_server.c:1058]: tls_h_read_f(): tls_h_read_f assertion check nw == bytes_read (nw=-1, bytes_read=6201, npos=-1) 2025-09-02T10:58:31.563456+03:00 iptel /usr/sbin/kamailio[892558]: BUG: tls_wolfssl [tls_server.c:1058]: tls_h_read_f(): tls_h_read_f assertion check nw == bytes_read (nw=-1, bytes_read=7587, npos=-1) ``` But service is alive. It is better to lose one session than the whole service. In any case this is just a crutch for quick problem fix, so it would be nice if tls_wolfssl module's author took a deeper look at the problem. P.S. I assume that module's logic should check BIO flags after the call to wolfSSL_BIO_write, f.e. this function can return error with bio flag WOLFSSL_BIO_FLAG_RETRY set. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4391 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4391(a)github.com>

5 13

[kamailio/kamailio] tls_wolfssl: crash qm_free / qm_debug_check_frag (Issue #4074)
by Fred Posner 18 Mar '26

18 Mar '26

### Introduction First, I apologize for the lack of detail here. I am unable to get a core dump and as a production box, I was unable to run in debug mode. ### Description Using Kamailio 5.8.4 on Debian 12, every 60-80 minutes, the software would crash, blaming tls_wolfssl, such as: ``` 2024-12-16T14:58:27.554497+00:00 ip-172-16-0-52 /usr/local/sbin/kamailio[9084]: CRITICAL: <core> [core/mem/q_malloc.c:535]: qm_free(): BUG: bad pointer 0x1 (out of memory block!) called from tls_wolfssl: tls_init.c: ser_free(240) - ignoring 2024-12-16T14:58:27.554555+00:00 ip-172-16-0-52 /usr/local/sbin/kamailio[9084]: CRITICAL: <core> [core/mem/q_malloc.c:126]: qm_debug_check_frag(): BUG: qm: fragm. 0x7f3440ba7560 (address 0x7f3440ba75a0) beginning overwritten (23)! Memory allocator was called from tls_wolfssl: tls_init.c:240. Fragment marked by :29. Exec from core/mem/q_malloc.c:546. 2024-12-16T14:58:27.616558+00:00 ip-172-16-0-52 /usr/local/sbin/kamailio[9089]: CRITICAL: <core> [core/pass_fd.c:281]: receive_fd(): EOF on 103 2024-12-16T14:58:27.617684+00:00 ip-172-16-0-52 /usr/local/sbin/kamailio[8992]: ALERT: <core> [main.c:805]: handle_sigs(): child process 9084 exited by a signal 6 2024-12-16T14:58:27.618339+00:00 ip-172-16-0-52 /usr/local/sbin/kamailio[8992]: ALERT: <core> [main.c:809]: handle_sigs(): core was not generated 2024-12-16T14:58:27.618477+00:00 ip-172-16-0-52 /usr/local/sbin/kamailio[8992]: INFO: <core> [main.c:832]: handle_sigs(): terminating due to SIGCHLD 2024-12-16T14:58:27.618589+00:00 ip-172-16-0-52 /usr/local/sbin/kamailio[9088]: INFO: <core> [main.c:888]: sig_usr(): signal 15 received ``` ``` 2024-12-16T14:57:52.029277+00:00 ip-172-16-0-73 /usr/local/sbin/kamailio[21605]: CRITICAL: <core> [core/mem/q_malloc.c:535]: qm_free(): BUG: bad pointer 0x1 (out of memory block!) called from tls_wolfssl: tls_init.c: ser_free(240) - ignoring 2024-12-16T14:57:52.029347+00:00 ip-172-16-0-73 /usr/local/sbin/kamailio[21605]: CRITICAL: <core> [core/mem/q_malloc.c:126]: qm_debug_check_frag(): BUG: qm: fragm. 0x7f085996b500 (address 0x7f085996b540) beginning overwritten (0)! Memory allocator was called from tls_wolfssl: tls_init.c:240. Fragment marked by (null):0. Exec from core/mem/q_malloc.c:546. 2024-12-16T14:57:52.048597+00:00 ip-172-16-0-73 /usr/local/sbin/kamailio[21611]: CRITICAL: <core> [core/pass_fd.c:281]: receive_fd(): EOF on 101 2024-12-16T14:57:52.048921+00:00 ip-172-16-0-73 /usr/local/sbin/kamailio[21512]: ALERT: <core> [main.c:805]: handle_sigs(): child process 21605 exited by a signal 6 2024-12-16T14:57:52.048953+00:00 ip-172-16-0-73 /usr/local/sbin/kamailio[21512]: ALERT: <core> [main.c:809]: handle_sigs(): core was not generated 2024-12-16T14:57:52.048975+00:00 ip-172-16-0-73 /usr/local/sbin/kamailio[21512]: INFO: <core> [main.c:832]: handle_sigs(): terminating due to SIGCHLD 2024-12-16T14:57:52.048997+00:00 ip-172-16-0-73 /usr/local/sbin/kamailio[21609]: INFO: <core> [main.c:888]: sig_usr(): signal 15 received ``` ``` 2024-12-16T16:21:35.967576+00:00 ip-172-16-0-52 /usr/local/sbin/kamailio[10591]: CRITICAL: <core> [core/mem/q_malloc.c:126]: qm_debug_check_frag(): BUG: qm: fragm. 0x7f442778d110 (address 0x7f442778d150) beginning overwritten (0)! Memory allocator was called from tls_wolfssl: tls_init.c:240. Fragment marked by (null):0. Exec from core/mem/q_malloc.c:546. ``` ``` 2024-12-16T13:31:55.995222+00:00 ip-172-16-0-52 /usr/local/sbin/kamailio[7602]: CRITICAL: <core> [core/mem/q_malloc.c:555]: qm_free(): BUG: freeing already freed pointer (0x7f8e55830a70), called from tls_wolfssl: tls_init.c: ser_free(240), first free tls_wolfssl: tls_init.c: ser_malloc(228) - ignoring 2024-12-16T13:32:40.093954+00:00 ip-172-16-0-52 /usr/local/sbin/kamailio[7603]: CRITICAL: <core> [core/mem/q_malloc.c:535]: qm_free(): BUG: bad pointer 0x7a100000000 (out of memory block!) called from tls_wolfssl: tls_init.c: ser_free(240) - ignoring 2024-12-16T13:32:40.094047+00:00 ip-172-16-0-52 /usr/local/sbin/kamailio[7603]: CRITICAL: <core> [core/mem/q_malloc.c:126]: qm_debug_check_frag(): BUG: qm: fragm. 0x7f8e55762720 (address 0x7f8e55762760) beginning overwritten (0)! Memory allocator was called from tls_wolfssl: tls_init.c:240. Fragment marked by (null):0. Exec from core/mem/q_malloc.c:546. 2024-12-16T13:32:40.260913+00:00 ip-172-16-0-52 /usr/local/sbin/kamailio[7504]: CRITICAL: <core> [core/mem/q_malloc.c:555]: qm_free(): BUG: freeing already freed pointer (0x7f8e55761a70), called from core: core/tcp_main.c: _tcpconn_free(1666), first free tls_wolfssl: tls_init.c: ser_free(240) - ignoring 2024-12-16T13:32:40.263520+00:00 ip-172-16-0-52 /usr/local/sbin/kamailio[7504]: CRITICAL: <core> [core/mem/q_malloc.c:126]: qm_debug_check_frag(): BUG: qm: fragm. 0x7f8e55762720 (address 0x7f8e55762760) beginning overwritten (0)! Memory allocator was called from tls_wolfssl: tls_init.c:240. Fragment marked by (null):0. Exec from core/mem/q_malloc.c:546. ``` The system was handling ~900 TLS registrations with ~2700 presence SUBSCRIBE events. **Running the same config with `tls.so` does not result in crash.** ### Additional Information * **Kamailio Version** - 5.8.4 ``` version: kamailio 5.8.4 (x86_64/linux) 598105-dirty 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: 598105 -dirty compiled on 04:31:34 Dec 16 2024 with gcc 12.2.0 ``` * **Operating System**: ``` Distributor ID: Debian Description: Debian GNU/Linux 12 (bookworm) Release: 12 Codename: bookworm Linux ip-172-16-0-52 6.1.0-28-cloud-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.119-1 (2024-11-22) x86_64 GNU/Linux ``` * TCP Settings ``` children=16 disable_tcp=no tcp_connection_lifetime=3605 tcp_accept_no_cl=yes tcp_max_connections=8192 tcp_defer_accept=yes tcp_accept_unique=0 tcp_connection_lifetime=3605 tcp_connection_match=1 tcp_connect_timeout=10 tcp_crlf_ping=yes tcp_linger2=1 tcp_keepalive=yes tcp_reuse_port=yes tcp_keepidle=20 tcp_keepintvl=15 tcp_rd_buf_size=65536 tcp_msg_data_timeout=40 tcp_msg_read_timeout=40 tcp_check_timer=20 tls_threads_mode=2 tls_max_connections=8192 ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4074 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4074(a)github.com>

3 8

[kamailio/kamailio] Corrupted output with log-engine json (Issue #4203)
by Matteo 04 Mar '26

04 Mar '26

xadhoom created an issue (kamailio/kamailio#4203)  ### Description Enabled json logging engine, with the following setup: - kam cmd line params: `--log-engine=json:Mp` - prefix: `log_prefix=", \"callid\": \"$ci\",\"srcip\": \"$si\", \"ts\": $TV(Sn), \"method\": \"$rm\", \"mt\": $mt, \"ua\": \"$(ua{s.escape.common})\", \"cseq\": \"$hdr(CSeq)\", \"status\": $rs "` - another prefix (same result): `log_prefix=", \"callid\": \"$ci\", \"ts\": $TV(Sn) "` What I see that certain json lines are truncated, for example - one line is interrupted by another json entry - one line starts "truncated" ### Troubleshooting What I can observe is that seems to happens always with same "kind" of line, usually internal logs, which don't have callid etc. #### Log Messages  The following first 3 lines are ok, then the latest is corrupted: ``` { "time": "2025-04-04T15:51:44.448427533Z", "idx": 193, "pid": 200, "level": "DEBUG", "module": "core", "file": "core/receive.c", "line": 128, "function": "sip_check_fline", "message": "first line indicates a SIP reply" } { "time": "2025-04-04T15:51:44.448682606Z", "idx": 194, "pid": 201, "level": "DEBUG", "module": "core", "file": "core/receive.c", "line": 128, "function": "sip_check_fline", "message": "first line indicates a SIP reply" } { "time": "2025-04-04T15:52:14.448279053Z", "idx": 195, "pid": 202, "level": "DEBUG", "module": "core", "file": "core/receive.c", "line": 128, "function": "sip_check_fline", "message": "first line indicates a SIP reply" } { "time": "2025-04-04T15:52:14.448505797Z", "idx": 196, "pid": 203, "level": "DEBUG", "module": "core", "file": "core/receive.c"{ "time": "2025-04-04T15:52:14.448508084Z", "idx": 195, "pid": 202, "level": "DEBUG", "module": "core", "file": "core/parser/msg, "line": 128, "function": "sip_check_fline", "message": "first line indicates a SIP reply" } ``` or (notice 2nd line or 5th one) ``` { "time": "2025-04-04T16:13:33.789641936Z", "idx": 221, "pid": 228, "level": "DEBUG", "module": "core", "file": "core/receive.c"{ "time": "2025-04-04T16:13:33.789642978Z", "idx": 222, "pid": 229, "level": "DEBUG", "module": "core", "file": "core/xavp.c", ", "line": 265, "function": "ksr_evrt_pre_routing", "callid": "5715efe40e9b7721-264(a)127.0.0.1", "ts": 1743783213.789640 , "message": "event route core:pre-routing not defined" } line": 630, "function": "xavp_destroy_list", "callid": "5715efe40e9b7720-264(a)127.0.0.1", "ts": 1743783213.789527 , "message": "destroying xavp list (nil)" } { "time": "2025-04-04T16:13:33.789646470Z", "idx": 222, "pid": 229, "level": "DEBUG", "module": "core", "file": "core/xavp.c", "line": 630, "function": "xavp_destroy_list", "callid": "5715efe40e9b7720-264(a)127.0.0.1", "ts": 1743783213.789527 , "message": "destroying xavp list (nil)" } { "time": "2025-04-04T16:13:33.789648201Z", "idx": 221, "pid": 228, "level": "DEBUG", "module": "tm", "file": "t_lookup.c", "line": 1579, "function": "t_check_msg", "callid": "5715efe40e9b7721-264(a)127.0.0.1", "ts": 1743783213.789640 , "message": "msg (0x7f{ "time": "2025-04-04T16:13:33.789649346Z", "idx": 222, "pid": 229, "level": "DEBUG", "module": "core", "file": "core/receive.c"8f7a693c50) id=2/228 global id=1/228 T start=0xffffffffffffffff" } , "line": 637, "function": "receive_msg", "callid": "5715efe40e9b7720-264(a)127.0.0.1", "ts": 1743783213.789527 , "message": "cleaning up" } { "time": "2025-04-04T16:13:33.789652839Z", "idx": 221, "pid": 228, "level": "DEBUG", "module": "tm", "file": "t_lookup.c", "line": 1424, "function": "t_reply_matching", "callid": "5715efe40e9b7721-264(a)127.0.0.1", "ts": 1743783213.789640 , "message": "t_reply_matching: hash 26404 label 0 branch 0" } ``` ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` 6.0.1 ``` happens also with 5.8.x * **Operating System**:  ``` Debian noble, docker container ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4203 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4203(a)github.com>

4 9