sr-dev May 2024

sr-dev@lists.kamailio.org

15 participants
162 discussions

[kamailio/kamailio] User-params parsing fails in multiple ways (Issue #3762)

by Alex Hermann

### Description The uri parser seems to fail in multiple ways on username-parameters. The ways it fails depends on the presence of user-params in the incoming request and on adjustments to $ru, $rd and $rU in the script. My expectation is that the whole username, including user-params is *always* visible in $rU. In reality, the user-params are absent or present depending on manipulations to the uri in the script. When setting $rU to a value with a user-param, that user-param is represented when reading $ru, but not in $rU.  ### Troubleshooting #### Reproduction I used below config script to test various scenario's. ``` debug=2 memlog=4 #fork=no # This option should not be present to enable forking but disable daemonize, also -D commandline parameter is needed log_stderror=yes log_name="kamailio-test" log_facility=LOG_LOCAL5 sip_warning=no children=2 shm_mem_size=128 check_via=no # (cmd. line: -v) dns=no # (cmd. line: -r) rev_dns=no # (cmd. line: -R) dns_use_search_list=no use_dns_failover=yes dns_srv_lb=yes disable_tcp=yes auto_aliases=no listen=172.16.1.19:7060 loadmodule "sl.so" loadmodule "pv.so" loadmodule "xlog.so" modparam("xlog", "prefix", "") route { xnotice("Incoming $rm to $rU\n"); xinfo("$$ru = $ru\n"); switch ($rU) { case "100": xnotice("Set $$rU = \"1234;first=yes\"\n"); $rU = "1234;first=yes"; xinfo("$$ru: $ru\n"); xinfo("$$rU: $rU\n"); if ($rU != "1234;first=yes") { xerr("Fail!\n"); } else { xinfo("Success!\n"); } break; case "200": xnotice("Set $$rd = \"example.com;transport=udp\"\n"); $rd = "example.com;transport=udp"; xinfo("$$ru: $ru\n"); xinfo("$$rU: $rU\n"); xnotice("Set $$rU = \"1234;first=yes\"\n"); $rU = "1234;first=yes"; xinfo("$$ru: $ru\n"); xinfo("$$rU: $rU\n"); if ($rU != "1234;first=yes") { xerr("Fail!\n"); } else { xinfo("Success!\n"); } break; case "300": xnotice("Set $$ru = \"sip:1234@example.com;transport=udp\"\n"); $ru = "sip:1234@example.com;transport=udp"; xinfo("$$ru: $ru\n"); xinfo("$$rU: $rU\n"); xnotice("Set $$rU = \"1234;first=yes\"\n"); $rU = "1234;first=yes"; xinfo("$$ru: $ru\n"); xinfo("$$rU: $rU\n"); if ($rU != "1234;first=yes") { xerr("Fail!\n"); } else { xinfo("Success!\n"); } break; case "400": xnotice("Set $$ru = \"sip:1234;first=yes@example.com;transport=udp\"\n"); $ru = "sip:1234;first=yes@example.com;transport=udp"; xinfo("$$ru: $ru\n"); xinfo("$$rU: $rU\n"); if ($rU != "1234;first=yes") { xerr("Fail!\n"); } else { xinfo("Success!\n"); } xnotice("Set $$rU = \"1234;second=yes\"\n"); $rU = "1234;second=yes"; xinfo("$$ru: $ru\n"); xinfo("$$rU: $rU\n"); if ($rU != "1234;second=yes") { xerr("Fail!\n"); } else { xinfo("Success!\n"); } break; } sl_send_reply(500, "Done"); exit; } ``` Outputs: --- ``` 1(2206122) NOTICE: Incoming INVITE to 100 1(2206122) INFO: $ru = sip:100@172.16.1.19:7060;user=phone 1(2206122) NOTICE: Set $rU = "1234;first=yes" 1(2206122) INFO: $ru: sip:1234;first=yes@172.16.1.19:7060;user=phone 1(2206122) INFO: $rU: 1234 1(2206122) ERROR: Fail! ``` Setting $rU with a user-param sets it correctly in $ru, but reading $rU back fails. --- ``` 1(2206122) NOTICE: Incoming INVITE to 200 1(2206122) INFO: $ru = sip:200@172.16.1.19:7060;user=phone 1(2206122) NOTICE: Set $rd = "example.com;transport=udp" 1(2206122) INFO: $ru: sip:200@example.com;transport=udp:7060;user=phone 1(2206122) INFO: $rU: 200 1(2206122) NOTICE: Set $rU = "1234;first=yes" 1(2206122) INFO: $ru: sip:1234;first=yes@example.com;transport=udp:7060;user=phone 1(2206122) INFO: $rU: 1234 1(2206122) ERROR: Fail! ``` Same when setting $rd in advance. --- ``` 1(2206122) NOTICE: Incoming INVITE to 300 1(2206122) INFO: $ru = sip:300@172.16.1.19:7060;user=phone 1(2206122) NOTICE: Set $ru = "sip:1234@example.com;transport=udp" 1(2206122) INFO: $ru: sip:1234@example.com;transport=udp 1(2206122) INFO: $rU: 1234 1(2206122) NOTICE: Set $rU = "1234;first=yes" 1(2206122) INFO: $ru: sip:1234;first=yes@example.com;transport=udp 1(2206122) INFO: $rU: 1234;first=yes 1(2206122) INFO: Success! ``` When setting $ru first with no user-param lets a later asssignment to $rU with user-param succeed. --- ``` 1(2206122) NOTICE: Incoming INVITE to 400 1(2206122) INFO: $ru = sip:400@172.16.1.19:7060;user=phone 1(2206122) NOTICE: Set $ru = "sip:1234;first=yes@example.com;transport=udp" 1(2206122) INFO: $ru: sip:1234;first=yes@example.com;transport=udp 1(2206122) INFO: $rU: 1234;first=yes 1(2206122) INFO: Success! 1(2206122) NOTICE: Set $rU = "1234;second=yes" 1(2206122) INFO: $ru: sip:1234;second=yes@example.com;transport=udp 1(2206122) INFO: $rU: 1234;second=yes 1(2206122) INFO: Success! ``` Setting $ru with a user-params succeeds. Subsequently overwriting the user part with $rU with a user-param also succeeds. --- ``` 1(2206122) NOTICE: Incoming INVITE to 400 1(2206122) INFO: $ru = sip:400;existing=yes@172.16.1.19:7060;user=phone 1(2206122) NOTICE: Set $ru = "sip:1234;first=yes@example.com;transport=udp" 1(2206122) INFO: $ru: sip:1234;first=yes@example.com;transport=udp 1(2206122) INFO: $rU: 1234;first=yes 1(2206122) INFO: Success! 1(2206122) NOTICE: Set $rU = "1234;second=yes" 1(2206122) INFO: $ru: sip:1234;second=yes@example.com;transport=udp 1(2206122) INFO: $rU: 1234;second=yes 1(2206122) INFO: Success! ``` Same as previous, but with incoming user-param. --- ``` 1(2206122) NOTICE: Incoming INVITE to 100 1(2206122) INFO: $ru = sip:100;existing=yes@172.16.1.19:7060;user=phone 1(2206122) NOTICE: Set $rU = "1234;first=yes" 1(2206122) INFO: $ru: sip:1234;first=yes;existing=yes@172.16.1.19:7060;user=phone 1(2206122) INFO: $rU: 1234 1(2206122) ERROR: Fail! ``` This one fails in an interesting way. The incoming uri has a user-param. When overwriting $rU with a user-param, the user-param from the incoming request is kept in addition to the new one instead of being overwritten. $rU still misses (both) user-params. #### Debugging Data I have no build (yet) with EXTRA_DEBUG enabled. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3762 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3762(a)github.com>

4 months, 1 week

[kamailio/kamailio] tm: memory leak in case dropping messages in local-request event route (PR #3403)

by Simon Darienko

#### 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 I faced an issue with memory leak in case drop NOTIFY messages in the "local-request" event route in `mem_copy_subs` and `build_uac_req` analysis of mem leak: kamcmd corex.shm_summary <code>... Mar 23 12:00:28 pbx kamailio[72308]: NOTICE: fm_status: fm_sums(): count= 11 size= 7520 bytes from presence: hash.c: mem_copy_subs(141)<br> Mar 23 12:00:28 pbx kamailio[72308]: NOTICE: fm_status: fm_sums(): count= 23 size= 22536 bytes from tm: t_msgbuilder.c: build_uac_req(1618) ...</code> a lot of dropped messages in local-request event route <code>... Mar 23 12:01:09 pbx kamailio[72308]: NOTICE: fm_status: fm_sums(): count= 83 size= 51256 bytes from presence: hash.c: mem_copy_subs(141) Mar 23 12:01:09 pbx kamailio[72308]: NOTICE: fm_status: fm_sums(): count= 98 size= 116864 bytes from tm: t_msgbuilder.c: build_uac_req(1618) ...</code> no messages, no activities <code>... Mar 23 12:02:34 pbx kamailio[72308]: NOTICE: fm_status: fm_sums(): count= 83 size= 51256 bytes from presence: hash.c: mem_copy_subs(141) Mar 23 12:02:34 pbx kamailio[72308]: NOTICE: fm_status: fm_sums(): count= 96 size= 115432 bytes from tm: t_msgbuilder.c: build_uac_req(1618) ...</code> In the code, we have a comment like "never free cbp here because if t_uac_prepare fails, cbp is not freed and thus caller has no chance to discover if it is freed or not", but we'll free the cbp in two cases: 1. in case of error, but we have if (ret == E_DROP) then ret = 0; (so, no error result) 2. in case call insert_tmcb for cbp, but we don't do it for E_DROP You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3403 -- Commit Summary -- * tm: memory leak in case dropping messages in local-request event route -- File Changes -- M src/modules/tm/uac.c (8) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3403.patch https://github.com/kamailio/kamailio/pull/3403.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3403 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3403(a)github.com>

4 months, 1 week

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev May 2024