sr-dev June 2025

sr-dev@lists.kamailio.org

23 participants
265 discussions

[kamailio/kamailio] uac: Fix restore for replies on upstream in-dialog requests (PR #4303)
by Bastian Triller 08 Jul '25

08 Jul '25

#### 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 #### Description  Add in-dialog request's direction to TM callback parameter, so correct URIs are restored for replies on upstream in-dialog requests. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/4303 -- Commit Summary -- * uac: Fix restore for replies on upstream in-dialog requests -- File Changes -- M src/modules/uac/replace.c (82) M src/modules/uac/uac.c (3) M src/modules/uac/uac_reg.c (1) -- Patch Links -- https://github.com/kamailio/kamailio/pull/4303.patch https://github.com/kamailio/kamailio/pull/4303.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4303 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/4303(a)github.com>

2 5

Ideas for developer meeting 2: Rearchitect TLS
by Richard Chan 08 Jul '25

08 Jul '25

(Apologies for the long wall of text) Ideas for developer meeting 2: Rearchitect TLS Background: Kamailio uses OpenSSL in fork() for load balancing (TLS followed by SIP).The TLS state must be in shared memory so that each worker can pick up where the previous worker has left off. Over the years this has caused much friction - only OpenSSL 3 and wolfSSL can be used in this manner because they include hooks for memory management Problems with current architecture Original OpenSSL 3+ has gone heavily down the way of using pthreads, especially thread-local variables. OpenSSL lookalikes - boringSSL, libreSSL, AWS-LC - don't support memory management to redirect functions to shared memory pools A pure GPL library like GnuTLS also not enable memory management hooks Today Kamailio is "fighting" its primary TLS provider, namely OpenSSL 3. We require pthread symbol overrides (which is a code smell) and have to do thread local tricks for the workers to have a clean state. With OpenSSL 3 - Kamailio users have an unhappy relationship with memory management. Structures are duplicated per worker(SSL_CTX) to avoid unexpected failures when an SSL object derived from worker A is used in worker B. Using a single SSL_CTX in the main process - in an attempt to conserve memory - has not been solved yet (my assessment is that this problem can be solved within the current architecture). History It seems that Kamailio code base has vestiges of when TLS was handled in core (possibly the TCP manager process?). Proposal 2 This proposal has the spirit that we should not be fighting the libraries we use especially if this library is a key component of many distributions/containers with many eyes on the way we use and abuse OpenSSL. The Zen of OpenSSL(I just made that up) would suggest we embrace their path forward and have Kamailio work within that boundary. The GPL of Kamailio would also suggest that we should validate this approach with the ability to use something like GnuTLS. This proposal is to perform TLS in a thread-pool in the TCP manager so that all TLS related operations are confined to a single process. When the TCP manager terminates or initiates TLS it should perform TLS in a hairpin socketpair(managed by a thread pool). The socket fd used in sendmsg/recvmsg with the worker is this internal proxy'ied socket but carries metadata about the original connection. In other words: Kamailio TCP manager internally implements a TLS/TCP bridge like Nginx/HAProxy do with HTTPS/HTTP or TLS/TCP. These proxies send headers so the worker is informed about the nature of the original connection. Benefits - use OpenSSL/AWS-LC/boringSSL/libreSSL in the way they are intended to be used; even GnuTLS - no pthreads hackery - a well-defined boundary for TLS operations, certificate and key management: allowing for easier scrutiny and audit The offloading of both TLS/SIP dates from the days when threading was poor on Linux. Today that is no longer the case, so the TLS Manager could handle all TLS and the worker should handle SIP/TCP. In fact this proposal was inspired by the recent work on UDP enhancement. Optional riff: we may be able to off-load TLS entirely to HAProxy(or any other TLS/TLS bridge). Instead of handling TLS ourselves Kamailio creates a new type of listener/speaker haproxy-in, haproxy-out. Kamailio "knows" that these sockets are not SIP traffic but internal hairpins to decrypt/encrypt the streams via HAProxy et al. Think of Kamailio as using HAProxy as a filter object: the sendmsg/recvmsg will use the haproxy-in socket (which is what the worker will see - TCP only). See the sidenode below. t_relay would have to taught that it doesn't need to look for "real" TLS sockets but instead a proxy socket should suffice. Sidenote: Today TLS can be solved with external TLS/TCP bridges. The main issue with this approach is the config file occasionally needs to force TCP otherwise Kamailio will look for a non-existent TLS socket - so it is not an entirely happy experience for users. Richard (Shih-Ping)

2 4

Dispatcher coherence: marking destinations and running event routes
by Daniel-Constantin Mierla 08 Jul '25

08 Jul '25

Hello, there is (still) some incoherence in dispatcher module regarding the marking of a destination (e.g., to inactive state) and execution of event route. First, which I tried to address earlier today, was that ds_mark_dst() was taking in consideration the value of ds_probing_threshold, which was intended for keepalives, so the use of the function was not having any effect (as documented) till it was used so many times as the parameter value, probably not noticed so far because the default value for the parameter is 1. Similar would be for setting destination active and the value of ds_inactive_threshold. Going on the same execution path as with setting the state of a destination based on keepalives, the use of ds_mark_dst() results in running the event routes, which I am not sure it is really expected. But then, setting the state of a destination via RPC is not running event routes and it was done immediately via reinitialising the state, without any relation to ds_probing_threshold or ds_inactive_threshold. So the questions would be: 1) the documented way is the expected one on admin-instructed state update (via config functions or rpc), respectively do it immediately, without considering ds_probing_threshold or ds_inactive_threshold? It is like now in git master branch, but for many years the config functions took in consideration the parameters. 2) shall event routes be executed only on SIP keepalives, or also on admin-instructed state update (via config functions or rpc)? Or leave it only for keepalives and config functions, like it is now, with updating documentation to be clear. Cheers, Daniel -- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy, Training and Development Services -- asipto.com

