sr-dev September 2025

sr-dev@lists.kamailio.org

10 participants
176 discussions

[kamailio/kamailio] Memory usage increases everytime tls.reload is executed (Issue #3823)
by Sebastian Denz 01 Feb '26

01 Feb '26

### 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>

10 50

[kamailio/kamailio] wolfssl: failed build on Alpine Linux (Issue #4374)
by sergey-safarov 29 Jan '26

29 Jan '26

sergey-safarov created an issue (kamailio/kamailio#4374) During build used `wolfssl-dev-5.7.6-r0` ``` In file included from /home/build/kamailio/pkg/kamailio/alpine/src/kamailio-6.0.1/src/modules/tls_wolfssl/tls_config.c:29: /home/build/kamailio/pkg/kamailio/alpine/src/kamailio-6.0.1/src/modules/tls_wolfssl/tls_util.h: In function 'tls_err_ret': /home/build/kamailio/pkg/kamailio/alpine/src/kamailio-6.0.1/src/modules/tls_wolfssl/tls_util.h:44:30: error: implicit declaration of function 'wolfSSL_get_servername'; did you mean 'wolfSSL_get_curve_name'? [-Wimplicit-function-declaration] 44 | sn = wolfSSL_get_servername(ssl, WOLFSSL_SNI_HOST_NAME); | ^~~~~~~~~~~~~~~~~~~~~~ | wolfSSL_get_curve_name /home/build/kamailio/pkg/kamailio/alpine/src/kamailio-6.0.1/src/modules/tls_wolfssl/tls_util.h:44:28: error: assignment to 'const char *' from 'int' makes pointer from integer without a cast [-Wint-conversion] 44 | sn = wolfSSL_get_servername(ssl, WOLFSSL_SNI_HOST_NAME); | ^ /home/build/kamailio/pkg/kamailio/alpine/src/kamailio-6.0.1/src/modules/tls_wolfssl/tls_util.h:46:30: error: implicit declaration of function 'ERR_get_error' [-Wimplicit-function-declaration] 46 | while((err = ERR_get_error())) { | ^~~~~~~~~~~~~ ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4374 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4374(a)github.com>

3 7

[kamailio/kamailio] ims_diameter_server not freeing shared memory (Issue #4116)
by MGrimby 28 Jan '26

28 Jan '26

### Description I have run in to an issue when sending diameter requests using the ims_diameter_server module. Shared memory keeps increasing and are not being freed until restart of kamailio. This leads to all shared memory is being used and no more are able to be allocated. This only happens when the request is sent synchronously. When sent asynchronously shared memory is being freed as far as I can see. Following functions have been used for sending requests. diameter_request([peer], appid, commandcode, message) diameter_request_async([peer], appid, commandcode, message) ### Troubleshooting Sent a bunch of diameter requests and verified that shared memory for the following functions are not freed. do_receive(600): AAATranslateMessage(500): AAACreateAVP(137): #### Reproduction It's possible to reproduce by sending sync diameter request and verify shared memory. Example of diameter request block ``` route[CHECK_LOCATION] { diameter_request("hss.ims.test.local", "16777217", "306", "[ " + "{ \"avpCode\":260, \"vendorId\":0, \"Flags\":64, \"list\":[ { \"avpCode\":266, \"vendorId\":0, \"Flags\":64, \"int32\":10415 }, { \"avpCode\":258, \"vendorId\":0, \"Flags\":64, \"int32\":16777217 } ] }, " + "{ \"avpCode\":277, \"vendorId\":0, \"Flags\":64, \"int32\":1 }, " + "{ \"avpCode\":283, \"vendorId\":0, \"Flags\":64, \"string\":\"ims.test.local\"}, " + "{ \"avpCode\":706, \"vendorId\":10415, \"Flags\":192, \"int32\":0 }, " + "{ \"avpCode\":700, \"vendorId\":10415, \"Flags\":192, \"list\": [ { \"avpCode\":601, \"vendorId\":10415, \"Flags\":192, \"string\":\"tel:" + $fU + "\" }]}, " + "{ \"avpCode\":707, \"vendorId\":10415, \"Flags\":192, \"int32\":0 }, " + "{ \"avpCode\":703, \"vendorId\":10415, \"Flags\":192, \"int32\":14 } ]"); xlog("L_INFO", "Sent Diameter request"); } ``` Stats cdp:replies_received = 343310 shmem:fragments = 142 shmem:free_size = 1221489992 shmem:max_used_size = 948242168 shmem:real_used_size = 925993656 shmem:total_size = 2147483648 shmem:used_size = 558205656 kamcmd mod.stats cdp shm do_receive(600): 256245808 AAATranslateMessage(500): 64420712 AAACreateAVP(137): 218100320 Total: 538774000 #### Debugging Data  ``` (paste your debugging data here) ``` #### Log Messages  ``` (paste your log messages here) ``` #### SIP Traffic  ``` (paste your sip traffic here) ``` ### Possible Solutions  ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.7.4 (x86_64/linux) dc393e 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: dc393e compiled on 13:56:27 Feb 27 2024 with gcc 8.5.0 ``` * **Operating System**:  ``` Linux bmatkamas1 4.18.0-553.16.1.el8_10.x86_64 #1 SMP Thu Aug 1 04:16:12 EDT 2024 x86_64 x86_64 x86_64 GNU/Linux Red Hat Enterprise Linux release 8.10 (Ootpa) ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4116 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4116(a)github.com>

4 9

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

26 Jan '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>

5 23

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

23 Jan '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>

4 7

[tracker] Assignee added: Assignment operators don't work
by sip-router 21 Jan '26

21 Jan '26

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A user has added themself to the list of users assigned to this task. FS#100 - Assignment operators don't work User who did this - Alex Hermann (axlh) http://sip-router.org/tracker/index.php?do=details&task_id=100 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

8 7

[kamailio/kamailio] Fixed segfault when using kazoo_query in kazoo mod (PR #4002)
by Remco van Vugt 19 Jan '26

19 Jan '26

A response to the amqp query caused a segfault in libc - Refactored parts of the code to be more readable and DRY - Split up functions for 3/4/5 arguments passed - Tested in 8.5.2 #### 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 The current state of the module was not usable anymore as everything up from 5.5.x caused a segfault when the kazoo_query method was executed. Refactored the module a bit to make sure it is works again 5.8.x You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/4002 -- Commit Summary -- * Fixed segfault when using kazoo_query in kazoo mod -- File Changes -- M src/modules/kazoo/kazoo.c (10) M src/modules/kazoo/kz_amqp.c (67) M src/modules/kazoo/kz_amqp.h (9) -- Patch Links -- https://github.com/kamailio/kamailio/pull/4002.patch https://github.com/kamailio/kamailio/pull/4002.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4002 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/4002(a)github.com>

4 18

[kamailio/kamailio] arm64 support issues (Issue #4235)
by Victor Seva 13 Jan '26

13 Jan '26

linuxmaniac created an issue (kamailio/kamailio#4235) Finally I had the time and patience to address the last issues in our deb environment. Now build flow is by _distribution/architecture_ so errors doesn't interfere in a healthy _distribution/architecture_ combination. > Follow up: same situation > > - **bookworm**: https://kamailio.sipwise.com/view/kamailiodev/job/kamailiodev-nightly-binar… > ``` > /usr/bin/make every-module group_include="kerlang" quiet=verbose > make[1]: Entering directory '/build/kamailio-6.1.0~dev1+bpo12.20250509084438.1' > /usr/bin/make -C src/ every-module > make[2]: Entering directory '/build/kamailio-6.1.0~dev1+bpo12.20250509084438.1/src' > config.mak loaded > Makefile.defs defs skipped > Makefile.defs defs skipped > qemu: uncaught target signal 11 (Segmentation fault) - core dumped > Segmentation fault > qemu: uncaught target signal 11 (Segmentation fault) - core dumped > Segmentation fault > Makefile:16: *** Not found Erlang. Stop. > make[2]: *** [Makefile:509: modules] Error 1 > make[2]: Leaving directory '/build/kamailio-6.1.0~dev1+bpo12.20250509084438.1/src' > make[1]: *** [Makefile:34: every-module] Error 2 > make[1]: Leaving directory '/build/kamailio-6.1.0~dev1+bpo12.20250509084438.1' > make: *** [debian/rules:134: build_erlang] Error 2 > make: *** Waiting for unfinished jobs.... > ``` > > - **bionic**: https://kamailio.sipwise.com/view/kamailiodev/job/kamailiodev-nightly-binar… > ``` > gcc -shared -g -pthread -Wl,-O2 -Wl,-E -Wl,-Bsymbolic-functions -Wl,-z,relro -rdynamic "-ldl" -Wl,-Bsymbolic-functions tls_domain.o tls_init.o tls_verify.o tls_locking.o tls_select.o tls_dump_vf.o tls_bio.o tlsa_mod.o tls_server.o tls_rpc.o tls_ct_wrq.o tls_rand.o tls_util.o tls_cfg.o tls_config.o -lm /usr/lib/aarch64-linux-gnu/libssl.a /usr/lib/aarch64-linux-gnu/libcrypto.a -o tlsa.so > /usr/bin/ld: /usr/lib/aarch64-linux-gnu/libcrypto.a(sha1-armv8.o): relocation R_AARCH64_PREL64 against symbol `OPENSSL_armcap_P' which may bind externally can not be used when making a shared object; recompile with -fPIC > /usr/lib/aarch64-linux-gnu/libcrypto.a(sha1-armv8.o): In function `sha1_block_armv8': > (.text+0x1240): dangerous relocation: unsupported relocation > /usr/bin/ld: /usr/lib/aarch64-linux-gnu/libcrypto.a(chacha-armv8.o): relocation R_AARCH64_PREL64 against symbol `OPENSSL_armcap_P' which may bind externally can not be used when making a shared object; recompile with -fPIC > /usr/lib/aarch64-linux-gnu/libcrypto.a(chacha-armv8.o):(.text+0x20): dangerous relocation: unsupported relocation > /usr/bin/ld: /usr/lib/aarch64-linux-gnu/libcrypto.a(poly1305-armv8.o): relocation R_AARCH64_PREL64 against symbol `OPENSSL_armcap_P' which may bind externally can not be used when making a shared object; recompile with -fPIC > /usr/lib/aarch64-linux-gnu/libcrypto.a(poly1305-armv8.o): In function `poly1305_emit_neon': > (.text+0x9a0): dangerous relocation: unsupported relocation > /usr/bin/ld: /usr/lib/aarch64-linux-gnu/libcrypto.a(sha256-armv8.o): relocation R_AARCH64_PREL64 against symbol `OPENSSL_armcap_P' which may bind externally can not be used when making a shared object; recompile with -fPIC > /usr/lib/aarch64-linux-gnu/libcrypto.a(sha256-armv8.o): In function `sha256_block_data_order': > (.text+0xf88): dangerous relocation: unsupported relocation > /usr/bin/ld: /usr/lib/aarch64-linux-gnu/libcrypto.a(sha512-armv8.o): relocation R_AARCH64_PREL64 against symbol `OPENSSL_armcap_P' which may bind externally can not be used when making a shared object; recompile with -fPIC > /usr/lib/aarch64-linux-gnu/libcrypto.a(sha512-armv8.o): In function `sha512_block_data_order': > (.text+0x10c8): dangerous relocation: unsupported relocation > collect2: error: ld returned 1 exit status > ../../Makefile.rules:191: recipe for target 'tlsa.so' failed > make[3]: *** [tlsa.so] Error 1 > ``` > > - **focal**: https://kamailio.sipwise.com/view/kamailiodev/job/kamailiodev-nightly-binar… > ``` > gcc -shared -g -pthread -Wl,-O2 -Wl,-E -Wl,-Bsymbolic-functions -Wl,-z,relro -rdynamic "-ldl" -Wl,-Bsymbolic-functions tls_domain.o tls_init.o tls_verify.o tls_locking.o tls_select.o tls_dump_vf.o tls_bio.o tlsa_mod.o tls_server.o tls_rpc.o tls_ct_wrq.o tls_rand.o tls_util.o tls_cfg.o tls_config.o -lm /usr/lib/aarch64-linux-gnu/libssl.a /usr/lib/aarch64-linux-gnu/libcrypto.a -o tlsa.so > /usr/bin/ld: /usr/lib/aarch64-linux-gnu/libcrypto.a(sha1-armv8.o): relocation R_AARCH64_PREL64 against symbol `OPENSSL_armcap_P' which may bind externally can not be used when making a shared object; recompile with -fPIC > /usr/lib/aarch64-linux-gnu/libcrypto.a(sha1-armv8.o): in function `sha1_block_armv8': > (.text+0x1240): dangerous relocation: unsupported relocation > /usr/bin/ld: /usr/lib/aarch64-linux-gnu/libcrypto.a(chacha-armv8.o): relocation R_AARCH64_PREL64 against symbol `OPENSSL_armcap_P' which may bind externally can not be used when making a shared object; recompile with -fPIC > /usr/lib/aarch64-linux-gnu/libcrypto.a(chacha-armv8.o):(.text+0x20): dangerous relocation: unsupported relocation > /usr/bin/ld: /usr/lib/aarch64-linux-gnu/libcrypto.a(poly1305-armv8.o): relocation R_AARCH64_PREL64 against symbol `OPENSSL_armcap_P' which may bind externally can not be used when making a shared object; recompile with -fPIC > /usr/lib/aarch64-linux-gnu/libcrypto.a(poly1305-armv8.o): in function `poly1305_emit_neon': > (.text+0x9a0): dangerous relocation: unsupported relocation > /usr/bin/ld: /usr/lib/aarch64-linux-gnu/libcrypto.a(sha256-armv8.o): relocation R_AARCH64_PREL64 against symbol `OPENSSL_armcap_P' which may bind externally can not be used when making a shared object; recompile with -fPIC > /usr/lib/aarch64-linux-gnu/libcrypto.a(sha256-armv8.o): in function `sha256_block_data_order': > (.text+0xf88): dangerous relocation: unsupported relocation > /usr/bin/ld: /usr/lib/aarch64-linux-gnu/libcrypto.a(sha512-armv8.o): relocation R_AARCH64_PREL64 against symbol `OPENSSL_armcap_P' which may bind externally can not be used when making a shared object; recompile with -fPIC > /usr/lib/aarch64-linux-gnu/libcrypto.a(sha512-armv8.o): in function `sha512_block_data_order': > (.text+0x1108): dangerous relocation: unsupported relocation > collect2: error: ld returned 1 exit status > ``` > _Originally posted by @linuxmaniac in [#13](https://github.com/sipwise/kamailio-deb-jenkins/issues/13#issuecomment-2866741862)_ -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4235 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4235(a)github.com>

4 12

[kamailio/kamailio] For network initiated ue de-registration, ims_registrar_scscf is populating Subscription-State header of NOTIFY message as active;expires=3581 instead of terminated;reason=deactivated (Issue #4296)
by Rik Biswas 12 Jan '26

12 Jan '26

therikb31 created an issue (kamailio/kamailio#4296) For network-initiated UE de-registration, `ims_registrar_scscf` is populating the `Subscription-State` header of the `NOTIFY` message as `active;expires=3581` instead of `terminated`. ### Description We are simulating a network-initiated UE de-registration by sending a **Registration-Termination Request** from the HSS to the S-CSCF for a registered IMSI. **Call Flow**: 1. UE registers to the IMS core 2. S-CSCF performs third-party registration with the Application Server on behalf of the UE 3. Application Server subscribes to `Event: reg` for the registered IMSI 4. HSS sends a Registration-Termination Request for network-initiated UE de-registration 5. S-CSCF sends a `NOTIFY` to subscribers for the `IMS_REGISTRAR_CONTACT_DEREGISTERED` event (issue with the `NOTIFY` SIP message) **Observation**: 1. `NOTIFY` messages are initiated to subscribers of `Event: reg`, but instead of having the `Subscription-State` header set to **terminated**, we observe the value **active;expires=3581**. (Image for the `NOTIFY` SIP message packet is attached below) ![Image](https://github.com/user-attachments/assets/08abc9a8-43b9-486c-9de5-370e465ea527) ### Troubleshooting #### Reproduction To reproduce this, we are performing the following steps: 1. Performing SIP registration of the UE with the target S-CSCF node 2. Sending `SUBSCRIBE` requests from a third-party Application Server and the UE with `Event: reg` to get notified of registration events 3. HSS sends a `Registration-Termination Request` to the target S-CSCF for the registered IMSI (network-initiated de-registration) #### Debugging Data #### Log Messages While going through the logs, we find that this header is being populated based on the expiry timer and a comparison with the current timestamp: ``` 2025-06-20 12:45:20 | 19(56) DEBUG: ims_registrar_scscf [registrar_notify.c:1716]: create_notifications(): Expires is greater than current time! Subscription state: [active;expires=3581] ``` #### SIP Traffic ### Possible Solutions **Workaround**: In the `create_notifications()` method of `src/modules/ims_registrar_scscf/registrar_notify.c`, when populating the `Subscription-State` header, if the `event_type` is `10` (`IMS_REGISTRAR_CONTACT_DEREGISTERED`), we can populate `Subscription-State` as `terminated`. ### Additional Information --- -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4296 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4296(a)github.com>

2 2

[kamailio/kamailio] cmake: build on ppc64le arch (Issue #4333)
by sergey-safarov 09 Jan '26

09 Jan '26

sergey-safarov created an issue (kamailio/kamailio#4333) ### Description I want to compile Kamailio sources on `ppc64le` arch. During compilation, I see an error ```sh [ 0%] Building C object src/CMakeFiles/kamailio.dir/main.c.o In file included from /tmp/kamailio/src/core/parser/../mem/../lock_ops.h:92, from /tmp/kamailio/src/core/parser/../mem/shm.h:44, from /tmp/kamailio/src/core/parser/../mem/shm_mem.h:32, from /tmp/kamailio/src/core/parser/../ut.h:46, from /tmp/kamailio/src/core/parser/../ip_addr.h:41, from /tmp/kamailio/src/core/parser/msg_parser.h:39, from /tmp/kamailio/src/core/select.h:36, from /tmp/kamailio/src/core/route_struct.h:35, from /tmp/kamailio/src/core/route.h:39, from /tmp/kamailio/src/main.c:79: /tmp/kamailio/src/core/parser/../mem/../fastlock.h:130:2: error: #error "unknown architecture" 130 | #error "unknown architecture" | ^~~~~ /tmp/kamailio/src/core/parser/../mem/../fastlock.h: In function ‘tsl’: /tmp/kamailio/src/core/parser/../mem/../fastlock.h:294:2: error: #error "unknown architecture" 294 | #error "unknown architecture" | ^~~~~ /tmp/kamailio/src/core/parser/../mem/../fastlock.h: In function ‘get_lock’: /tmp/kamailio/src/core/parser/../mem/../fastlock.h:317:9: error: implicit declaration of function ‘membar_getlock’ [-Wimplicit-function-declaration] 317 | membar_getlock(); | ^~~~~~~~~~~~~~ /tmp/kamailio/src/core/parser/../mem/../fastlock.h: In function ‘release_lock’: /tmp/kamailio/src/core/parser/../mem/../fastlock.h:436:2: error: #error "unknown architecture" 436 | #error "unknown architecture" | ^~~~~ In file included from /tmp/kamailio/src/core/atomic_ops.h:180, from /tmp/kamailio/src/core/locking.h:74, from /tmp/kamailio/src/core/rpc.h:36, from /tmp/kamailio/src/core/sr_module.h:38, from /tmp/kamailio/src/main.c:85: /tmp/kamailio/src/core/atomic/atomic_unknown.h: At top level: /tmp/kamailio/src/core/atomic/atomic_unknown.h:53:2: warning: #warning no native memory barrier implementations, falling back to slow lock based workaround [-Wcpp] 53 | #warning no native memory barrier implementations, falling back to slow lock \ | ^~~~~~~ gmake[2]: *** [src/CMakeFiles/kamailio.dir/build.make:76: src/CMakeFiles/kamailio.dir/main.c.o] Error 1 gmake[1]: *** [CMakeFiles/Makefile2:3359: src/CMakeFiles/kamailio.dir/all] Error 2 gmake: *** [Makefile:156: all] Error 2 ``` ### Expected behavior Sources compiled without error messages. #### Actual observed behavior Build failed be error described above. ### Reproduction ```sh git clone https://github.com/kamailio/kamailio.git docker run -it \ --platform linux/ppc64le \ -v ./kamailio:/usr/src/kamailio \ ghcr.io/sergey-safarov/kamailio-builder:centos-10 cd /usr/src/kamailio cmake -S . -B build cmake --build build ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4333 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4333(a)github.com>

6 46

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev September 2025