sr-dev April 2023

sr-dev@lists.kamailio.org

15 participants
157 discussions

[kamailio/kamailio] Adding SSL support to db_redis and ndb_redis (PR #3345)

by joelbax

#### Pre-Submission Checklist    - [x] Commit message has the format required by CONTRIBUTING guide - [x] Commits are split per component (core, individual modules, libs, utils, ...) - [ ] Each component has a single commit (if not, squash them into one commit) - [ ] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated) #### Type Of Change - [ ] Small bug fix (non-breaking change which fixes an issue) - [ ] 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 - [ ] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description A couple of commit (1 per each module) adding SSL support to db_redis and ndb_redis. This mainly includes checking if proper parameter is provided (for ndb_redis it is `ssl` option in the DB URL and, for db_redis, a new `opt_ssl` parameter) and create a temporary SSL context that is used to initialise the redis context. db_redis is also updated with another parameter to provide a DB access password. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3345 -- Commit Summary -- * db_redis: Adding SSL support * ndb_redis: Adding SSL support -- File Changes -- M src/modules/db_redis/Makefile (8) M src/modules/db_redis/db_redis_mod.c (5) M src/modules/db_redis/redis_connection.c (43) M src/modules/db_redis/redis_connection.h (2) M src/modules/ndb_redis/Makefile (6) M src/modules/ndb_redis/redis_client.c (47) M src/modules/ndb_redis/redis_client.h (3) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3345.patch https://github.com/kamailio/kamailio/pull/3345.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3345 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3345(a)github.com>

6 days, 15 hours

[kamailio/kamailio] topoh: uses socket IP when no mask_ip is defined (PR #3341)

by TorPetterson

#### 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) - [ ] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated) #### Type Of Change - [ ] Small bug fix (non-breaking change which fixes an issue) - [ ] 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 - [ ] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description  topoh: uses socket IP when no mask_ip is defined If the parameter mask_ip is not defined the module finds the socket IP and uses that as mask IP for the message. If the socket has an advertised IP it is used, otherwise the socket IP is used. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3341 -- Commit Summary -- * topoh: uses socket IP when no mask_ip is defined * Merge remote-tracking branch 'upstream/master' -- File Changes -- M src/modules/topoh/doc/topoh_admin.xml (4) M src/modules/topoh/th_msg.c (55) M src/modules/topoh/th_msg.h (16) M src/modules/topoh/topoh_mod.c (309) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3341.patch https://github.com/kamailio/kamailio/pull/3341.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3341 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3341(a)github.com>

1 week, 1 day

[kamailio/kamailio] ipops: srv_query and naptr_query do not trigger DNS request (Issue #3419)

by sergey-safarov

### Description I found `srv_query` and `naptr_query` do not trigger DNS requests. This was checked via Kamailio logs and via tcpdump utility. #### Reproduction Required start Kamailio with config like ``` #!define L_DBG 3 #!define IPV4_ADDR 127.0.0.1 loadmodule "debugger.so" modparam("debugger", "cfgtrace", 1) modparam("debugger", "log_level_name", "exec") debug=L_DBG log_stderror=yes loadmodule "ipops.so" listen=udp:IPV4_ADDR name "ipv4_udp" request_route { naptr_query ("example.com", "res"); srv_query ("_sip._udp.example.com", "udp"); dns_query("test.com", "xyz"); drop; } ``` #### Log Messages ``` 28(2324390) DEBUG: <core> [core/ip_addr.c:580]: print_ip(): tcpconn_new: new tcp connection: 2600:1f18:578:5702:0:0:0:cc 28(2324390) DEBUG: <core> [core/tcp_main.c:1216]: tcpconn_new(): on port 34664, type 2, socket 46 28(2324390) DEBUG: <core> [core/tcp_main.c:1548]: tcpconn_add(): hashes: 1351:58:985, 2 28(2324390) DEBUG: <core> [core/io_wait.h:374]: io_watch_add(): processing io_watch_add(0x9ff548, 46, 2, 0xffff901ff268) - fd_no=40 28(2324390) DEBUG: <core> [core/io_wait.h:599]: io_watch_del(): DBG: io_watch_del (0x9ff548, 46, -1, 0x0) fd_no=41 called 28(2324390) DEBUG: <core> [core/tcp_main.c:4547]: handle_tcpconn_ev(): sending to child, events 1 28(2324390) DEBUG: <core> [core/tcp_main.c:4217]: send2child(): selected tcp worker idx:1 proc:21 pid:2324383 for activity on [tcp:[2605:84c0:88:42::1]:5060], 0xffff901ff268 21(2324383) DEBUG: <core> [core/tcp_read.c:1735]: handle_io(): received n=8 con=0xffff901ff268, fd=6 21(2324383) DEBUG: <core> [core/tcp_read.c:1533]: tcp_read_req(): content-length=782 21(2324383) DEBUG: <core> [core/parser/parse_fline.c:249]: parse_first_line(): first line type 1 (request) flags 1 21(2324383) DEBUG: <core> [core/parser/msg_parser.c:679]: parse_msg(): SIP Request: 21(2324383) DEBUG: <core> [core/parser/msg_parser.c:680]: parse_msg(): method: <INVITE> 21(2324383) DEBUG: <core> [core/parser/msg_parser.c:682]: parse_msg(): uri: <urn:service:sos> 21(2324383) DEBUG: <core> [core/parser/msg_parser.c:684]: parse_msg(): version: <SIP/2.0> 21(2324383) DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [Record-Route] type 10 21(2324383) DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [Record-Route] type 10 21(2324383) DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [Via] type 1 21(2324383) DEBUG: <core> [core/parser/parse_via.c:1300]: parse_via_param(): Found param type 232, <branch> = <z9hG4bKb72a.e5268cd9ad7d121798072d354270bec4.0>; state=6 21(2324383) DEBUG: <core> [core/parser/parse_via.c:1300]: parse_via_param(): Found param type 236, <i> = <6c7781>; state=16 21(2324383) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 21(2324383) DEBUG: <core> [core/parser/msg_parser.c:555]: parse_headers(): Via found, flags=2 21(2324383) DEBUG: <core> [core/parser/msg_parser.c:557]: parse_headers(): this is the first via 21(2324383) DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [Via] type 1 21(2324383) DEBUG: <core> [core/parser/parse_via.c:1300]: parse_via_param(): Found param type 234, <received> = <2600:1f18:578:5704:62c1:bea:3535:6449>; state=6 21(2324383) DEBUG: <core> [core/parser/parse_via.c:1300]: parse_via_param(): Found param type 235, <rport> = <34895>; state=6 21(2324383) DEBUG: <core> [core/parser/parse_via.c:1300]: parse_via_param(): Found param type 232, <branch> = <z9hG4bKrB4pr8Sa2gaKQ>; state=16 21(2324383) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 21(2324383) DEBUG: <core> [core/parser/msg_parser.c:555]: parse_headers(): Via found, flags=78 21(2324383) DEBUG: <core> [core/parser/msg_parser.c:568]: parse_headers(): this is the second via 21(2324383) DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [Max-Forwards] type 8 21(2324383) DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [From] type 4 21(2324383) DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [To] type 3 21(2324383) DEBUG: <core> [core/parser/parse_addr_spec.c:884]: parse_addr_spec(): end of header reached, state=10 21(2324383) DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): <To> [19]; uri=[urn:service:sos] 21(2324383) DEBUG: <core> [core/parser/msg_parser.c:174]: get_hdr_field(): to body (19)[<urn:service:sos> ], to tag (0)[] 21(2324383) DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [Call-ID] type 6 21(2324383) DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [CSeq] type 5 21(2324383) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <66360993> <INVITE> 21(2324383) DEBUG: <core> [core/receive.c:389]: receive_msg(): --- received sip message - request - call-id: [b12b3938-ddf8-11ed-8503-e9120e4ae1c8] - cseq: [66360993 INVITE] 21(2324383) DEBUG: <core> [core/receive.c:261]: ksr_evrt_pre_routing(): event route core:pre-routing not defined 21(2324383) DEBUG: <core> [core/receive.c:471]: receive_msg(): preparing to run routing scripts... 21(2324383) exec: *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/etc/sip-aggregator/kamailio2.cfg] l=34 a=26 n=naptr_query 21(2324383) DEBUG: ipops [ipops_pv.c:1483]: naptr_update_pv(): ipops_pv.c:1483 naptr_update_pv - called: naptrname => [example.com], pvid => [res] 21(2324383) DEBUG: ipops [ipops_pv.c:1204]: sr_naptr_add_item(): ipops_pv.c:1204 sr_naptr_add_item - called: pvid => [res] findflg => [1] 21(2324383) DEBUG: ipops [ipops_pv.c:1503]: naptr_update_pv(): pvid not found: res 21(2324383) exec: *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/etc/sip-aggregator/kamailio2.cfg] l=35 a=26 n=srv_query 21(2324383) DEBUG: ipops [ipops_pv.c:1034]: srv_update_pv(): pvid not found: udp 21(2324383) exec: *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/etc/sip-aggregator/kamailio2.cfg] l=36 a=26 n=dns_query 21(2324383) DEBUG: ipops [ipops_pv.c:390]: dns_update_pv(): attempting to resolve: test.com 21(2324383) DEBUG: ipops [ipops_pv.c:421]: dns_update_pv(): #0 - type 4 addr: 67.225.146.248 (2) 21(2324383) DEBUG: ipops [ipops_pv.c:434]: dns_update_pv(): dns PV updated for: test.com (1) 21(2324383) exec: *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/etc/sip-aggregator/kamailio2.cfg] l=37 a=2 n=drop 21(2324383) DEBUG: <core> [core/receive.c:528]: receive_msg(): request-route executed in: 4324 usec 21(2324383) DEBUG: <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list (nil) 21(2324383) DEBUG: <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list (nil) 21(2324383) DEBUG: <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list (nil) 21(2324383) DEBUG: <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list (nil) 21(2324383) DEBUG: <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list (nil) 21(2324383) DEBUG: <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list (nil) 21(2324383) DEBUG: <core> [core/xavp.c:541]: xavp_destroy_list(): destroying xavp list (nil) 21(2324383) DEBUG: <core> [core/xavp.c:541]: xavp_destroy_list(): destroying xavp list (nil) 21(2324383) DEBUG: <core> [core/xavp.c:541]: xavp_destroy_list(): destroying xavp list (nil) 21(2324383) DEBUG: <core> [core/receive.c:628]: receive_msg(): cleaning up 21(2324383) DEBUG: <core> [core/io_wait.h:374]: io_watch_add(): processing io_watch_add(0xa437d8, 6, 2, 0xffff901ff268) - fd_no=1 ``` ### Additional Information * **Kamailio Version** - output of `kamailio -v` Here is little modified 5.6.4 ``` version: kamailio 5.6.4 (aarch64/linux) 5583a2 flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT-NOSMP, 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: 5583a2 compiled on 00:00:00 Sep 13 2022 with gcc 12.2.1 ``` * **Operating System**: ``` NAME="Fedora Linux" VERSION="37.20230322.3.0 (CoreOS)" ID=fedora VERSION_ID=37 VERSION_CODENAME="" PLATFORM_ID="platform:f37" PRETTY_NAME="Fedora CoreOS 37.20230322.3.0" ANSI_COLOR="0;38;2;60;110;180" LOGO=fedora-logo-icon CPE_NAME="cpe:/o:fedoraproject:fedora:37" HOME_URL="https://getfedora.org/coreos/" DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora-coreos/" SUPPORT_URL="https://github.com/coreos/fedora-coreos-tracker/" BUG_REPORT_URL="https://github.com/coreos/fedora-coreos-tracker/" REDHAT_BUGZILLA_PRODUCT="Fedora" REDHAT_BUGZILLA_PRODUCT_VERSION=37 REDHAT_SUPPORT_PRODUCT="Fedora" REDHAT_SUPPORT_PRODUCT_VERSION=37 SUPPORT_END=2023-11-14 VARIANT="CoreOS" VARIANT_ID=coreos OSTREE_VERSION='37.20230322.3.0' ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3419 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3419(a)github.com>

1 week, 5 days

[kamailio/kamailio] tm:t_lookup_callid use only trans Call-ID header value to match with … (PR #3393)

by descartin

…callid param   #### Pre-Submission Checklist    - [ ] Commit message has the format required by CONTRIBUTING guide - [ ] Commits are split per component (core, individual modules, libs, utils, ...) - [ ] Each component has a single commit (if not, squash them into one commit) - [ ] 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  Using kamailio 5.4 version, we have had an issue with a carrier that sent a CANCEL with to-tag. To be able to process that request, we used the function t_cancel_callid, to convert that abnormal CANCEL to a regular one cancelling the current transaction for that call. But we saw that it was not working since they sent the callid header named as CALL-ID. Seems the matching between the stored callid header in memory and the param passed for the callid lookup matching, is being done in case sensitive way with a generated Call-ID: XXXXXXXX based on the called param of the function. we have tested a wasy to do the comparision only with the callid header value, so we strip from the callid header stored at memory the Call-ID: (or CALL-ID:) part. maybe there is another way to do that in other part of the code, but seems at least this worked for the tests thanks a lot and regards david You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3393 -- Commit Summary -- * tm:t_lookup_callid use only trans Call-ID header value to match with callid param -- File Changes -- M src/modules/tm/t_lookup.c (10) M src/modules/tm/t_msgbuilder.c (9) M src/modules/tm/t_msgbuilder.h (1) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3393.patch https://github.com/kamailio/kamailio/pull/3393.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3393 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3393(a)github.com>

1 week, 5 days

[kamailio/kamailio] kamailio 5.7.0 cant't use siprepo function sr_msg_push() (Issue #3418)

by zhangyang

### Description When I use the siprepo module, according to the documentation, I use the sr_msg_push function, and the startup log will report an error "failed to find command sr_msg_push (params 2)" this is my cfg code: $var(msgid) = $sruid; if(sr_msg_push("$var(msgid)")) { xlog("L_INFO","OUT Call $ci: INVITE_PBX save the call mgsid is $var(msgid),callid is $ci\n"); exit(); } According to the code, I found that the parameters of this function should be two, and the second one is an int, but I did not find the use of the int type "rmode" in the siprepo_msg_set function。 So I changed the code to this： $var(msgid) = $sruid; if(sr_msg_push("$var(msgid)",1)) { xlog("L_INFO","OUT Call $ci: INVITE_PBX save the call mgsid is $var(msgid),callid is $ci\n"); exit(); } This time it started successfully, but a crash occurred when calling。The following is the core file analysis #### Debugging Data ``` GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-120.el7 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /home/ucp/fusionsbc/bin/ucp_proxy...done. [New LWP 78415] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Missing separate debuginfo for /home/ucp/fusionsbc/pgsql/lib/libgssapi_krb5.so.2 Missing separate debuginfo for /home/ucp/fusionsbc/pgsql/lib/libkrb5.so.3 Missing separate debuginfo for /home/ucp/fusionsbc/pgsql/lib/libk5crypto.so.3 Missing separate debuginfo for /home/ucp/fusionsbc/pgsql/lib/libz.so.1 Missing separate debuginfo for /home/ucp/fusionsbc/pgsql/lib/libcom_err.so.3 Missing separate debuginfo for /home/ucp/fusionsbc/pgsql/lib/libkrb5support.so.0 Core was generated by `/home/ucp/fusionsbc/bin/ucp_proxy -P /home/ucp/fusionsbc/run/proxy.pid -f /home'. Program terminated with signal 11, Segmentation fault. #0 0x00002b2a919420ae in get_hash1_raw (s=0x0, len=36) at ../../core/hashes.h:109 109 hash_update_str(s, s+len, p, v, h); Missing separate debuginfos, use: debuginfo-install glibc-2.17-325.el7_9.x86_64 libcom_err-1.42.9-19.el7.x86_64 libgcc-4.8.5-44.el7.x86_64 libgcrypt-1.5.3-14.el7.x86_64 libgpg-error-1.12-3.el7.x86_64 libunistring-0.9.3-9.el7.x86_64 lua-5.1.4-15.el7.x86_64 openssl-libs-1.0.2k-26.el7_9.x86_64 pcre-8.32-17.el7.x86_64 sqlite-3.7.17-8.el7_7.1.x86_64 (gdb) (gdb) (gdb) (gdb) (gdb) (gdb) bt #0 0x00002b2a919420ae in get_hash1_raw (s=0x0, len=36) at ../../core/hashes.h:109 #1 0x00002b2a91944eb3 in siprepo_msg_set (msg=0x2b2a8aa810d0, msgid=0x7ffca5cbd8c0, rmode=1) at siprepo_data.c:222 #2 0x00002b2a91949eda in ki_sr_msg_push (msg=0x2b2a8aa810d0, msgid=0x7ffca5cbd8c0, rmode=1) at siprepo_mod.c:156 #3 0x00002b2a9194a60e in w_sr_msg_push (msg=0x2b2a8aa810d0, pmsgid=0x2b2a8a487b08 "\220zH\212*+", prmode=0x2b2a8a487c30 "") at siprepo_mod.c:181 #4 0x0000000000465a8c in do_action (h=0x7ffca5cbe190, a=0x2b2a8a48bad8, msg=0x2b2a8aa810d0) at core/action.c:1088 #5 0x0000000000472d29 in run_actions (h=0x7ffca5cbe190, a=0x2b2a8a48bad8, msg=0x2b2a8aa810d0) at core/action.c:1581 #6 0x00000000004733a5 in run_actions_safe (h=0x7ffca5cbee10, a=0x2b2a8a48bad8, msg=0x2b2a8aa810d0) at core/action.c:1645 #7 0x00000000004396e6 in rval_get_int (h=0x7ffca5cbee10, msg=0x2b2a8aa810d0, i=0x7ffca5cbeabc, rv=0x2b2a8a48cb78, cache=0x0) at core/rvalue.c:915 #8 0x000000000043e217 in rval_expr_eval_int (h=0x7ffca5cbee10, msg=0x2b2a8aa810d0, res=0x7ffca5cbeabc, rve=0x2b2a8a48cb70) at core/rvalue.c:1913 #9 0x0000000000465457 in do_action (h=0x7ffca5cbee10, a=0x2b2a8a48d7c8, msg=0x2b2a8aa810d0) at core/action.c:1052 #10 0x0000000000472d29 in run_actions (h=0x7ffca5cbee10, a=0x2b2a8a480510, msg=0x2b2a8aa810d0) at core/action.c:1581 #11 0x000000000047346d in run_top_route (a=0x2b2a8a480510, msg=0x2b2a8aa810d0, c=0x0) at core/action.c:1666 #12 0x00000000005d7f61 in receive_msg ( buf=0xabca80 <buf.7134> "INVITE sip:1005@192.168.10.60:55067 SIP/2.0\r\nVia: SIP/2.0/UDP 192.168.10.77:5080;rport;branch=z9hG4bKjDFXQjF8278rr\r\nMax-Forwards: 70\r\nFrom: \"\" <sip:0000000000@192.168.10.77>;tag=gQ6aBXpg5gcXF\r\nTo: <si"..., len=1532, rcv_info=0x7ffca5cbf500) at core/receive.c:423 #13 0x00000000004ca6fb in udp_rcv_loop () at core/udp_server.c:543 #14 0x0000000000429d47 in main_loop () at main.c:1683 #15 0x0000000000433a96 in main (argc=9, argv=0x7ffca5cbfd88) at main.c:2856 (gdb) f 1 #1 0x00002b2a91944eb3 in siprepo_msg_set (msg=0x2b2a8aa810d0, msgid=0x7ffca5cbd8c0, rmode=1) at siprepo_data.c:222 warning: Source file is more recent than executable. 222 it->hid = get_hash1_raw(it->callid.s, it->callid.len); (gdb) info local hid = 2879241394 slotid = 178 dsize = 1928 vbr = 0x2b2a8a9c72b0 scallid = {s = 0xabcb6e <buf.7134+238> "e7f00e70-5866-123c-f09f-b827ebf8b6d3\r\nCSeq: 66349691 INVITE\r\nContact: <sip:mod_sofia@192.168.10.77:5080>\r\nUser-Agent: FreeSWITCH-mod_sofia/1.10.1-dev-25-a4c5802372~32bit\r\nAllow: INVITE, ACK, BYE, CANC"..., len = 36} it = 0x2b2a92864d90 __FUNCTION__ = "siprepo_msg_set" (gdb) p it->callid $1 = {s = 0x0, len = 36} (gdb) p it->hid $2 = 0 (gdb) p *it $3 = {hid = 0, mtype = 0, msgid = {s = 0x0, len = 0}, callid = {s = 0x0, len = 36}, ftag = { s = 0xabcb32 <buf.7134+178> "gQ6aBXpg5gcXF\r\nTo: <sip:1005@192.168.10.60:55067>\r\nCall-ID: e7f00e70-5866-123c-f09f-b827ebf8b6d3\r\nCSeq: 66349691 INVITE\r\nContact: <sip:mod_sofia@192.168.10.77:5080>\r\nUser-Agent: FreeSWITCH-mod_sofia/1"..., len = 13}, cseqnum = { s = 0xabcb9a <buf.7134+282> "66349691 INVITE\r\nContact: <sip:mod_sofia@192.168.10.77:5080>\r\nUser-Agent: FreeSWITCH-mod_sofia/1.10.1-dev-25-a4c5802372~32bit\r\nAllow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER"..., len = 8}, cseqmet = {s = 0xabcba3 <buf.7134+291> "INVITE\r\nContact: <sip:mod_sofia@192.168.10.77:5080>\r\nUser-Agent: FreeSWITCH-mod_sofia/1.10.1-dev-25-a4c5802372~32bit\r\nAllow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, "..., len = 6}, vbranch = { s = 0xabcade <buf.7134+94> "z9hG4bKjDFXQjF8278rr\r\nMax-Forwards: 70\r\nFrom: \"\" <sip:0000000000@192.168.10.77>;tag=gQ6aBXpg5gcXF\r\nTo: <sip:1005@192.168.10.60:55067>\r\nCall-ID: e7f00e70-5866-123c-f09f-b827ebf8b6d3\r\nCSeq: 66349691 INV"..., len = 20}, dbuf = {s = 0x2b2a92864f00 "", len = 0}, cseqmetid = 0, msgno = 0, pid = 0, mflags = 0, rcv = {src_ip = {af = 0, len = 0, u = {addrl = {0, 0}, addr32 = {0, 0, 0, 0}, addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, addr = '\000' <repeats 15 times>}}, dst_ip = {af = 0, len = 0, u = {addrl = {0, 0}, addr32 = {0, 0, 0, 0}, addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, addr = '\000' <repeats 15 times>}}, src_port = 0, dst_port = 0, proto_reserved1 = 0, proto_reserved2 = 0, src_su = {s = {sa_family = 0, sa_data = '\000' <repeats 13 times>}, sin = {sin_family = 0, sin_port = 0, sin_addr = {s_addr = 0}, sin_zero = "\000\000\000\000\000\000\000"}, sin6 = {sin6_family = 0, sin6_port = 0, sin6_flowinfo = 0, sin6_addr = {__in6_u = { __u6_addr8 = '\000' <repeats 15 times>, __u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}, sin6_scope_id = 0}, sas = {ss_family = 0, __ss_padding = '\000' <repeats 117 times>, __ss_align = 0}}, bind_address = 0x0, proto = 0 '\000', proto_pad0 = 0 '\000', proto_pad1 = 0}, itime = 0, next = 0x0, prev = 0x0} (gdb) p * msg $4 = {id = 1, pid = 0, tval = {tv_sec = 0, tv_usec = 0}, fwd_send_flags = {f = 0, blst_imask = 0}, rpl_send_flags = {f = 0, blst_imask = 0}, first_line = {type = 1, flags = 1, len = 45, u = {request = {method = { s = 0xabca80 <buf.7134> "INVITE sip:1005@192.168.10.60:55067 SIP/2.0\r\nVia: SIP/2.0/UDP 192.168.10.77:5080;rport;branch=z9hG4bKjDFXQjF8278rr\r\nMax-Forwards: 70\r\nFrom: \"\" <sip:0000000000@192.168.10.77>;tag=gQ6aBXpg5gcXF\r\nTo: <si"..., len = 6}, uri = { s = 0xabca87 <buf.7134+7> "sip:1005@192.168.10.60:55067 SIP/2.0\r\nVia: SIP/2.0/UDP 192.168.10.77:5080;rport;branch=z9hG4bKjDFXQjF8278rr\r\nMax-Forwards: 70\r\nFrom: \"\" <sip:0000000000@192.168.10.77>;tag=gQ6aBXpg5gcXF\r\nTo: <sip:1005@"..., len = 28}, version = { s = 0xabcaa4 <buf.7134+36> "SIP/2.0\r\nVia: SIP/2.0/UDP 192.168.10.77:5080;rport;branch=z9hG4bKjDFXQjF8278rr\r\nMax-Forwards: 70\r\nFrom: \"\" <sip:0000000000@192.168.10.77>;tag=gQ6aBXpg5gcXF\r\nTo: <sip:1005@192.168.10.60:55067>\r\nCall-ID"..., len = 7}, method_value = 1}, reply = {version = { s = 0xabca80 <buf.7134> "INVITE sip:1005@192.168.10.60:55067 SIP/2.0\r\nVia: SIP/2.0/UDP 192.168.10.77:5080;rport;branch=z9hG4bKjDFXQjF8278rr\r\nMax-Forwards: 70\r\nFrom: \"\" <sip:0000000000@192.168.10.77>;tag=gQ6aBXpg5gcXF\r\nTo: <si"..., len = 6}, status = { s = 0xabca87 <buf.7134+7> "sip:1005@192.168.10.60:55067 SIP/2.0\r\nVia: SIP/2.0/UDP 192.168.10.77:5080;rport;branch=z9hG4bKjDFXQjF8278rr\r\nMax-Forwards: 70\r\nFrom: \"\" <sip:0000000000@192.168.10.77>;tag=gQ6aBXpg5gcXF\r\nTo: <sip:1005@"..., len = 28}, reason = { s = 0xabcaa4 <buf.7134+36> "SIP/2.0\r\nVia: SIP/2.0/UDP 192.168.10.77:5080;rport;branch=z9hG4bKjDFXQjF8278rr\r\nMax-Forwards: 70\r\nFrom: \"\" <sip:0000000000@192.168.10.77>;tag=gQ6aBXpg5gcXF\r\nTo: <sip:1005@192.168.10.60:55067>\r\nCall-ID"..., len = 7}, statuscode = 1}}}, via1 = 0x2b2a8a9c70b8, via2 = 0x0, headers = 0x2b2a8a9c7010, last_header = 0x2b2a8a9b5a50, parsed_flag = 18446744073709551615, h_via1 = 0x2b2a8a9c7010, h_via2 = 0x0, callid = 0x2b2a8a9b2068, to = 0x2b2a8a9adaa8, cseq = 0x2b2a8a9b2110, from = 0x2b2a8a9ad728, contact = 0x2b2a8a9b2250, maxforwards = 0x2b2a8a9ad680, route = 0x0, record_route = 0x0, content_type = 0x2b2a8a9b2598, content_length = 0x2b2a8a9b26e8, authorization = 0x0, expires = 0x0, proxy_auth = 0x0, supported = 0x2b2a8a9b2448, require = 0x0, proxy_require = 0x0, unsupported = 0x0, allow = 0x2b2a8a9b23a0, event = 0x0, accept = 0x0, accept_language = 0x0, organization = 0x0, priority = 0x0, subject = 0x0, user_agent = 0x2b2a8a9b22f8, server = 0x0, content_disposition = 0x2b2a8a9b2640, diversion = 0x0, rpid = 0x2b2a8a9b5a50, refer_to = 0x0, session_expires = 0x0, min_se = 0x0, sipifmatch = 0x0, subscription_state = 0x0, date = 0x0, identity = 0x0, identity_info = 0x0, pai = 0x0, ppi = 0x0, path = 0x0, privacy = 0x0, min_expires = 0x0, body = 0x0, eoh = 0xabcd92 <buf.7134+786> "\r\nv=0\r\no=FreeSWITCH 1681788467 1681788468 IN IP4 192.168.10.77\r\ns=FreeSWITCH\r\nc=IN IP4 192.168.10.77\r\nt=0 0\r\nm=audio 18500 RTP/AVP 102 9 0 8 105 101\r\na=rtpmap:102 opus/48000/2\r\na=fmtp:102 useinbandfec"..., unparsed = 0xabcd92 <buf.7134+786> "\r\nv=0\r\no=FreeSWITCH 1681788467 1681788468 IN IP4 192.168.10.77\r\ns=FreeSWITCH\r\nc=IN IP4 192.168.10.77\r\nt=0 0\r\nm=audio 18500 RTP/AVP 102 9 0 8 105 101\r\na=rtpmap:102 opus/48000/2\r\na=fmtp:102 useinbandfec"..., rcv = {src_ip = {af = 2, len = 4, u = {addrl = {1292544192, 0}, addr32 = {1292544192, 0, 0, 0}, addr16 = {43200, 19722, 0, 0, 0, 0, 0, 0}, addr = "\300\250\nM", '\000' <repeats 11 times>}}, dst_ip = {af = 2, len = 4, u = {addrl = {1007331520, 0}, addr32 = {1007331520, 0, 0, 0}, addr16 = {43200, 15370, 0, 0, 0, 0, 0, 0}, addr = "\300\250\n<", '\000' <repeats 11 times>}}, src_port = 5080, dst_port = 55067, proto_reserved1 = 0, proto_reserved2 = 0, src_su = {s = {sa_family = 2, sa_data = "\023\330\300\250\nM\000\000\000\000\000\000\000"}, sin = {sin_family = 2, sin_port = 55315, sin_addr = {s_addr = 1292544192}, sin_zero = "\000\000\000\000\000\000\000"}, sin6 = {sin6_family = 2, sin6_port = 55315, sin6_flowinfo = 1292544192, sin6_addr = {__in6_u = {__u6_addr8 = '\000' <repeats 15 times>, __u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}, sin6_scope_id = 0}, sas = {ss_family = 2, __ss_padding = "\023\330\300\250\nM", '\000' <repeats 111 times>, __ss_align = 0}}, bind_address = 0x2b2a8a47c2d0, proto = 1 '\001', proto_pad0 = 0 '\000', proto_pad1 = 0}, buf = 0xabca80 <buf.7134> "INVITE sip:1005@192.168.10.60:55067 SIP/2.0\r\nVia: SIP/2.0/UDP 192.168.10.77:5080;rport;branch=z9hG4bKjDFXQjF8278rr\r\nMax-Forwards: 70\r\nFrom: \"\" <sip:0000000000@192.168.10.77>;tag=gQ6aBXpg5gcXF\r\nTo: <si"..., len = 1532, new_uri = {s = 0x0, len = 0}, dst_uri = {s = 0x0, len = 0}, parsed_uri_ok = 1, parsed_uri = {user = { s = 0xabca8b <buf.7134+11> "1005@192.168.10.60:55067 SIP/2.0\r\nVia: SIP/2.0/UDP 192.168.10.77:5080;rport;branch=z9hG4bKjDFXQjF8278rr\r\nMax-Forwards: 70\r\nFrom: \"\" <sip:0000000000@192.168.10.77>;tag=gQ6aBXpg5gcXF\r\nTo: <sip:1005@192."..., len = 4}, passwd = {s = 0x0, len = 0}, host = { s = 0xabca90 <buf.7134+16> "192.168.10.60:55067 SIP/2.0\r\nVia: SIP/2.0/UDP 192.168.10.77:5080;rport;branch=z9hG4bKjDFXQjF8278rr\r\nMax-Forwards: 70\r\nFrom: \"\" <sip:0000000000@192.168.10.77>;tag=gQ6aBXpg5gcXF\r\nTo: <sip:1005@192.168.1"..., len = 13}, port = { ---Type <return> to continue, or q <return> to quit--- s = 0xabca9e <buf.7134+30> "55067 SIP/2.0\r\nVia: SIP/2.0/UDP 192.168.10.77:5080;rport;branch=z9hG4bKjDFXQjF8278rr\r\nMax-Forwards: 70\r\nFrom: \"\" <sip:0000000000@192.168.10.77>;tag=gQ6aBXpg5gcXF\r\nTo: <sip:1005@192.168.10.60:55067>\r\nC"..., len = 5}, params = {s = 0x0, len = 0}, sip_params = {s = 0x0, len = 0}, headers = {s = 0x0, len = 0}, port_no = 55067, proto = 0, type = SIP_URI_T, flags = (unknown: 0), transport = {s = 0x0, len = 0}, ttl = {s = 0x0, len = 0}, user_param = {s = 0x0, len = 0}, maddr = {s = 0x0, len = 0}, method = {s = 0x0, len = 0}, lr = {s = 0x0, len = 0}, r2 = {s = 0x0, len = 0}, gr = {s = 0x0, len = 0}, transport_val = {s = 0x0, len = 0}, ttl_val = {s = 0x0, len = 0}, user_param_val = {s = 0x0, len = 0}, maddr_val = {s = 0x0, len = 0}, method_val = {s = 0x0, len = 0}, lr_val = {s = 0x0, len = 0}, r2_val = {s = 0x0, len = 0}, gr_val = {s = 0x0, len = 0}}, parsed_orig_ruri_ok = 0, parsed_orig_ruri = {user = {s = 0x0, len = 0}, passwd = {s = 0x0, len = 0}, host = {s = 0x0, len = 0}, port = {s = 0x0, len = 0}, params = {s = 0x0, len = 0}, sip_params = {s = 0x0, len = 0}, headers = {s = 0x0, len = 0}, port_no = 0, proto = 0, type = ERROR_URI_T, flags = (unknown: 0), transport = {s = 0x0, len = 0}, ttl = {s = 0x0, len = 0}, user_param = {s = 0x0, len = 0}, maddr = {s = 0x0, len = 0}, method = {s = 0x0, len = 0}, lr = {s = 0x0, len = 0}, r2 = {s = 0x0, len = 0}, gr = {s = 0x0, len = 0}, transport_val = {s = 0x0, len = 0}, ttl_val = { s = 0x0, len = 0}, user_param_val = {s = 0x0, len = 0}, maddr_val = {s = 0x0, len = 0}, method_val = {s = 0x0, len = 0}, lr_val = {s = 0x0, len = 0}, r2_val = {s = 0x0, len = 0}, gr_val = {s = 0x0, len = 0}}, add_rm = 0x0, body_lumps = 0x0, reply_lump = 0x0, add_to_branch_s = '\000' <repeats 57 times>, add_to_branch_len = 0, hash_index = 1864, msg_flags = 128, flags = 0, xflags = {0, 0}, set_global_address = {s = 0x0, len = 0}, set_global_port = {s = 0x0, len = 0}, force_send_socket = 0x0, path_vec = {s = 0x0, len = 0}, instance = {s = 0x0, len = 0}, reg_id = 0, ruid = {s = 0x0, len = 0}, location_ua = {s = 0x0, len = 0}, otcpid = 0, ldv = {flow = {decoded = 0, rcv = {src_ip = {af = 0, len = 0, u = {addrl = {0, 0}, addr32 = {0, 0, 0, 0}, addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, addr = '\000' <repeats 15 times>}}, dst_ip = {af = 0, len = 0, u = {addrl = {0, 0}, addr32 = {0, 0, 0, 0}, addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, addr = '\000' <repeats 15 times>}}, src_port = 0, dst_port = 0, proto_reserved1 = 0, proto_reserved2 = 0, src_su = {s = {sa_family = 0, sa_data = '\000' <repeats 13 times>}, sin = {sin_family = 0, sin_port = 0, sin_addr = {s_addr = 0}, sin_zero = "\000\000\000\000\000\000\000"}, sin6 = {sin6_family = 0, sin6_port = 0, sin6_flowinfo = 0, sin6_addr = {__in6_u = {__u6_addr8 = '\000' <repeats 15 times>, __u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}, sin6_scope_id = 0}, sas = {ss_family = 0, __ss_padding = '\000' <repeats 117 times>, __ss_align = 0}}, bind_address = 0x0, proto = 0 '\000', proto_pad0 = 0 '\000', proto_pad1 = 0}}, vdata = 0x0}} ``` #### Log Messages segfault at 0 ip 00002b2a919420ae sp 00007ffca5cbd6a0 error 4 in siprepo.so[2b2a91940000+f000] #### SIP Traffic I just sent an invite via freeswitch： ``` INVITE` sip:1005@192.168.10.60:55067 SIP/2.0 Via: SIP/2.0/UDP 192.168.10.77:5080;rport;branch=z9hG4bKjDFXQjF8278rr Max-Forwards: 70 From: "" <sip:0000000000@192.168.10.77>;tag=gQ6aBXpg5gcXF To: <sip:1005@192.168.10.60:55067> Call-ID: e7f00e70-5866-123c-f09f-b827ebf8b6d3 CSeq: 66349691 INVITE Contact: <sip:mod_sofia@192.168.10.77:5080> User-Agent: FreeSWITCH-mod_sofia/1.10.1-dev-25-a4c5802372~32bit Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY Supported: timer, path, replaces Allow-Events: talk, hold, conference, refer Content-Type: application/sdp Content-Disposition: session Content-Length: 744 X-FS-Support: update_display,send_info Remote-Party-ID: <sip:0000000000@192.168.10.77>;party=calling;screen=yes;privacy=off v=0 o=FreeSWITCH 1681788467 1681788468 IN IP4 192.168.10.77 s=FreeSWITCH c=IN IP4 192.168.10.77 t=0 0 m=audio 18500 RTP/AVP 102 9 0 8 105 101 a=rtpmap:102 opus/48000/2 a=fmtp:102 useinbandfec=1; maxaveragebitrate=30000; maxplaybackrate=48000; ptime=20; minptime=10; maxptime=40 ``` * **Operating System**: Linux siphostexternal 3.10.0-1160.el7.x86_64 #1 SMP Mon Oct 19 16:18:59 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux on centos7.9.2009 ``` version: kamailio 5.7.0-pre0 (x86_64/linux) 77c41d 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 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: 77c41d compiled on 16:24:27 Apr 18 2023 with gcc 4.8.5 ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3418 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3418(a)github.com>

2 weeks, 1 day

[kamailio/kamailio] tls: build does not apply TLS_PTHREAD_MUTEX_SHARED on systems with libssl 1.1+ and without pkg-config (Issue #3384)

by shaneqld

### Description On systems running libssl 1.1+, the compile flag `TLS_PTHREAD_MUTEX_SHARED` is set to avoid an issue with deadlocks. However, if the system does not have `pkg-config` installed, the build completes successfully without setting this compile flag. As such, users with this particular configuration are at risk of TLS-related deadlocks. ### Troubleshooting This scenario arose for me when I experienced suspected TLS-related deadlocks in Kamailio 5.4.1. Particularly, in a simple configuration, multiple UDP workers were using t_relay to near-simultaneously connect to the same TLS host. After some time, the UDP workers stopped responding while executing this simple route block. I cannot definitively conclude this issue was the same deadlock bug. The compile flag `TLS_PTHREAD_MUTEX_SHARED` was not set and `pkg-config` was not installed. I found [this mailing list thread](https://lists.kamailio.org/pipermail/sr-users/2019-December/107759.… discussing TLS deadlocks and the build process and the user was running Kamailio 5.3.1, libssl 1.1 but did not have `TLS_PTHREAD_MUTEX_SHARED` set. This issue may explain how this user ended up in that situation. #### Reproduction Tested against Kamailio 5.4.1 and latest master. On a system with libssl 1.1+, build (including the `tls` module) with `pkg-config` installed and run `kamailio -I`. `TLS_PTHREAD_MUTEX_SHARED` flag is set. ``` Version: kamailio 5.7.0-dev3 (x86_64/linux) b75b6e Default config: /usr/local/etc/kamailio/kamailio.cfg Default paths to modules: /usr/local/lib64/kamailio/modules Compile 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 ``` Uninstall `pkg-config` and rebuild. `TLS_PTHREAD_MUTEX_SHARED` flag is not set. ``` Version: kamailio 5.7.0-dev3 (x86_64/linux) b75b6e Default config: /usr/local/etc/kamailio/kamailio.cfg Default paths to modules: /usr/local/lib64/kamailio/modules Compile 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 ``` When `pkg-config` is not installed, the build also outputs the following log lines, however the build does not fail. ``` /bin/sh: 1: pkg-config: not found /bin/sh: 1: pkg-config: not found /bin/sh: 1: pkg-config: not found /bin/sh: 1: pkg-config: not found /bin/sh: 1: pkg-config: not found /bin/sh: 1: pkg-config: not found /bin/sh: 1: pkg-config: not found /bin/sh: 1: pkg-config: not found ``` ### Possible Solutions Some thoughts about options: 1. It looks like effort has been applied in other areas to support the absence of `pkg-config`, so potentially support libssl 1.1+ detection without `pkg-config`. 2. Require `pkg-config` on build and fail without it. 3. Enable `TLS_PTHREAD_MUTEX_SHARED` by default as I assume most people are running libssl 1.1+ these days, and disable it if libssl < 1.1 detected. Personally I have installed `pkg-config` and rebuilt, however I think for the safety of others building from source that the compile flag should be correctly set or the build should fail. ### Operating System ``` Distributor ID: Debian Description: Debian GNU/Linux 10 (buster) Release: 10 Codename: buster Linux debian-kamailio 4.19.0-20-amd64 #1 SMP Debian 4.19.235-1 (2022-03-17) x86_64 GNU/Linux ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3384 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3384(a)github.com>

3 weeks, 1 day

[kamailio/kamailio] htable dbmode 1 not insterting all records (Issue #3422)

by Julien Chavanton

### Description The dbmode behavior was modified (see the commit reference bellow) and does not clearly align with the documentation anymore, I still need the feature when we can persist htable records that were inserted at runtime. In fact I do not understand that value of writing back only records that where loaded from the DB, this seems equivalent to dbmode 0 (if the db is not altered) ? Maybe you can help me understand why we the change is needed @miconda ? ``` dbmode - if set to 1, the content of hash table is written to database table when the SIP server is stopped (i.e., ensure persistency over restarts). Default value is 0 (no write back to db table). ``` ``` commit b1fa63b1547fc5af6cc1e97db42ea76db1bf927b Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Wed Apr 13 13:11:30 2022 +0200 htable: track when records were successfully loaded from database - write back only in such case diff --git a/src/modules/htable/ht_api.c b/src/modules/htable/ht_api.c index 00023e7153..f212600e21 100644 --- a/src/modules/htable/ht_api.c +++ b/src/modules/htable/ht_api.c @@ -1099,7 +1099,7 @@ int ht_db_sync_tables(void) ht = _ht_root; while(ht) { - if(ht->dbtable.len>0 && ht->dbmode!=0 && ht->ncols==0) + if(ht->dbtable.len>0 && ht->dbmode!=0 && ht->dbload!=0 && ht->ncols==0) { LM_DBG("sync db table [%.*s] from ht [%.*s]\n", ht->dbtable.len, ht->dbtable.s, ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3422 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3422(a)github.com>

3 weeks, 2 days

[kamailio/kamailio] Topos: Added Call-ID mask support for Topos (PR #3347)

by Harish S

Added Call-ID mask Support for Topos with API call from Topoh to mask the callID Call-ID mask happens before the request is sent downstream and unmasked when received from downstream.   #### Pre-Submission Checklist    - [x] Commit message has the format required by CONTRIBUTING guide - [x] Commits are split per component (core, individual modules, libs, utils, ...) - [ ] Each component has a single commit (if not, squash them into one commit) - [ ] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated) #### Type Of Change - [ ] Small bug fix (non-breaking change which fixes an issue) - [ ] 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 - [ ] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description  You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3347 -- Commit Summary -- * Topos: Added Call ID mask when sending to Downstream * Topos: Added CallID Mask Document for Topos -- File Changes -- M src/modules/topos/doc/topos_admin.xml (20) M src/modules/topos/topos_mod.c (119) M src/modules/topos/tps_msg.c (37) M src/modules/topos/tps_msg.h (2) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3347.patch https://github.com/kamailio/kamailio/pull/3347.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3347 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3347(a)github.com>

3 weeks, 2 days

[kamailio/kamailio] lost: HELD request with broken sip uri (Issue #3426)

by sergey-safarov

### Description Kamailio sending HELD request with broken sip uri when the INVITE message contains a display name or display name with special character "&". ``` P-Asserted-Identity: "User &" <sip:+12001112233@206.147.236.78:5060> ``` or ``` P-Asserted-Identity: "User" <sip:+12001112233@206.147.236.78:5060> ``` For the first case, HELD request body looks like ```xml <?xml version="1.0" encoding="UTF-8"?> <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held" responseTime="5000"> <locationType exact="true">geodetic locationURI</locationType> <device xmlns="urn:ietf:params:xml:ns:geopriv:held:id"> <uri /> </device> </locationRequest> ``` Here `uri` element is empty. For the second case, HELD request body looks like (ident formatted) ``` <?xml version="1.0" encoding="UTF-8"?> <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held" responseTime="5000"> <locationType exact="true">geodetic locationURI</locationType> <device xmlns="urn:ietf:params:xml:ns:geopriv:held:id"> <uri>"User" <sip:+12001112233@206.147.236.78:5060></uri> </device> </locationRequest> ``` In [HELD schema](https://datatracker.ietf.org/doc/html/rfc6155#section-6) the 'uri' element specified as ``` <xs:element name="uri" type="xs:anyURI"/> ``` For me looks like here `display name` cannot be used. Moreover, if an inbound call does not contain `P-Asserted-Identity` header then `lost` properly extracts uri from the `From` header. For me look like need to improve `P-Asserted-Identity` parsing in the `lost` module and properly extract uri from header value. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3426 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3426(a)github.com>

4 weeks

[kamailio/kamailio] rtpengine: google sanitizer aligment warning (Issue #3058)

by sergey-safarov

``` bencode.c:149:14: runtime error: member access within misaligned address 0xffff9f18937f for type 'struct bencode_item_t', which requires 8 byte alignment 0xffff9f18937f: note: pointer points here 9f ff ff 00 00 14 00 00 00 00 00 00 00 98 1b 21 9f ff ff 00 00 f0 8b 9a fe ff ff 00 00 18 26 9c ^ bencode.c:50:64: runtime error: member access within misaligned address 0xffff9f18937f for type 'struct bencode_item_t', which requires 8 byte alignment 0xffff9f18937f: note: pointer points here 9f ff ff 00 00 14 00 00 00 00 00 00 00 98 1b 21 9f ff ff 00 00 f0 8b 9a fe ff ff 00 00 18 26 9c ^ bencode.c:50:54: runtime error: member access within misaligned address 0xffff9f18937f for type 'struct bencode_item_t', which requires 8 byte alignment 0xffff9f18937f: note: pointer points here 9f ff ff 00 00 14 00 00 00 00 00 00 00 98 1b 21 9f ff ff 00 00 f0 8b 9a fe ff ff 00 00 00 00 00 ^ bencode.c:50:48: runtime error: member access within misaligned address 0xffff9f18937f for type 'struct bencode_item_t', which requires 8 byte alignment 0xffff9f18937f: note: pointer points here 9f ff ff 00 00 14 00 00 00 00 00 00 00 98 1b 21 9f ff ff 00 00 f0 8b 9a fe ff ff 00 00 00 00 00 ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3058 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3058(a)github.com>

4 weeks, 1 day

Jump to page:

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev April 2023