2 1

Ideas for developer meeting 2b: Teach TCP sockets that they are TLS proxies
by Richard Chan 08 Jul '25

08 Jul '25

Ideas for developer meeting 2b: Teach TCP sockets that they are TLS proxies Background: This is a follow-on for Proposal 2 - it is for each of use TLS offloading to external proxies. When using external TLS/TCP bridges users encounter a mismatch when the URI/socket matcher cannnot find a matching TLS socket. Users can work around this by forcing t_relay_to but it is not a natural map. Some dancing with record-route headers is usually necessary Proposal 2b This proposal is to have a marker in config file on TCP listeners that they are in fact proxy'd TLS connections. So the look-and-feel should be TLS except that they skip mod_tls processing. When the config searches for matching socket this type of TLS-proxy will be found. Benefits: - can sidestep more exotic mod_tls problems with OpenSSL; user just offloads to HAProxy et al - seamless config: these proxy'ied sockets have enough metadata that look like TLS socket for URIs, record-route etc handling Richard (Shih-Ping)

3 2

[kamailio/kamailio] core: Add null and empty check for AVP name (PR #4302)
by Tomohare 08 Jul '25

08 Jul '25

#### 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:  - [ ] PR should be backported to stable branches - [x] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description  Ensure that the pointer 'name' is not null and its size not negative. - Returns 0 in case of invalid name values: null or empty or name length have a negative value. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/4302 -- Commit Summary -- * core: Add null and empty check for AVP name -- File Changes -- M src/core/usr_avp.c (4) -- Patch Links -- https://github.com/kamailio/kamailio/pull/4302.patch https://github.com/kamailio/kamailio/pull/4302.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4302 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/4302(a)github.com>

3 16

Kamailio rpm server
by Patrick Wakano 08 Jul '25

08 Jul '25

Hello list, Hope everyone is fine. I'm trying to install the latest 6.0.1 version from https://rpm.kamailio.org/centos/ but it doesn't seem to be updated...The latest version available there is the 5.8.5. Version 6.0.0 isn't there as well... Is it still maintained? or just some rpmbuild command missed? Thank you, Patrick

3 9

[tracker] Assignee added: Assignment operators don't work
by sip-router 06 Jul '25

06 Jul '25

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.

3 2

[kamailio/kamailio] http_client leaks TLS shared memory (Issue #4231)
by Alexander Bakker 04 Jul '25

04 Jul '25

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>

4 13

[kamailio/kamailio] Duplicated presentities (and notifies) when usrloc and presence are replicated via dmq and pua_reginfo used (Issue #4252)
by Matteo 04 Jul '25

04 Jul '25

xadhoom created an issue (kamailio/kamailio#4252) ### Description A kamailio cluster which replicates presentities and usrloc via dmq may incur into duplicated presentities and notifications depending on config. The problematic setup, where each kamailio node has the following setup: - presence enabled with dmq - usrloc distributed with dmq - pua_reginfo used to publish reginfo to self Really is multiplicated by the numbers of nodes, so 4 nodes -> 4 times notifications and presentities. ### Troubleshooting The problem arise because pua_reginfo hooks to usrloc and every time a "save()" is done a publish is sent, which is by design. Then the handled publish generates a presentity which is replicated via dmq from presence module. Now, if also usrloc is replicated via DMQ, the handling of such message still trigger the hook, causing another publish with generates a different presentiy, since is new and the e-tag is different. This causes subscribers to receive <number of nodes> notifications on every status change. ### Possible Solutions The approach can be to optionally disable that hook (basically making pua_reginfo skipping publish) when handling a message via DMQ, so the usrloc replica is just saved. In other modules, like pua_dialoginfo or pua_usrloc this can be already done, since publishing can be controlled from script. ### Additional Information * **Kamailio Version** ``` 6.0.1 ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4252 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4252(a)github.com>

3 4

[kamailio/kamailio] arm64 support issues (Issue #4235)
by Victor Seva 04 Jul '25

04 Jul '25

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>

3 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev June 2025