[sr-dev] Re: RFC: move app_lua_sr to kamailio-archive
On Tue, 2024-03-26 at 12:19 +, Victor Seva via sr-dev wrote: > Hi, > > I would like to move app_lua_sr to kamailio-archive but I would like > to hear if anyone out there has a solid reason not to do it. I have a client who used app_lua_sr extensively. (Basically we did KEMI before KEMI was available.) The only place I can find it in current configs is an edge case with a single sqlops call. Specifically: loadmodule "app_lua_sr" modparam ( "app_lua_sr", "register", "sqlops") The initial conversion was "a thing", but was done years ago. This edge case was missed in the conversion. +1 to "archive" HTH Nathan ___ Kamailio (SER) - Development Mailing List To unsubscribe send an email to sr-dev-le...@lists.kamailio.org
[sr-dev] [kamailio/kamailio] sdp_remove_transport() corrupts SDP payload in conjunction with NAT-traversal rewriting using rtpproxy (Issue #3555)
### Description
I have some buggy devices that get upset by SRTP payloads in SDP that are
marked inactive. As a hack, I was attempting to delete them when going to
certain endpoints that are known to be problematic:
```
if (is_method("INVITE"))
sdp_remove_transport("RTP/SAVP");
```
### Troubleshooting
Per below, there is some garbage that looks like a port number inserted before
`m=audio` that seems to have come from rtpproxy rewriting for NAT traversal.
Removing the NAT traversal rewrite logic entirely fixes the problem, but also
makes NAT traversal not happen. Changing the order of `sdp_remove_transport()`
with respect to `rtpproxy_manage()` does not change anything.
Reproduction
This was seen with a Grandstream DP752 phone talking to SEMS, but applying the
code snippet above and getting a packet trace will be enough. The original SDP
had the RTP/SAVP transport first, followed by an RTP/AVP one. For the problem
to occur, NAT SDP rewriting has to occur using rtpproxy.
Debugging Data
Here is the payload after sfp_remove_transport() removed the RTP/SAVP section:
```
v=0
o=15176190619 8000 8000 IN IP4 X.X.X.X
s=SIP Call
c=IN IP4 X.X.X.X
t=0 0
46108m=audio 55082 RTP/AVP 125 9 0 8 2 18 97 101
a=sendrecv
a=rtpmap:125 opus/48000/2
a=fmtp:125 maxplaybackrate=16000
a=ptime:20
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16,32-36,54
a=nortpproxy:yes
```
There is a garbage 46108 (I think what would have been the port number for SAVP
data) at the beginning of the m=audio line. It seems that the rewrite by
rtpproxy is still inserting this port number even though the transport in
question has been removed.
Log Messages
None relevant.
SIP Traffic
(See above)
### Possible Solutions
None.
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
$ kamailio -v
version: kamailio 5.6.2 (x86_64/freebsd) 54a9c1
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, 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, select, kqueue.
id: 54a9c1
compiled on 10:44:33 Jul 20 2023 with cc FreeBSD clang version 13.0.0
(g...@github.com:llvm/llvm-project.git llvmorg-13.0.0-0-gd7b669b3a303)
```
* **Operating System**:
FreeBSD 13.2
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3555
You are receiving this because you are subscribed to this thread.
Message ID: ___
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-le...@lists.kamailio.org
[sr-dev] Re: Alpine packages
On Tue, 2023-04-18 at 17:16 +0200, Olle E. Johansson wrote: > Hi! > Sorry if I’ve brought this up before. Was looking at the package > definitions in our repo today and > did go through Alpine. It’s not following the template set by the > Debian packages, Correct. It tries to follow (as closely as possible) Makefile.groups Please see https://git.alpinelinux.org/aports/tree/main/kamailio/APKBUILD, lines 45-58) > it’s one huge package with all possible dependencies. ? It is one abuild that builds 44 sub packages: https://pkgs.alpinelinux.org/package/edge/main/x86_64/kamailio > > Since there’s a cost and a risk with adding dependencies and very few > Kamailio installs > use all modules this doesn’t look good to me. Alpine tries to follow Makefile.groups which honestly doesn't make sense to me either. > > I personally don’t know the details of Alpine packaging, but can help > trying to define > a set of packages like in Debian and test them in Alpine. See above. > > It would be good for the project overall if we can fix this. Ok. I'm listed as the package manager. > > Btw, the same goes for the docker image that is built with scripts in > the packaging > repository. Being able to minimise the build would be a good thing. > Out of my scope. The docker images people do crazy things. :) > Kamailio greetings! > /O Kamailio is a Hawaiian word for to "talk, converse" - Yeah, let's talk, my friend. ___ Kamailio (SER) - Development Mailing List To unsubscribe send an email to sr-dev-le...@lists.kamailio.org
[sr-dev] [kamailio/kamailio] Confusing wss transport with ws transport while forwarding sip messages (Issue #3340)
### Description
For secure websocket connections (wss), Kamailio seems to forget that the
connection is secure, later trying to use a regular TCP `listen` option to send
out messags.
I'd be happy to propose a patch, but I'm not sure what the expected behavior of
Kamailio would be here.
Setup:
- One Kamailio acting as websocket endpoint with TLS configured, forwarding all
packets via udp to another kamailio
- Another Kamailio handling all dialplan logic, including registers/invites
We have traced the issue:
- Client sends a `REGISTER` over secure websockets
- Kamailio1 forwards this to Kamailio 2, with `Path:
`
- Kamailio 2 stores the AOR in database using `registrar.store`
- In the location table, we can see `received =
sip:1.1.1.1:1;transport=ws`
- We try to send a SIP INVITE to the WebRTC client
- Kamailio 2 creates invite, adds header `Route: ` with option `transport=ws`
- INVITE arrives at Kamailio 1, which forwards it to the client using
`t_relay`
- Kamailio 1 ends up in `get_send_socket2`, with parameter `proto = ws`
- Following the source code, we end up
[here](https://github.com/kamailio/kamailio/blob/master/src/core/forward.c#L286),
this will end up picking `sendipv4_tcp` as `send_sock`
- This picks a *TCP* listener, while in fact we need a *TLS* listener
- As a result, the outgoing message contains a wrong endpoint in the
`Record-Route` header, causing issues in the SIP dialog later on
### Troubleshooting
Reproduction
Reproducing from scratch requires quite some setup, hopefully the above
information will be enough to diagnose.
Debugging Data
See above.
Log Messages
See above.
SIP Traffic
See above, can provide exact SIP traces if required.
### Possible Solutions
We have been able to work around the issue like this:
```
if (pcre_match("$(hdr(Route)[0]{nameaddr.uri}{uri.param,received})",
"%3Btransport%3Dws")) {
# Kamailio bug?
# in the received parameter of the route header, there is ';transport=ws'
# so kamailio starts looking for a *tcp* connection, while it should be
looking for a *tls*
# connection.
xlog("L_NOTICE", "Websocket detected; forcing wss transport");
set_send_socket("tls:WEBSOCKET_IP:WEBSOCKET_PORT");
}
```
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
Tested with 5.4.4, but code doesn't seem to be changed in master.
* **Operating System**:
Ubuntu Focal.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3340
You are receiving this because you are subscribed to this thread.
Message ID: ___
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-le...@lists.kamailio.org
[sr-dev] Re: DMQ Trials
On Fri, 2022-12-30 at 14:26 +0100, Olle E. Johansson wrote: > Dear Kamailians! > > I’m trying to figure out DMQ and see how it reacts to server outages > and downtime - the base protocol. > Same here. The best I could figure is "it works when it works, until it doesn't" In our tests, the "edge cases" got weird. Anyone who wants to explain how DMQ works in failure scenarios - there are two of us who are interested! ___ Kamailio (SER) - Development Mailing List To unsubscribe send an email to sr-dev-le...@lists.kamailio.org
Re: [sr-dev] [kamailio/kamailio] pua_dialoginfo publishing confirmed for an early call (#2700)
Closed #2700. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2700#event-4574867789___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] [kamailio/kamailio] pua_dialoginfo publishing confirmed for an early call (#2700)
Yes, I can confirm this patch fixes our problem. Thanks! -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2700#issuecomment-816735849___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] [kamailio/kamailio] pua_dialoginfo publishing confirmed for an early call (#2700)
### Description When updating from Kamailio 5.2.2 to 5.4.4, we're encountering an issue: the pua_dialoginfo module publishes a `confirmed` state for the dialog, even though it's still ringing. It turns out this commit introduces the problem since 5.3.0: 4efe19f So since 5.3.0, the dialog module (i think correctly?) sends out state updates for PRACK dialog updates as `DLGCB_REQ_WITHIN` events. But the `pua_dialoginfo` module seems to see that as a signal to mark the dialog confirmed (see [here](https://github.com/kamailio/kamailio/blob/master/src/modules/pua_dialoginfo/pua_dialoginfo.c#L311)). One easy fix would be to simply remove `DLGCB__REQ_WITHIN` from the case list in pua_dialoginfo? OpenSER [seems to](https://github.com/OpenSIPS/opensips/blob/master/modules/pua_dialoginfo/pua_dialoginfo.c#L353) ditch the `DLGCB_REQ_WITHIN` messages altogether, for specific messages... ### Troubleshooting Reproduction - Use the pua_dialoginfo module - Make sure your device uses PRACK - See that the dialog is confirmed even before you pick up; watch for log lines: `__dialog_sendpublish(): dialog confirmed` Debugging Data N/A Log Messages With 5.4.4: ``` 2021-04-02T16:49:44.453339+02:00 debug proxy[17964]: DEBUG: pua_dialoginfo [pua_dialoginfo.c:295]: __dialog_sendpublish(): dialog confirmed, from=sip:220@188.166.42.37 ``` SIP Traffic Just a regular invite with prack. ### Possible Solutions See above. ### Additional Information Reproduced with Kamailio 5.4.4, but probably all versions from 5.3.0 are affected. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2700___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] [kamailio/kamailio] Fix ip parsing in ipops (#2695)
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 - [x] Related to issue #2645 Description For #2645, a patch was pushed in 47b45b60a037808a675f7d52dd5b2ee80bfe0868, but this code does not correctly check the return value of `str2ip6buf` and `str2ipbuf`. As described in the comments on both methods, they return zero *for success*. This MR should be backported to 5.4 as well. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/2695 -- Commit Summary -- * Fix ip parsing in ipops -- File Changes -- M src/modules/ipops/ipops_mod.c (4) -- Patch Links -- https://github.com/kamailio/kamailio/pull/2695.patch https://github.com/kamailio/kamailio/pull/2695.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/2695 ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] [kamailio/kamailio] dns_int_match_ip is broken (#2645)
### Description
`dns_int_match_ip` is broken on 5.3.0 and above
### Troubleshooting
Reproduction
Try this dialplan:
```
if (dns_int_match_ip('dns.google', '8.8.8.8')) {
xlog("L_INFO", "OK dns-ip match with dns_int_match_ip");
} else {
xlog("L_ERR", "FAIL dns-ip match with dns_int_match_ip");
}
if (dns_int_match_ip('100.100.100.100', '8.8.8.8')) {
xlog("L_ERR", "FAIL dns_int_match_ip on 2 ip's");
} else {
xlog("L_INFO", "OK dns_int_match_ip on 2 ip's");
}
```
On 5.2 releases, both checks succeed. On 5.3 and up, both fail.
Debugging Data
I've traced down the problem to `str2ip`.
In 5.2, this is a `static inline` function defined in the header file
`resolve.h`. Therefore, the returned `ip` structure is allocated *once per
compilation unit* - ie. `ipops_mod.c` and `dns_cache.c` both have their own
versions of the variable.
Since fb75e90549a (5.3 and up) this function is defined in it's own compilation
unit (`resolve.c`) and therefore shared by all callers.
See:
https://stackoverflow.com/questions/185624/static-variables-in-an-inlined-function
Log Messages
n/a
SIP Traffic
n/a
### Possible Solutions
- Have `ki_dns_sys_match_ip` make a local copy of the return value of `str2ip`
- Move `str2ip` back to a header file
- Refactor `str2ip` to take a pointer to an output struct
### Additional Information
In 5.3, this is what happens:
```
# - ki_dns_int_match_ip will call str2ip on 8.8.8.8, filling the static variable
# - resolvehost will call dns_a_get_he, which calls str2ip on dns.google.com,
zeroing out the static variable
# - (dns_cache_do_request will call str2ip on dns.google.com, zeroing out the
static variable again)
# - resolvehost queries DNS
# - the resolved IP's will be compared to the zero'd out struct
dns_int_match_ip('dns.google', '8.8.8.8') == false
# - ki_dns_int_match_ip will call str2ip on 8.8.8.8, filling the static variable
# - resolvehost will call dns_a_get_he, which calls str2ip on 100.100.100.100,
overwriting the static variable
# - the static variable will be compared to itself
dns_int_match_ip('100.100.100.100', '8.8.8.8') == true
```
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2645___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] [kamailio/kamailio] Segfault in openssl on Xenial (#2274)
To be honest, I rather stay with the upstream Kamailio from Xenial and accept this bug for now. The burden of having to maintain a custom Kamailio build and package does not outweigh the complications caused by this issue, in our case. I can understand that fixing Xenial bugs are not your priority... if there's no plan to fix this in Kamailio, we should just close this with "won't fix". -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2274#issuecomment-634699145___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] [kamailio/kamailio] Segfault in openssl on Xenial (#2274)
We settled on accepting this as known issue for now. We just don't ds-reload this instance... Updating to a non-Xenial libmysqlclient or libssl feels like it could introduce a whole range of new problems (also outside of Kamailio). -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2274#issuecomment-633476740___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] [kamailio/kamailio] Segfault in openssl on Xenial (#2274)
Yes, same story here. Using 'localhost' for DB connection URL solves the problem. But we can't use this for our production scenario, as our DB is not on localhost... -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2274#issuecomment-628140579___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] [kamailio/kamailio] Crashes on handling of BYE with 5.3.0 (#2121)
I finally isolated the problem here. I was trying to deal with some NAT
nonsense involving dropped Contact headers from my SIP trunk provider and had a
block like this in the WITHINDLG route:
```
if (uri==myself && $ru=~";alias=10") {
# Deal with BS on ACKs
handle_ruri_alias();
if($du != $null) {
$ru = $du;
}
}
```
The crash was happening in here. I've since switched to a different method of
dealing with this and the problem has gone away.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2121#issuecomment-624333026___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] [kamailio/kamailio] Segfault in openssl on Xenial (#2274)
Hi, I'm attaching a zip containing all files needed for repro. Just use `start.sh` and it should reproduce the segfault. [kam-2274.zip](https://github.com/kamailio/kamailio/files/4558686/kam-2274.zip) -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2274#issuecomment-621864541___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] [kamailio/kamailio] Segfault in openssl on Xenial (#2274)
Yes, I was adding that to test for repro on Ubuntu Bionic. It's not needed for Xenial. When removed, we still have the same segfault. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2274#issuecomment-613443545___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] [kamailio/kamailio] Segfault in openssl on Xenial (#2274)
Attached is the debug log from Kamailio: [xenial-debug3.log](https://github.com/kamailio/kamailio/files/4472261/xenial-debug3.log) I have a docker-based reproduction for various OS versions, if you want to test. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2274#issuecomment-613137053___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] [kamailio/kamailio] Segfault in openssl on Xenial (#2274)
Kamailio version (latest stable xenial version from kamailio repo):
```
version: kamailio 5.3.3 (x86_64/linux)
flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE,
USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, 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_BLACKLIST, 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: unknown
compiled with gcc 5.3.1
```
GDB output:
```
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x in ?? ()
(gdb) bt full
#0 0x in ?? ()
No symbol table info available.
#1 0x7fe9a1931b0d in getrn (lh=lh@entry=0x7fe9a2e167e8,
data=data@entry=0x7ffebc880c70, rhash=rhash@entry=0x7ffebc880c10) at lhash.c:396
ret =
n1 =
hash =
nn =
cf =
#2 0x7fe9a193217a in lh_retrieve (lh=0x7fe9a2e167e8,
data=data@entry=0x7ffebc880c70) at lhash.c:248
hash = 8298067
rn =
ret =
#3 0x7fe9a1934651 in int_thread_get_item (d=0x7ffebc880c70) at err.c:500
p =
hash = 0x7fe9a2e167e8
#4 0x7fe9a1935024 in ERR_get_state () at err.c:1023
fallback = {tid = {ptr = 0x0, val = 0}, err_flags = {0 }, err_buffer = {0 }, err_data = {0x0 }, err_data_flags = {0 },
err_file = {0x0 }, err_line = {0 }, top = 0, bottom = 0}
ret =
tmp = {tid = {ptr = 0x0, val = 140642013755136}, err_flags = {511, 316,
-1619302300, 32745, -1552805456, 32745, -1565683712, 32745, -2091823603,
-883404243, 234052522, 1484894954, -2091823603,
-883404243, 234052522, 1484894954}, err_buffer = {140641446269360,
140641433391104, 17179869256, 120267519968, 140641446272144, 140641433394304,
140732061453760, 6966688,
17774295194511430037, 16205183325810705970, 140641379772512,
1358401357362, 140641379784296, 140641379772516, 140641446269416,
140641433391104}, err_data = {
0x82c76a98fc8c8c89 , 0x5ce09cb9d15aa665 ,
0x82c76a98fc8c8c89 , 0x5ce09cb9d15aa665 ,
0x1 , 0x7fe9a37211b0
, 0xe0 ,
0x7fe9a2ad9000 "",
0x1a3721130 ,
0x7fe9a2b126c8 "", 0x7ffebc880dc0 "",
0x69fcd8
"\211E\374\203}\374\002\017\224\300\017\266\300H\205\300t6H\213E\350H\203\354\bj",
0x48 , 0x7fe9a2b126c8 "",
0x8 , 0x10049
}, err_data_flags =
{-1131934208, 32766, 7001680, 0, -1619302304, 32745,
-1573631521, 32745, -1619290520, 32745, -1619302300, 32745,
-1552805400, 32745, -1565683712, 32745}, err_file = {0x7ffebc880e20
"\300\016\210\274\376\177",
0x7fe99f76cc19
"\220\311\303UH\211\345AWAVAUATSH\203\354\070H\211}\270H\213E\270H\211\307\350Ӳ\376\377\211Eȃ",
, 0x7ffebc880e80 "",
0x49ea76c4c1721d00 , 0x7ffebc880ec0 "\262\367\217\070\271\235;\245",
0x7ffebc880e80 "",
0x48 ,
0x7fe9a1c58660
"i\t\264F\340\372ﳫc\266\001\375\230Q\234M\263\037\344=M%\310a\274\234\177.Q\364%\224|K\334\062\233\374\065k,\215\362\064\231\277PҒ\035\332\333\363\320MɌ\202\372\346\366\t\206\064B\370X\362B\355\366u\334\341\342S\275\063\236\213\255*ű\327\347\005\214\221\016\001'@\003<\361\257Lf\300\346x1\227\315\344hF\236\020\065>'~5\314s\327\313{\206\307\343\016\034\226\223\354\063\357\v\226Y\241\203\333\032\231\345P\f\017'y\313ytѽ\201i\376k\242\240\317\bz^\344\062k\202Y\320Q\213^J\033g\256\377Y\316\034+\321\375\341\211>\\\205;\253\325\313:^\377\350\366ܻ\001"...,
0x7ffebc880ec0 "\262\367\217\070\271\235;\245", 0x7fe9a1932c0c
"H\213\204$\210", 0x14bc880ec0 , 0x7ffebc880f28 "",
0x8 , 0x7ffebc880eb0
"\276\002", 0x8 , 0x0}, err_line =
{0 , 702, 0, 61, 0},
top = 948959154, bottom = -1522819655}
tmpp = 0x0
i =
tid = {ptr = 0x0, val = 140642013755136}
#5 0x7fe9a193525f in ERR_clear_error () at err.c:743
i =
es =
#6 0x7fe9a1c8667e in ssl23_accept (s=0x7fe9a36532d0) at s23_srvr.c:157
buf =
Time = 1586173596
cb = 0x0
ret = -1
new_state =
state =
#7 0x7fe99f792bd4 in tls_accept (c=0x7fe9a3723810, error=0x7ffebc881050)
at tls_server.c:422
ret = -1131933680
ssl = 0x7fe9a36532d0
cert = 0x7fe9a3720e58
tls_c = 0x7fe9a355a0d0
tls_log = -1619452682
__func__ = "tls_accept"
pkey = 0x0
#8 0x7fe99f79c2d4 in tls_read_f (c=0x7fe9a3723810, flags=0x7ffebc8a13fc)
at tls_server.c:1116
r = 0x7fe9a3723890
bytes_free = 16383
bytes_read = 305
read_size = 16383
ssl_error = 0
ssl_read = 0
ssl = 0x7fe9a36532d0
rd_buf =
Re: [sr-dev] [kamailio/kamailio] Segfault in openssl on Xenial (#2274)
[kamailio.cfg.example.txt](https://github.com/kamailio/kamailio/files/4435235/kamailio.cfg.example.txt) -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2274#issuecomment-609501792___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] [kamailio/kamailio] Segfault in openssl on Xenial (#2274)
### Description Segfault in Kamailio when using mysql (over ssl) and tls listeners. We have a reproducible segfault with Kamailio on Ubuntu Xenial. The problems is revealed when two modules (db_mysql and tls) and both using the openssl library. The mysql module is using openssl indirectly, because the connection is encrypted by default when the server supports it. ### Troubleshooting Reproduction Install Kamailio with - tls listeners enabled - dispatcher module enabled, from mysql db Example configuration attached: In this case, reproduction with: - start kamailio - let dispatcher reload, for example via jsonrpc - make connection on tls, for example with `openssl s_connect` Kamailio will crash. Debugging Data Stack trace, with `libssl1.0.0-dbg` installed: ``` #0 0x in ?? () #1 0x7ff862d07b0d in getrn (lh=lh@entry=0x7ff8641eb7e8, data=data@entry=0x7ffe1f36e750, rhash=rhash@entry=0x7ffe1f36e6f0) at lhash.c:396 #2 0x7ff862d0817a in lh_retrieve (lh=0x7ff8641eb7e8, data=data@entry=0x7ffe1f36e750) at lhash.c:248 #3 0x7ff862d0a651 in int_thread_get_item (d=0x7ffe1f36e750) at err.c:500 #4 0x7ff862d0b024 in ERR_get_state () at err.c:1023 #5 0x7ff862d0b25f in ERR_clear_error () at err.c:743 #6 0x7ff86305c67e in ssl23_accept (s=0x7ff864a282d0) at s23_srvr.c:157 #7 0x7ff860b70d86 in tls_accept (c=0x7ff864af8810, error=0x7ffe1f36eb30) at tls_server.c:422 #8 0x7ff860b7a486 in tls_read_f (c=0x7ff864af8810, flags=0x7ffe1f38eedc) at tls_server.c:1116 #9 0x00625ac2 in tcp_read_headers (c=0x7ff864af8810, read_flags=0x7ffe1f38eedc) at core/tcp_read.c:469 #10 0x0062d05d in tcp_read_req (con=0x7ff864af8810, bytes_read=0x7ffe1f38eed8, read_flags=0x7ffe1f38eedc) at core/tcp_read.c:1496 #11 0x00631c42 in handle_io (fm=0x7ff885734520, events=1, idx=-1) at core/tcp_read.c:1804 #12 0x00620500 in io_wait_loop_epoll (h=0xae0200 , t=2, repeat=0) at core/io_wait.h:1065 #13 0x00633adb in tcp_receive_loop (unix_sock=26) at core/tcp_read.c:1974 #14 0x0051a9a1 in tcp_init_children () at core/tcp_main.c:4853 #15 0x0042620e in main_loop () at main.c:1745 #16 0x0042ca76 in main (argc=7, argv=0x7ffe1f38f578) at main.c:2696 ``` Log Messages ``` 2020-04-05T01:27:37.965778+02:00 nathancmp01 kernel: [432825.787355] kamailio[6296]: segfault at 0 ip (null) sp 7ffe4cdaf248 error 14 in kamailio[40+47b000] ``` SIP Traffic No SIP traffic needed, just a TLS connection. ### Possible Solutions Could not reproduce with Kamailio 5.3.3 on Ubuntu Bionic nor Debian Buster. Both are using openssl 1.1.x, so I guess that fixes the problem. But Xenial is still on 1.0.2g... ### Additional Information Tested with Kamailio 5.2 and 5.3.3. * **Operating System**: Repro on: - Ubuntu Xenial No repro on: - Ubuntu Bionic - Debian Buster -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2274___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] [kamailio/kamailio] Fix returning multiple IP's for a cached DNS entry (#2260)
!-- 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 youre unsure about any of these, dont 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 # (replace with an open issue number) Description The method `dns_entry2he` was returning 10 `hostent` structures, containing the same record, because the rr counter was never updated (10 being the value of `DNS_HE_MAX_ADDR`). With this fix, the cache correctly returns all records found by the resolver. In the documentation of `dns_int_match_ip`, it says: At this moment, the function might not check all the IP addresses as returned by dns_sys_match_ip(), because the internal resolver targets to discover the first address to be used for relaying SIP traffic. I believe that with this patch, `dns_int_match_ip` now also works for DNS entries with multiple values. Im not sure about mixed ipv4/ipv6 though. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/2260 -- Commit Summary -- * Fix returning multiple IPs for a cached DNS entry -- File Changes -- M src/core/dns_cache.c (1) -- Patch Links -- https://github.com/kamailio/kamailio/pull/2260.patch https://github.com/kamailio/kamailio/pull/2260.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/2260 ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] [kamailio/kamailio] Crashes on handling of BYE with 5.3.0 (#2121)
This is still present with 5.3.1, at least. I missed your last comment earlier, but will have a go at it soon. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2121#issuecomment-566379619___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] [kamailio/kamailio] Crashes on handling of BYE with 5.3.0 (#2121)
Here you are, apologies for the delay:
```
(gdb) p *( (struct qm_frag*) ( ((char*)(0x801544380)-sizeof(struct
qm_frag_end)) - ((struct qm_frag_end*)((char*)(0x801544380)-sizeof(struct
qm_frag_end)))->size - sizeof(struct qm_frag) ) )
$1 = {size = 32, u = {nxt_free = 0x0 , is_free = 0},
file = 0x208a40 "core: core/parser/msg_parser.c", func = 0x2059c3
"set_dst_uri",
mname = 0x2067f2 "core", line = 752, check = 4042322160}
```
I've had several more samples of this crash in the last few days, all in the
same place, so it doesn't appear to be random. Please let me know if there is
anything else I can provide -- I'll have to roll back to 5.2.4 soon.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2121#issuecomment-552700932___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] [kamailio/kamailio] Crashes on handling of BYE with 5.3.0 (#2121)
Here is the actual backtrace, after ~ half a week this time:
```
(lldb) bt
* thread #1, name = 'kamailio', stop reason = signal SIGABRT
* frame #0: 0x000800a8645a libc.so.7`_thr_kill + 10
frame #1: 0x000800a84844 libc.so.7`_raise + 52
frame #2: 0x0008009f7079 libc.so.7`abort + 73
frame #3: 0x00706ffe kamailio`___lldb_unnamed_symbol817$$kamailio +
5934
frame #4: 0x00708b32 kamailio`qm_free + 6418
frame #5: 0x005ab45c kamailio`do_action + 38716
frame #6: 0x000801ea45a9 pv.so`pv_set_ruri + 2777
frame #7: 0x0057e80c kamailio`___lldb_unnamed_symbol454$$kamailio +
6172
frame #8: 0x0057ae98 kamailio`lval_assign + 3176
frame #9: 0x005bf4e6 kamailio`do_action + 120774
frame #10: 0x005c278d kamailio`run_actions + 3245
frame #11: 0x005af198 kamailio`do_action + 54392
frame #12: 0x005c278d kamailio`run_actions + 3245
frame #13: 0x005af198 kamailio`do_action + 54392
frame #14: 0x005c278d kamailio`run_actions + 3245
frame #15: 0x005a9823 kamailio`do_action + 31491
frame #16: 0x005c278d kamailio`run_actions + 3245
frame #17: 0x005c3493 kamailio`run_top_route + 179
frame #18: 0x0036553c kamailio`receive_msg + 24332
frame #19: 0x0064b938 kamailio`receive_tcp_msg + 312
frame #20: 0x0065132c kamailio`tcp_read_req + 13740
frame #21: 0x00664971 kamailio`___lldb_unnamed_symbol650$$kamailio
+ 10817
frame #22: 0x0065e671 kamailio`___lldb_unnamed_symbol637$$kamailio
+ 4561
frame #23: 0x00657954 kamailio`tcp_receive_loop + 1556
frame #24: 0x004b9fed kamailio`tcp_init_children + 3805
frame #25: 0x002fa5df kamailio`main_loop + 35311
frame #26: 0x00307d2b kamailio`main + 50267
frame #27: 0x002e311b kamailio`_start + 283
```
This time the crash happened on ACK, rather than BYE:
```
Nov 5 19:13:03 home /usr/local/sbin/kamailio[16259]: CRITICAL: {1 952554 ACK !!
:R7p-RGMbyGRCR9j0aFpFaFhbakp0yAK0yAKYR7pVRcNL} [core/mem/q_malloc.c:149]:
qm_debug_check_frag(): BUG: qm: prev. fragm. tail overwritten(c0c0c000,
abcdefed)[0x801544380:0x8015443b8]! Memory allocator was called from core:
core/action.c:754. Fragment marked by core: core/dset.c:733. Exec from
core/mem/q_malloc.c:504.
Nov 5 19:14:56 home /usr/local/sbin/kamailio[16260]: CRITICAL:
[core/pass_fd.c:277]: receive_fd(): EOF on 22
Nov 5 19:14:56 home kernel: pid 16259 (kamailio), uid 0: exited on signal 6
(core dumped)
```
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2121#issuecomment-550129626___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] [kamailio/kamailio] Crashes on handling of BYE with 5.3.0 (#2121)
I agree that it is probably not TLS related, but it was all I had. I'll wait for a better core, will probably have one in ~ a week again; on FreeBSD, this is the relevant setting in case it comes up again: ``` sysctl kern.corefile='%N.%P.core' ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2121#issuecomment-549062943___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] [kamailio/kamailio] Continued OpenSSL 1.1 crashes with 5.3.0 (#2121)
### Description
After upgrading to 5.3.0 from 5.2.2 (standard packages on FreeBSD 12.0), I am
experiencing intermittent crashes related to handling of BYE messages.
### Troubleshooting
Reproduction
This happens ~ weekly and I have not found a good way to reproduce it.
Debugging Data
An example backtrace is below from the last dumped core (the SIGSEGV one);
unfortunately it overwrote the earlier one:
```
* thread #1, name = 'kamailio', stop reason = signal SIGSEGV
* frame #0: 0x0008009c5b79 libc.so.7`___lldb_unnamed_symbol403$$libc.so.7
+ 41
frame #1: 0x0008009ed63e libc.so.7`__free + 990
frame #2: 0x00080271562b libthr.so.3`pthread_rwlock_destroy + 59
frame #3: 0x000802bedbf6 libcrypto.so.111`CRYPTO_THREAD_lock_free + 22
frame #4: 0x000802aef3c4 libcrypto.so.111`RSA_free + 100
frame #5: 0x000802b10c32 libcrypto.so.111`EVP_PKEY_free + 66
frame #6: 0x00080296ed86
libssl.so.111`___lldb_unnamed_symbol646$$libssl.so.111 + 134
frame #7: 0x00080295f93c libssl.so.111`SSL_CTX_free + 236
frame #8: 0x0008028aee42 tls.so`tls_free_domain + 114
frame #9: 0x0008028af1d7 tls.so`tls_free_cfg + 199
frame #10: 0x0008028af2df tls.so`tls_destroy_cfg + 191
frame #11: 0x0008028ad1f1 tls.so`destroy_tls_h + 1185
frame #12: 0x0041adea kamailio`destroy_tls + 26
frame #13: 0x002e36fd kamailio`cleanup + 269
frame #14: 0x002eb5b7 kamailio`___lldb_unnamed_symbol5$$kamailio +
1351
frame #15: 0x002ea5e5 kamailio`handle_sigs + 21669
frame #16: 0x002fb83e kamailio`main_loop + 40014
frame #17: 0x00307d2b kamailio`main + 50267
frame #18: 0x002e311b kamailio`_start + 283
```
This is with OpenSSL 1.1 With the LD_PRELOAD hack to 5.2.2, things were
completely stable; I am trying to use kamailio without the LD_PRELOAD'ed mutex
wrapper now, which I believe is no longer required. It looks like the
SSL-related stuff in the TLS crash (which was 5 minutes later!) is unrelated to
the initial problem and may just be an artifact of one of the kamailio
processes crashing earlier.
Log Messages
```
Nov 2 08:11:31 home /usr/local/sbin/kamailio[94702]: CRITICAL: {1 527440 BYE
973470944-5061-16392@BA.A.B.I} [core/mem/q_malloc.c:149]:
qm_debug_check_frag(): BUG: qm: prev. fragm. tail overwritten(c0c0c000,
abcdefed)[0x801544c58:0x801544c90]! Memory allocator was called from core:
core/action.c:754. Fragment marked by core: core/dset.c:733. Exec from
core/mem/q_malloc.c:504.
Nov 2 08:13:41 home /usr/local/sbin/kamailio[94703]: CRITICAL:
[core/pass_fd.c:277]: receive_fd(): EOF on 22
Nov 2 08:13:41 home kernel: pid 94702 (kamailio), uid 0: exited on signal 6
(core dumped)
Nov 2 08:13:41 home /usr/local/sbin/kamailio[94692]: ALERT:
[main.c:767]: handle_sigs(): child process 94702 exited by a signal 6
Nov 2 08:13:41 home /usr/local/sbin/kamailio[94692]: ALERT:
[main.c:770]: handle_sigs(): core was generated
Nov 2 08:14:56 home login[8284]: ROOT LOGIN (root) ON ttyu0
Nov 2 08:16:26 home kernel: pid 94692 (kamailio), uid 0: exited on signal 11
(core dumped)
```
I had an identical problem a week ago, also with a crash on a BYE for an active
call:
```
Oct 27 13:00:02 home /usr/local/sbin/kamailio[79819]: CRITICAL: {1 598425 BYE
649761149-5061-291@BA.A.B.I} [core/mem/q_malloc.c:149]:
qm_debug_check_frag(): BUG: qm: prev. fragm. tail overwritten(c0c0c000,
abcdefed)[0x801551808:0x801551840]! Memory allocator was called from core:
core/action.c:754. Fragment marked by core: core/dset.c:733. Exec from
core/mem/q_malloc.c:504.
Oct 27 13:02:09 home /usr/local/sbin/kamailio[79820]: CRITICAL:
[core/pass_fd.c:277]: receive_fd(): EOF on 22
Oct 27 13:02:09 home kernel: pid 79819 (kamailio), uid 0: exited on signal 6
(core dumped)
Oct 27 13:02:09 home /usr/local/sbin/kamailio[79809]: ALERT:
[main.c:767]: handle_sigs(): child process 79819 exited by a signal 6
Oct 27 13:02:09 home /usr/local/sbin/kamailio[79809]: ALERT:
[main.c:770]: handle_sigs(): core was generated
Oct 27 13:04:55 home kernel: pid 79809 (kamailio), uid 0: exited on signal 11
(core dumped)
```
### Possible Solutions
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
version: kamailio 5.3.0 (x86_64/freebsd) 4cc67a
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, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER,
USE_NAPTR, USE_DST_BLACKLIST, 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, select, kqueue.
id: 4cc67a
compiled on 18:51:34 Oct 25 2019 with cc 6.0
```
* **Operating System**:
FreeBSD 12.0
```
FreeBSD home.XXX 12.0-RELEASE-p10 FreeBSD 12.0-RELEASE-p10 GENERIC amd64
```
--
You are
Re: [sr-dev] [kamailio/kamailio] Kamailio 5.2.2 - Segmentation fault in libcrypto.so.1.1 (#1860)
I'm also having trouble with kamailio and OpenSSL 1.1, with segfaults in TLS. It's not quite the same issue as described here, but I suspect might be related: * thread #1, name = 'kamailio', stop reason = signal SIGSEGV * frame #0: 0x0008009c954d libc.so.7`__free + 749 frame #1: 0x0008026c262b libthr.so.3`pthread_rwlock_destroy + 59 frame #2: 0x000802b8abf6 libcrypto.so.111`CRYPTO_THREAD_lock_free + 22 frame #3: 0x000802b784c6 libcrypto.so.111`BIO_free + 182 frame #4: 0x0008028fb1a1 libssl.so.111`SSL_free + 193 frame #5: 0x000802810d48 tls.so`tls_h_tcpconn_clean + 1240 I haven't tried with OpenSSL 1.0 yet. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/1860#issuecomment-485191734___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] [kamailio/kamailio] cannot build 5.1 branch on Alpine (#1509)
Sergey, I'm the maintainer of the Alpine Linux Kamailio package. The TLS module has never worked with Kamailio because of the use of LibreSSL. Even after we got the patches to compile, the TLS module didn't actually work. So we pulled the patches and disabled the module entirely. We are waiting for Alpine Linux to switch back to OpenSSL, and then will renable the module. Last I was informed, that will be the 3.8 or 3.9 release. HTH ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
