<!--
Kamailio Project uses GitHub Issues only for bugs in the code or feature requests. Please use this template only for bug reports.
If you have questions about using Kamailio or related to its configuration file, ask on sr-users mailing list:
* https://lists.kamailio.org/mailman3/postorius/lists/sr-users.lists.kamailio…
If you have questions about developing extensions to Kamailio or its existing C code, ask on sr-dev mailing list:
* https://lists.kamailio.org/mailman3/postorius/lists/sr-dev.lists.kamailio.o…
Please try to fill this template as much as possible for any issue. It helps the developers to troubleshoot the issue.
Note that an issue report may be closed automatically after about 2 months
if there is no interest from developers or community users on pursuing it, being
considered expired. In such case, it can be reopened by writing a comment that includes
the token `/notexpired`. About two weeks before considered expired, the issue is
marked with the label `stale`, trying to notify the submitter and everyone else
that might be interested in it. To remove the label `stale`, write a comment that
includes the token `/notstale`. Also, any comment postpone the `expire` timeline,
being considered that there is interest in pursuing the issue.
If there is no content to be filled in a section, the entire section can be removed.
You can delete the comments from the template sections when filling.
You can delete next line and everything above before submitting (it is a comment).
-->
### 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
<!--
If you got a core dump, use gdb to extract troubleshooting data - full backtrace,
local variables and the list of the code at the issue location.
gdb /path/to/kamailio /path/to/corefile
bt full
info locals
list
If you are familiar with gdb, feel free to attach more of what you consider to
be relevant.
-->
```
(paste your debugging data here)
```
#### Log Messages
<!--
Check the syslog file and if there are relevant log messages printed by Kamailio, add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site).
-->
```
(paste your log messages here)
```
#### SIP Traffic
<!--
If the issue is exposed by processing specific SIP messages, grab them with ngrep or save in a pcap file, then add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site).
-->
```
(paste your sip traffic here)
```
### Possible Solutions
<!--
If you found a solution or workaround for the issue, describe it. Ideally, provide a pull request with a fix.
-->
### 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**:
<!--
Details about the operating system, the type: Linux (e.g.,: Debian 8.4, Ubuntu 16.04, CentOS 7.1, ...), MacOS, xBSD, Solaris, ...;
Kernel details (output of `lsb_release -a` and `uname -a`)
-->
```
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>
Module: kamailio
Branch: master
Commit: 2e20c74fb03f2442cde5f3f69989a0ed914f542c
URL: https://github.com/kamailio/kamailio/commit/2e20c74fb03f2442cde5f3f69989a0e…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Committer: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2025-05-06T14:38:02+02:00
app_jsdt: doc - fix section tags for loaddir
---
Modified: src/modules/app_jsdt/doc/app_jsdt_admin.xml
---
Diff: https://github.com/kamailio/kamailio/commit/2e20c74fb03f2442cde5f3f69989a0e…
Patch: https://github.com/kamailio/kamailio/commit/2e20c74fb03f2442cde5f3f69989a0e…
---
diff --git a/src/modules/app_jsdt/doc/app_jsdt_admin.xml b/src/modules/app_jsdt/doc/app_jsdt_admin.xml
index 6d139c29428..bbf2148b9b4 100644
--- a/src/modules/app_jsdt/doc/app_jsdt_admin.xml
+++ b/src/modules/app_jsdt/doc/app_jsdt_admin.xml
@@ -107,35 +107,31 @@ modparam("app_jsdt", "load", "/usr/local/etc/kamailio/js/myscript.js")
</programlisting>
</example>
</section>
- <section>
- <title>Parameters</title>
- <section id="app_jsdt.p.loaddir">
- <title>
- <varname>loaddir</varname> (str)
- </title>
- <para>
- Set the path to the folder containing JavaScript files to be loaded at startup. All
- .js files in the folder will be loaded and combined into a single javascript script.
- Then you can use jsdt_run(function, params) to execute a function from the
- script at runtime. If you use it for KEMI configuration,
- then it has to include the required functions.
- </para>
- <para>
- <emphasis>
- Default value is <quote>null</quote>.
- </emphasis>
- </para>
- <example>
- <title>
- Set <varname>loaddir</varname> parameter
- </title>
- <programlisting format="linespecific">
- ...
- modparam("app_jsdt", "loaddir", "/usr/local/etc/kamailio/js")
- ...
- </programlisting>
- </example>
- </section>
+ <section id="app_jsdt.p.loaddir">
+ <title><varname>loaddir</varname> (str)</title>
+ <para>
+ Set the path to the folder containing JavaScript files to be loaded at startup. All
+ .js files in the folder will be loaded and combined into a single javascript script.
+ Then you can use jsdt_run(function, params) to execute a function from the
+ script at runtime. If you use it for KEMI configuration,
+ then it has to include the required functions.
+ </para>
+ <para>
+ <emphasis>
+ Default value is <quote>null</quote>.
+ </emphasis>
+ </para>
+ <example>
+ <title>
+ Set <varname>loaddir</varname> parameter
+ </title>
+ <programlisting format="linespecific">
+...
+modparam("app_jsdt", "loaddir", "/usr/local/etc/kamailio/js")
+...
+</programlisting>
+ </example>
+ </section>
<section id="app_jsdt.p.mode">
<title><varname>mode</varname> (int)</title>
<para>
@@ -328,4 +324,3 @@ request_route {
</programlisting>
</section>
</chapter>
-
<!-- Kamailio Pull Request Template -->
<!--
IMPORTANT:
- for detailed contributing guidelines, read:
https://github.com/kamailio/kamailio/blob/master/.github/CONTRIBUTING.md
- pull requests must be done to master branch, unless they are backports
of fixes from master branch to a stable branch
- backports to stable branches must be done with 'git cherry-pick -x ...'
- code is contributed under BSD for core and main components (tm, sl, auth, tls)
- code is contributed GPLv2 or a compatible license for the other components
- GPL code is contributed with OpenSSL licensing exception
-->
#### Pre-Submission Checklist
<!-- Go over all points below, and after creating the PR, tick all the checkboxes that apply -->
<!-- All points should be verified, otherwise, read the CONTRIBUTING guidelines from above-->
<!-- If you're unsure about any of these, don't hesitate to ask on sr-dev mailing list -->
- [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:
<!-- Go over all points below, and after creating the PR, tick the checkboxes that apply -->
- [ ] PR should be backported to stable branches
- [x] Tested changes locally
- [ ] Related to issue #XXXX (replace XXXX with an open issue number)
#### Description
We've been running the ims_charging module in production for quite some time, without any issues.
A couple of days ago the whole instance freezed, but I was able to get a dump before the stuck processes before restarting. The traffic volume has gradually increased over time, so it's likely related to that.
I then did a summary of the different types of stuck processes. Which locks they're holding, and what they're waiting for:
```
holding lock:
AAASessionsLock
waiting for lock:
lock_get(peer_list_lock);
#1 0x00007fe70eba8cde in futex_get (lock=0x7fe6e4a5c680) at ../../core/futexlock.h:108
#2 0x00007fe70ebaaca2 in get_peer_by_fqdn (fqdn=0x7fe6e4a5ba30) at peermanager.c:259
#3 0x00007fe70ebb64b7 in get_first_connected_route (cdp_session=0x7fe6e5cc5350, r=0x7fe6e4a5ba30, app_id=4, vendor_id=10415) at routing.c:115
#4 0x00007fe70ebb9a37 in get_routing_peer (cdp_session=0x7fe6e5cc5350, m=0x7fe6e5447ab0) at routing.c:293
#5 0x00007fe70ebcaf8c in AAASendMessage (message=0x7fe6e5447ab0, callback_f=0x7fe707a9e323 <resume_on_initial_ccr>, callback_param=0x7fe6e5297110) at diameter_comm.c:139
#6 0x00007fe707a9d3e0 in Ro_Send_CCR (msg=0x7fe70f011100, dlg=0x7fe6e5c571f0, dir=0, reservation_units=30, incoming_trunk_id=0x7ffe50efb060, outgoing_trunk_id=0x7ffe50efb050, pani=0x7ffe50efaee0, action=0x7fe70efa4730, tindex=10484, tlabel=677172593) at ims_ro.c:1511
#7 0x00007fe707a8285d in ki_ro_ccr (msg=0x7fe70f011100, s_route_name=0x7ffe50efb080, s_direction=0x7ffe50efb070, reservation_units=30, s_incoming_trunk_id=0x7ffe50efb060, s_outgoing_trunk_id=0x7ffe50efb050) at ims_charging_mod.c:742
#8 0x00007fe707a7bf01 in w_ro_ccr (msg=0x7fe70f011100, c_route_name=0x7fe70ef8b8d0 "\220\311\371\016\347\177", c_direction=0x7fe70ef8b980 "p\240\371\016\347\177", reservation_units=30, c_incoming_trunk_id=0x7fe70ef8ba30 "p\241\371\016\347\177", c_outgoing_trunk_id=0x7fe70ef8bae0 "\360\241\371\016\347\177") at ims_charging_mod.c:507
#9 0x00000000004858d8 in do_action (h=0x7ffe50efb970, a=0x7fe70ef99e20, msg=0x7fe70f011100) at core/action.c:1144
#10 0x00000000004928d6 in run_actions (h=0x7ffe50efb970, a=0x7fe70ef99e20, msg=0x7fe70f011100) at core/action.c:1618
#11 0x0000000000492f52 in run_actions_safe (h=0x7ffe50eff1e0, a=0x7fe70ef99e20, msg=0x7fe70f011100) at core/action.c:1681
#12 0x0000000000450156 in rval_get_long (h=0x7ffe50eff1e0, msg=0x7fe70f011100, i=0x7ffe50efbec8, rv=0x7fe70ef9c1d8, cache=0x0) at core/rvalue.c:973
#13 0x0000000000454d24 in rval_expr_eval_long (h=0x7ffe50eff1e0, msg=0x7fe70f011100, res=0x7ffe50efbec8, rve=0x7fe70ef9c1d0) at core/rvalue.c:1854
#14 0x0000000000454d52 in rval_expr_eval_long (h=0x7ffe50eff1e0, msg=0x7fe70f011100, res=0x7ffe50efc448, rve=0x7fe70ef9b920) at core/rvalue.c:1864
#15 0x00000000004850ce in do_action (h=0x7ffe50eff1e0, a=0x7fe70ef9b070, msg=0x7fe70f011100) at core/action.c:1097
--
holding lock:
AAASessionsLock
waiting for lock:
lock_get(peer_list_lock);
#1 0x00007fe70eba8d4f in futex_get (lock=0x7fe6e4a5c680) at ../../core/futexlock.h:121
#2 0x00007fe70ebaaca2 in get_peer_by_fqdn (fqdn=0x7ffe50efab90) at peermanager.c:259
#3 0x00007fe70ebb8e89 in get_routing_peer (cdp_session=0x7fe6e5ab6910, m=0x7fe6e5435be0) at routing.c:252
#4 0x00007fe70ebcaf8c in AAASendMessage (message=0x7fe6e5435be0, callback_f=0x7fe707a95edc <resume_on_termination_ccr>, callback_param=0x0) at diameter_comm.c:139
#5 0x00007fe707a95b02 in send_ccr_stop_with_param (ro_session=0x7fe6e5ab65e0, code=0, reason=0x7ffe50efb060) at ims_ro.c:1181
#6 0x00007fe707a72ff7 in dlg_terminated (dlg=0x7fe6e623d7a0, type=64, termcode=0, reason=0x7fe707ab72b3 "normal call clearing", _params=0x7fe707f67280 <params>) at dialog.c:249
#7 0x00007fe707a6a729 in dlg_callback_received (dlg=0x7fe6e623d7a0, type=64, _params=0x7fe707f67280 <params>) at dialog.c:25
#8 0x00007fe707d341b9 in run_dlg_callbacks (type=64, dlg=0x7fe6e623d7a0, req=0x7fe70f011100, rpl=0x0, dir=1, dlg_data=0x0) at dlg_cb.c:271
#9 0x00007fe707cf4db4 in dlg_terminated (req=0x7fe70f011100, dlg=0x7fe6e623d7a0, dir=1) at dlg_handlers.c:413
#10 0x00007fe707cfddeb in dlg_onroute (req=0x7fe70f011100, route_params=0x7ffe50efb6d0, param=0x0) at dlg_handlers.c:1097
#11 0x00007fe70ad285f6 in run_rr_callbacks (req=0x7fe70f011100, rr_param=0x7ffe50efb7c0) at rr_cb.c:96
#12 0x00007fe70ad3ae92 in after_loose (_m=0x7fe70f011100, preloaded=0) at loose.c:1021
#13 0x00007fe70ad3b5ce in loose_route_mode (_m=0x7fe70f011100, _mode=0) at loose.c:1056
#14 0x00007fe70ad3f74f in w_loose_route (msg=0x7fe70f011100, p1=0x0, p2=0x0) at rr_mod.c:273
#15 0x00000000004855ff in do_action (h=0x7ffe50efc390, a=0x7fe70efe0d40, msg=0x7fe70f011100) at core/action.c:1121
--
holding lock:
lock_get(peer_list_lock);
waiting for lock:
lock_get(p->lock);
#1 0x00007fe70eba8d4f in futex_get (lock=0x7fe6e4a5cbd0) at ../../core/futexlock.h:121
#2 0x00007fe70ebab0ae in peer_timer (now=1742807320, ptr=0x0) at peermanager.c:286
#3 0x00007fe70ebd0f39 in timer_loop () at timer.c:116
#4 0x00007fe70ebd21b2 in timer_process (returns=0) at timer.c:216
#5 0x00007fe70eb8ccf8 in diameter_peer_start (blocking=0) at diameter_peer.c:350
#6 0x00007fe70eb7cbb2 in cdp_child_init (rank=0) at cdp_mod.c:272
--
holding lock:
lock_get(p->lock)
waiting for lock:
AAASessionsLock
#1 0x00007fe70ebf2597 in futex_get (lock=0x7fe6e4a5d490) at ../../core/futexlock.h:108
#2 0x00007fe70ebf26f1 in AAASessionsLock (hash=0) at session.c:79
#3 0x00007fe70ebf5e6e in cdp_get_session (id=...) at session.c:316
#4 0x00007fe70eba6892 in Snd_Message (p=0x7fe6e4a5c880, msg=0x7fe6e63998d0) at peerstatemachine.c:1237
#5 0x00007fe70eba003e in sm_process (p=0x7fe6e4a5c880, event=Send_Message, msg=0x7fe6e63998d0, peer_locked=0, sock=0) at peerstatemachine.c:429
#6 0x00007fe70ebcbdc6 in AAASendMessage (message=0x7fe6e63998d0, callback_f=0x7fe707a8f208 <resume_on_interim_ccr>, callback_param=0x7fe6e6190a90) at diameter_comm.c:166
#7 0x00007fe707a8edb3 in send_ccr_interim (ro_session=0x7fe6e5399160, used=60, reserve=30) at ims_ro.c:847
#8 0x00007fe707a68bd6 in ro_session_ontimeout (tl=0x7fe6e5399200) at ro_timer.c:513
#9 0x00007fe707a63078 in ro_timer_routine (ticks=114862426, attr=0x0) at ro_timer.c:279
#10 0x00000000004fd33e in compat_old_handler (ti=1837798827, tl=0x7fe6e4cf6260, data=0x7fe6e4cf6260) at core/timer.c:980
#11 0x00000000004fde7a in slow_timer_main () at core/timer.c:1103
#12 0x000000000042e4e7 in main_loop () at main.c:1911
#13 0x000000000043876c in main (argc=10, argv=0x7ffe50f001c8) at main.c:3236
```
In `get_first_connected_route()` in `routing.c` of the cdp module there are two places `get_peer_by_fqdn()` are called. One of them has an unlock/relock of the session list before and after (and a comment about holding two locks at a time), while the other doesn't.
I'm currently testing two version of this. The first by just doing the some relock for the other `get_peer_by_fqdn()`, but this PR got an approach for maybe fixing more latent issues. `sm_process()` also got some strange handling by `Rcv_Process()` after the peer lock is released, which seems to be about the same thing. My deadlock is for the `Snd_Message()` equivalent.
I've now removed this queueing behaviour, and instead doing a re-lock of the peer to (hopefully) have the same locking order as the other operations.
The problem with this thing is how rare it occurs. Just wanted to share my findings for others with more knowledge to the cdp module for comments, suggestions and hopefully some extra testing.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/4191
-- Commit Summary --
* cdp: restructure locking order to prevent rare deadlock
-- File Changes --
M src/modules/cdp/peerstatemachine.c (25)
M src/modules/cdp/routing.c (6)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/4191.patchhttps://github.com/kamailio/kamailio/pull/4191.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/4191
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/4191(a)github.com>
<!-- Kamailio Pull Request Template -->
<!--
IMPORTANT:
- for detailed contributing guidelines, read:
https://github.com/kamailio/kamailio/blob/master/.github/CONTRIBUTING.md
- pull requests must be done to master branch, unless they are backports
of fixes from master branch to a stable branch
- backports to stable branches must be done with 'git cherry-pick -x ...'
- code is contributed under BSD for core and main components (tm, sl, auth, tls)
- code is contributed GPLv2 or a compatible license for the other components
- GPL code is contributed with OpenSSL licensing exception
-->
#### Pre-Submission Checklist
<!-- Go over all points below, and after creating the PR, tick all the checkboxes that apply -->
<!-- All points should be verified, otherwise, read the CONTRIBUTING guidelines from above-->
<!-- If you're unsure about any of these, don't hesitate to ask on sr-dev mailing list -->
- [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:
<!-- Go over all points below, and after creating the PR, tick the checkboxes that apply -->
- [ ] PR should be backported to stable branches
- [x] Tested changes locally
- [ ] Related to issue #XXXX (replace XXXX with an open issue number)
#### Description
Currently `stirshaken` module performs x509 certificate path check twice (when enabled):
- first by calling `stir_shaken_verify_cert_path` directly from the [`stirshaken_mod.c`](https://github.com/kamailio/kamailio/blob/330543f46cbb6bf815ebf77c98378314091197ce/src/modules/stirshaken/stirshaken_mod.c#L626)
- second time from the [`libstirshaken`](https://github.com/signalwire/libstirshaken/blame/cb6ede40b3ce12ab76e370186a14dc141839ef07/src/stir_shaken_verify.c#L445)
`libstirshaken` had the path check built in since approx 2020 ([last commit mentioning it as TODO](https://github.com/signalwire/libstirshaken/blame/552650e31e3dc668069… before the `stir_shaken_verify_cert_path` function was introduced). This shouldn't be an issue since `stirshaken` module was added to Kamailio in 2021.
This PR removes the x509 certificate path check from the `stirshaken_mod.c` by passing the responsibility to perform certificate path check to the `libstirshaken`.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/4202
-- Commit Summary --
* stirshaken: removed repeated x509 certification path check
-- File Changes --
M src/modules/stirshaken/doc/stirshaken_admin.xml (4)
M src/modules/stirshaken/stirshaken_mod.c (17)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/4202.patchhttps://github.com/kamailio/kamailio/pull/4202.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/4202
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/4202(a)github.com>
Module: kamailio
Branch: master
Commit: f007736ba18f5cc2114ffdd1e6df2b9b03808fe7
URL: https://github.com/kamailio/kamailio/commit/f007736ba18f5cc2114ffdd1e6df2b9…
Author: FelipeCuadra <f.cuadra(a)zaleos.net>
Committer: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2025-05-06T13:34:41+02:00
stirshaken: removed repeated x509 certification path check
- removed a second check of the x509 certificate path from the module, since it is already done earlier in the library and updated documentation
---
Modified: src/modules/stirshaken/doc/stirshaken_admin.xml
Modified: src/modules/stirshaken/stirshaken_mod.c
---
Diff: https://github.com/kamailio/kamailio/commit/f007736ba18f5cc2114ffdd1e6df2b9…
Patch: https://github.com/kamailio/kamailio/commit/f007736ba18f5cc2114ffdd1e6df2b9…
---
diff --git a/src/modules/stirshaken/doc/stirshaken_admin.xml b/src/modules/stirshaken/doc/stirshaken_admin.xml
index ef07e6a7212..41f72e5c1b7 100644
--- a/src/modules/stirshaken/doc/stirshaken_admin.xml
+++ b/src/modules/stirshaken/doc/stirshaken_admin.xml
@@ -528,6 +528,10 @@ request_route {
...
</programlisting>
</example>
+ <para>
+ To ensure proper functionality, the Kamailio stirshaken module requires a minimum version of libstirshaken that includes the stir_shaken_verify_cert_path function for performing the x509 certificate path check. This functionality was added to libstirshaken around 2020 (<![CDATA[https://github.com/signalwire/libstirshaken/commit/58e740b897ae40e2bb02ada2231a051a7eb55137]]>).
+ If you're using an older version of libstirshaken that predates this commit, the stirshaken module may not function correctly.
+ </para>
</section>
</chapter>
diff --git a/src/modules/stirshaken/stirshaken_mod.c b/src/modules/stirshaken/stirshaken_mod.c
index 95bbdeb5736..5d0bc744885 100644
--- a/src/modules/stirshaken/stirshaken_mod.c
+++ b/src/modules/stirshaken/stirshaken_mod.c
@@ -613,23 +613,6 @@ static int ki_stirshaken_check_identity(sip_msg_t *msg)
goto fail;
}
- if(stirshaken_vs_verify_x509_cert_path) {
-
- LM_DBG("Running X509 certificate path verification\n");
-
- if(!vs) {
- LM_ERR("Verification Service not started\n");
- goto fail;
- }
-
- if(STIR_SHAKEN_STATUS_OK
- != stir_shaken_verify_cert_path(&ss, cert_out, vs->store)) {
- LM_ERR("Cert did not pass X509 path validation\n");
- stirshaken_print_error_details(&ss);
- goto fail;
- }
- }
-
if(stirshaken_vs_pptg_pvname.s != 0) {
memset(&val, 0, sizeof(pv_value_t));
val.flags = PV_VAL_STR;