[sr-dev] Re: [kamailio/kamailio] crypto related crash in 5.8.2 (Issue #3885)

[Sebastian Damm via sr-dev]

Closed #3885 as completed.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3885#event-13281590019
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: [kamailio/kamailio] crypto related crash in 5.8.2 (Issue #3885)

[Sebastian Damm via sr-dev]

Looks like `tls_threads_mode = 2` solved the issue. Has been running for more 
than 4 days now.

BTW: We found out that the crash could actually be triggered by running `nmap 
--script ssl-enum-ciphers -p 5061 example.com`, too. After some requests, 
Kamailio crashed and nmap returned with an incomplete number of ciphers.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3885#issuecomment-2188994027
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: [kamailio/kamailio] crypto related crash in 5.8.2 (Issue #3885)

[Sebastian Damm via sr-dev]

Thanks Henning, we'll try.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3885#issuecomment-2180606968
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: [kamailio/kamailio] crypto related crash in 5.8.2 (Issue #3885)

[Sebastian Damm via sr-dev]

It's unconfigured. And I couldn't find any documentation for it except in the 
sample kamailio.cfg file. So I don't know what the default is.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3885#issuecomment-2180449543
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] [kamailio/kamailio] crypto related crash in 5.8.2 (Issue #3885)

[Sebastian Damm via sr-dev]

### Description

We updated one of our endpoint facing proxies last night, from 5.7.4 to 5.8.2. 
After running for about 12 hours, it crashed. It had about 1.8k TLS connections 
at the time of the crash.

When crashing, Kamailio produced core dumps of two processes. One of them must 
be the TCP listener, the other maybe the main process.



 Debugging Data



TCP worker BT:
```
GNU gdb (Ubuntu 12.1-0ubuntu1~22.04.2) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
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-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/sbin/kamailio...
Reading symbols from 
/usr/lib/debug/.build-id/f7/ddc0031f334263ca08ef340ce76dcf36c43616.debug...
[New LWP 170]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/sbin/kamailio -P /var/run/kamailio/kamailio.pid -f 
/etc/kamailio/kamailio.'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  EVP_MD_get_size (md=0x4434443332454246) at ../crypto/evp/evp_lib.c:790
(gdb) bt full
#0  EVP_MD_get_size (md=0x4434443332454246) at ../crypto/evp/evp_lib.c:790
__func__ = "EVP_MD_get_size"
#1  0x7f6fdae8dac9 in ssl3_get_record (s=0x7f6f7b56b940) at 
../ssl/record/ssl3_record.c:532
tmpmd = 
rbuf = 0x7f6f7b56c5b8
p = 
md = "\004Б\220WU\000\000h\023\226\220WU\000\000\001", '\000' , 
"\240\331\356\332o\177\000\000\000@\233\363\377\177\000\000\340?\233\363\377\177\000"
sslv2pkt = 
rret = 
more = 
imac_size = 
num_recs = 1
enc_err = 
is_ktls_left = 0
i = 
n = 1220
rr = 0x7f6f7b56cbe8
version = 
pkt = 
ret = -1
thisrr = 0x7f6f7b56cbe8
sess = 0x7f6f83f15360
mac_size = 0
max_recs = 1
j = 
macbufs = 0x0
end = 
enc_err = 
rret = 
i = 
more = 
n = 
rr = 
thisrr = 
rbuf = 
sess = 
p = 
md = 
version = 
mac_size = 
imac_size = 
num_recs = 
max_recs = 
j = 
pkt = 
sslv2pkt = 
is_ktls_left = 
macbufs = 
ret = 
__func__ = 
skip_decryption = 
end = 
sslv2len = 
type = 
len = 
tmpmd = 
mac = 
trc_out = 
thismb = 
end = 
#2  ssl3_read_bytes (s=, type=23, recvd_type=0x0, 
buf=0x7f6f83c10c58 "SIP/2.0 200 OK\r\nVia: SIP/2.0/TLS 
18.196.228.33:5061;received=18.196.228.33;branch=z9hG4bKb7cd.8d562f68384ebfdf796976dadc7858a1.0;i=2901\r\nVia:
 SIP/2.0/TCP 100.101.131.74:5060;rport=36255;received=100.1"...,
len=16383, peek=0, readbytes=0x739b3f30) at 
../ssl/record/rec_layer_s3.c:1348
i = 
j = 
ret = 
n = 
curr_rec = 
num_recs = 
totalbytes = 
rr = 0x7f6f7b56cbe8
rbuf = 
cb = 0x0
is_tls13 = 0
start = 
__func__ = "ssl3_read_bytes"
#3  0x7f6fdae683fc in ssl3_read_internal (s=0x7f6f7b56b940, 
buf=0x7f6f83c10c58, len=16383, peek=0, readbytes=0x739b3f30) at 
../ssl/s3_lib.c:4449
ret = 
#4  0x7f6fdae6ecb7 in SSL_read (s=s@entry=0x7f6f7b56b940, buf=, num=num@entry=16383) at ../ssl/ssl_lib.c:1871
ret = 
readbytes = 0
__func__ = "SSL_read"
#5  0x7f6fdaf2f61a in tls_h_read_f (c=c@entry=0x7f6f83c108a0, 
flags=flags@entry=0x739d4408) at 
/build/kamailio-5.8.2+ubuntu22.04/src/modules/tls/tls_server.c:1172
r = 0x7f6f83c109c8
bytes_free = 16383
bytes_read = 
read_size = 
ssl_error = 0
ssl_read = 0
ssl = 0x7f6f7b56b940
rd_buf = 
"\027\003\003\004Ď\202B\346o\234lj\254/#cD`\\\332O\313\353P\005ws\274\026\\\324\030\210\210;\037{\315\064\355Q\204\024[:Č]\330\062<\021E\373\371\241\237\207\373\020zj\f\006۫\262\001\270_;\372\273\366\334r\221Cq\321\023\071<3\v\021:\376[\245\322i\246x\330C\016G'\372\357\324>pY\247\356\361\371\351
 
\031\301\032T\256\243wlD54\221\310̨yl\267\037\212?`\024\321\065\"\273;O\275IR\263\312/V\210\316h\330\337\366p\276#\032\323-3\345\067\276\250[\274\361^\260\237\213\346,o\243ķ\204\257\354\343\317\312i6Y\034\370\266<7\034/^\201g\f\245\232}I\350*\344"...
wr_buf = 

[sr-dev] Re: [kamailio/kamailio] Undocumented TCP connection limit introduced in 5.7.3 must be configurable (Issue #3755)

[Sebastian Damm via sr-dev]

Thanks for the hint. Although I think, those type of behavior changes are 
something for a major version and should be mentioned in a Changelog, it's good 
that it is configurable.

Closing.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3755#issuecomment-1946344136
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: [kamailio/kamailio] Undocumented TCP connection limit introduced in 5.7.3 must be configurable (Issue #3755)

[Sebastian Damm via sr-dev]

Closed #3755 as completed.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3755#event-11817268626
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] [kamailio/kamailio] Undocumented TCP connection limit introduced in 5.7.3 must be configurable (Issue #3755)

[Sebastian Damm via sr-dev]

### Description

Scenario: Kamailio servers running behind a loadbalancer (AWS network 
loadbalancer in this case). This causes all packets to come from the same IP 
address in Kamailio's POV.

The change 
https://github.com/kamailio/kamailio/commit/a902e4a032a85a7755de32eeadac800a1312e64f
 introduced a connection limit per source IP address. This obviously conflicts 
with the setup mentioned above. We need up to 1 client connections, which 
would seem to all come from the same IP address.

Apart from this limit being introduced without a changelog entry (at least I 
didn't find one), I would expect it to be configurable. But from the commit it 
looks like it is a compile time option only.



 Log Messages

```
Feb 15 09:24:00 sipproxy /usr/sbin/kamailio[174]: CRITICAL:  
[core/tcp_main.c:4447]: handle_new_connect(): hit the limit of connections per 
source IP (100.68.15.172:4) - rejecting
Feb 15 09:24:01 sipproxy /usr/sbin/kamailio[174]: CRITICAL:  
[core/tcp_main.c:4447]: handle_new_connect(): hit the limit of connections per 
source IP (100.68.15.172:1153) - rejecting
Feb 15 09:24:01 sipproxy /usr/sbin/kamailio[174]: CRITICAL:  
[core/tcp_main.c:4447]: handle_new_connect(): hit the limit of connections per 
source IP (100.68.15.172:59946) - rejecting
```



### Additional Information

Using the packages from the official Kamailio repository.

  * **Kamailio Version** - output of `kamailio -v`

```
version: kamailio 5.7.4 (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, MEM_JOIN_FREE, Q_MALLOC, 
F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, 
USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, 
TLS_PTHREAD_MUTEX_SHARED
ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, 
BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: unknown
compiled with gcc 11.4.0
```

* **Operating System**:



```
Ubuntu Jammy
```


-- 
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3755
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: [kamailio/kamailio] TLS related crash in Kamailio 5.7.2 (double free) with libssl 3.x Ubuntu 22.04 (Issue #3635)

[Sebastian Damm via sr-dev]

@space88man I just checked it on a test system with exactly one connected 
client, and all 4 TCP listeners as well as the TCP main process show this 
output:
```
(gdb) p ossl_err_get_state_int()
No symbol "ossl_err_get_state_int" in current context.
(gdb)
```

-- 
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3635#issuecomment-1874993122
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: [kamailio/kamailio] TLS related crash in Kamailio 5.7.2 (double free) with libssl 3.x Ubuntu 22.04 (Issue #3635)

[Sebastian Damm via sr-dev]

Just to give a feedback: A nightly build has been running on one of our 
affected systems for three weeks now, and we haven't had a crash since. So the 
fix seems to improve the behavior. Next step is to test it on a system with 
client devices on the other end, handling much more TLS connections and more 
frequent connects and disconnects.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3635#issuecomment-1873764858
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: [kamailio/kamailio] TLS related crash in Kamailio 5.7.2 (double free) (Issue #3635)

[Sebastian Damm via sr-dev]

I really had overlooked the init_mode parameter. Have set it now, it is 
deployed to one production system, waiting if it crashes or not.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3635#issuecomment-1820658576
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: [kamailio/kamailio] Memory leak in dns_cache.c / dns_cache_mk_rd_entry (Issue #3523)

[Sebastian Damm via sr-dev]

Closed #3523 as completed.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3523#event-10969811645
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: [kamailio/kamailio] Memory leak in dns_cache.c / dns_cache_mk_rd_entry (Issue #3523)

[Sebastian Damm via sr-dev]

Since we are obviously the only ones having this problem and it's not possible 
for us to set up a useful test system and to find anything without it, I'm 
going to close it. Seems to be an edge case and we'll write a "restart every 4 
weeks" wrapper around.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3523#issuecomment-1812894698
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: [kamailio/kamailio] TLS related crash in Kamailio 5.7.2 (double free) (Issue #3635)

[Sebastian Damm via sr-dev]

After seeing the crashes on a system serving a lot of user requests, we see it 
happening on a system being connected to some carriers dealing with only 
outbound TLS connections, too.

Here are four more resolved core dumps.

[obp-crash1.log](https://github.com/kamailio/kamailio/files/13365195/obp-crash1.log)
[obp-crash2.log](https://github.com/kamailio/kamailio/files/13365196/obp-crash2.log)
[obp-crash3.log](https://github.com/kamailio/kamailio/files/13365197/obp-crash3.log)
[obp-crash4.log](https://github.com/kamailio/kamailio/files/13365198/obp-crash4.log)

Is there any useful information in the core dumps which can help finding the 
problem? 

-- 
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3635#issuecomment-1812533654
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] [kamailio/kamailio] TLS related crash in Kamailio 5.7.2 (double free) (Issue #3635)

[Sebastian Damm via sr-dev]

### Description

We have updated one system from a Ubuntu Focal 5.6.x container to a Ubuntu 
Jammy 5.7.2 container. In the last 24 hours, we saw three crashes. The logs of 
the last crash say:
```
Nov 09 20:39:34 sipproxy /usr/sbin/kamailio[4332]: CRITICAL:  
[core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer 
(0x7f[4434056180](tel:4434056180)), called from tls: tls_init.c: ser_free>
Nov 09 20:39:34 sipproxy /usr/sbin/kamailio[4331]: CRITICAL:  
[core/mem/q_malloc.c:123]: qm_debug_check_frag(): BUG: qm: fragm. 
0x7f[44340561](tel:44340561)d0 (address 0x7f[4434056208](tel:4434056208)) 
beginning overwritten >
Nov 09 20:39:43 sipproxy /usr/sbin/kamailio[4273]: ALERT:  [main.c:776]: 
handle_sigs(): child process 4331 exited by a signal 6
Nov 09 20:39:43 sipproxy /usr/sbin/kamailio[4273]: ALERT:  [main.c:779]: 
handle_sigs(): core was generated
```

 Debugging Data

Backtraces of the three crashes are attached.

[kamailio-crash1.log](https://github.com/kamailio/kamailio/files/13313115/kamailio-crash1.log)
[kamailio-crash2.log](https://github.com/kamailio/kamailio/files/13313116/kamailio-crash2.log)
[kamailio-crash3.log](https://github.com/kamailio/kamailio/files/13313117/kamailio-crash3.log)

### Additional Information

We are using the official Kamailio debian packages.

  * **Kamailio Version** - output of `kamailio -v`

```
version: kamailio 5.7.2 (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, MEM_JOIN_FREE, Q_MALLOC, 
F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, 
USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, 
TLS_PTHREAD_MUTEX_SHARED
ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, 
BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: unknown
compiled with gcc 11.4.0
```

* **Operating System**:



```
root@sipproxy:/WORKSPACE/sipproxy-container# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 22.04.3 LTS
Release:22.04
Codename:   jammy
root@sipproxy:/WORKSPACE/sipproxy-container# uname -a
Linux sipproxy 5.15.0-87-generic #97-Ubuntu SMP Mon Oct 2 21:09:21 UTC 2023 
x86_64 x86_64 x86_64 GNU/Linux
```


-- 
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3635
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: [kamailio/kamailio] Memory leak in dns_cache.c / dns_cache_mk_rd_entry (Issue #3523)

[Sebastian Damm via sr-dev]

Okay, the problem is not gone in current 5.7 (5.7.2 from the official repo). 

We restarted one affected system 2 days ago. Since then, I have dumped the shm 
summary a few times.

Shortly after restart:
```
NOTICE: qm_sums: qm_sums():  count=   159 size= 42000 bytes from core: 
core/dns_cache.c: dns_cache_mk_rd_entry(1117)
```

After running for 10 hours:
```
NOTICE: qm_sums: qm_sums():  count=  9822 size=   2857152 bytes from core: 
core/dns_cache.c: dns_cache_mk_rd_entry(1117)
```

After running for 2 days:
```
NOTICE: qm_sums: qm_sums():  count= 39931 size=  12716680 bytes from core: 
core/dns_cache.c: dns_cache_mk_rd_entry(1117)
```

Answering your question about the amount of different domains: We have a pretty 
static load sharing over all proxies, so without an outage the same amount of 
customer trunks always get routed through the same proxy. And there are only 
10-20 carriers that actually get routed through those proxies. The only special 
thing are Telekom CompanyFlex trunks, where every customer has their own dns 
name, which gets set in `$du` when handling the packet. All other trunks get 
routed simply via `$ru`.
In total there are just about 1k trunks registered through each system.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3523#issuecomment-1772868040
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: [kamailio/kamailio] Memory leak in dns_cache.c / dns_cache_mk_rd_entry (Issue #3523)

[Sebastian Damm via sr-dev]

We will first update two systems to the latest 5.7 branch release (and a new OS 
as well) and watch if the behavior has changed. Will take another week or so.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3523#issuecomment-1768374938
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: [kamailio/kamailio] Memory leak in dns_cache.c / dns_cache_mk_rd_entry (Issue #3523)

[Sebastian Damm]

There are no error messages. It happens all the time. I just checked the graphs 
of one of the affected systems. If we don't restart them from time to time, 
shared mem will fill up eventually.
https://github.com/kamailio/kamailio/assets/9820790/a173ed58-d3f0-47c5-bce8-7303dc97366a;>

`kamcmd dns.view` shows about 70 entries in the cache, not more. 
`kamcmd dns.delete_all_force` doesn't free any mem.
Anything else I can check here? 

-- 
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3523#issuecomment-1715616058
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] [kamailio/kamailio] Memory leak in dns_cache.c / dns_cache_mk_rd_entry (Issue #3523)

[Sebastian Damm]

### Description

We have some Kamailio servers running as an outboundproxy. Requests go to 
different domains. Over the time, there is a slow but steady shared memory 
increase. We don't see the behavior on our Kamailio servers serving as endpoint 
proxies using the same code.

I did a memory dump, and on two systems I inspected, I saw the same result: A 
really high memory usage for the `dns_cache_mk_rd_entry` function.


### Troubleshooting

 Reproduction

When we restart our Kamailio, it starts off with just a few megabytes of shared 
mem used. After running for a month or two, this has increased to some hundred 
megabytes used.


 Debugging Data

This is the output of the shm dump:

```
Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums(): 
summarizing all alloc'ed. fragments:
Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums():  
count= 1 size=   592 bytes from tm: t_reply.c: _reply_light(500)
Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums():  
count=45 size= 43576 bytes from core: core/msg_translator.c: 
build_req_buf_from_sip_req(2233)
Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums():  
count=44 size= 33232 bytes from tm: t_reply.c: relay_reply(2061)
Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums():  
count=45 size=376840 bytes from tm: h_table.c: build_cell(334)
Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums():  
count= 4 size=   224 bytes from pike: ip_tree.c: new_ip_node(201)
Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums():  
count=45 size=275304 bytes from core: core/sip_msg_clone.c: 
sip_msg_shm_clone(495)
Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums():  
count=16 size=  1528 bytes from core: core/usr_avp.c: create_avp(176)
Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums():  
count=45 size= 16728 bytes from core: core/sip_msg_clone.c: 
msg_lump_cloner(973)
Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums():  
count=12 size=   488 bytes from tls: tls_ct_q.h: tls_ct_q_add(58)
Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums():  
count=12 size=   584 bytes from tls: tls_server.c: 
tls_complete_init(276)
Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums():  
count=59 size=  3776 bytes from rtpengine: ../../core/parser/../ut.h: 
shm_str_dup(859)
Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums():  
count=   212 size= 15720 bytes from core: core/xavp.c: xavp_new_value(116)
Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums():  
count=59 size=  3888 bytes from rtpengine: rtpengine.c: 
rtpp_function_call(2775)
Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums():  
count=29 size=  2680 bytes from core: core/dns_cache.c: 
dns_cache_mk_bad_entry(770)
Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums():  
count=856568 size= 311761008 bytes from core: core/dns_cache.c: 
dns_cache_mk_rd_entry(1117)
Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums():  
count= 13941 size=   2741784 bytes from htable: ht_api.c: ht_cell_new(186)
Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums():  
count= 2 size=   104 bytes from xhttp_prom: prom_metric.c: 
prom_metric_lvalue_create(513)
Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums():  
count=24 size=  3752 bytes from tmx: tmx_pretran.c: 
tmx_check_pretran(250)
Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums():  
count=24 size=  6776 bytes from tmx: tmx_pretran.c: 
tmx_check_pretran(271)
Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums():  
count=   553 size=  10177808 bytes from core: core/tcp_main.c: tcpconn_new(1175)
Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums():  
count= 1 size= 53760 bytes from core: core/counters.c: 
counters_prefork_init(212)
Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums():  
count= 2 size=   976 bytes from tls: tls_domain.c: 
ksr_tls_fix_domain(1057)
Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums():  
count= 1 size=  8064 bytes from sl: sl_stats.c: init_sl_stats_child(125)
Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums():  
count= 1 size=   512 bytes from tmx: tmx_pretran.c: 
tmx_init_pretran_table(90)
Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: qm_sums: qm_sums():  
count= 1 size= 10752 bytes from tm: t_stats.c: init_tm_stats_child(56)
Jul 25 15:08:52 sipproxy /usr/sbin/kamailio[122]: NOTICE: 

Re: [sr-dev] [kamailio/kamailio] usrloc Stats are not compatible with Prometheus (xhttp_prom module) (#2644)

[Sebastian Damm]

Argh. Thanks for notifying. The update to 5.4 is on my roadmap as well, so I 
guess time will heal. 

-- 
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/2644#issuecomment-783512041___
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] usrloc Stats are not compatible with Prometheus (xhttp_prom module) (#2644)

[Sebastian Damm]

Closed #2644.

-- 
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/2644#event-4360775119___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] [kamailio/kamailio] usrloc Stats are not compatible with Prometheus (xhttp_prom module) (#2644)

[Sebastian Damm]

### Description

We tried to use the `xhttp_prom`  module, but our Prometheus couldn't read it, 
because of metrics conflicting with Prometheus data model.

For us, the problem lies in the usrloc module. It exports the following metrics:

```
usrloc:location-contacts = 0
usrloc:location-expires = 0
usrloc:location-users = 0
usrloc:registered_users = 0
```

However, Prometheus allows only ascii characters and digits, as well as 
underscores and colons. 
See: https://prometheus.io/docs/concepts/data_model/#metric-names-and-labels

The metrics names should not contain `-`, so they should get converted to `_`.

 Reproduction

Setup Kamailio with `usrloc`, `xhttp` and `xhttp_prom` module and let 
Prometheus query it. It will stumble upon the first entry of `usrloc` module 
stats.

### Possible Solutions

Either the `usrloc` module could export its stats with the dash replaced by 
underscores, or the xhttp_prom module could sanitize the output. The first one 
would be a breaking change, I guess, making this a change for a major release.

### Additional Information

  * **Kamailio Version** - output of `kamailio -v`

```
root@ifens5:/# kamailio -v
version: kamailio 5.3.8 (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, 
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: unknown
compiled with gcc 7.5.0```

* **Operating System**:

```
Ubuntu 18.04
```


-- 
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/2644___
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] Kamailio 5.1.10 crash in EVP_DecryptUpdate() (#2394)

[Sebastian Damm]

```
r...@sip-tcploadbalancer02.live.sipgate.net:/usr/lib/x86_64-linux-gnu/kamailio# 
ldd modules/tls.so
linux-vdso.so.1 (0x7ffef73a7000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f7cc66c6000)
libssl.so.1.1 => /usr/lib/x86_64-linux-gnu/libssl.so.1.1 
(0x7f7cc6634000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f7cc6613000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f7cc6452000)
/lib64/ld-linux-x86-64.so.2 (0x7f7cc676)
libcrypto.so.1.1 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 
(0x7f7cc6169000)
```

Okay, then this might be the first step to upgrading our Kamailio loadbalancers.

-- 
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/2394#issuecomment-654829933___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] [kamailio/kamailio] Kamailio 5.1.10 crash in EVP_DecryptUpdate() (#2394)

[Sebastian Damm]

### Description

We replaced a legacy wheezy system running Kamailio 5.1.4 with a Debian Buster 
system running Kamailio 5.1.10. (We currently can't update to 5.3.x because the 
configuration file is shared across multiple machines.  ) This new system has 
crashed upon us even before getting real traffic (except maybe some random 
scanners driving by), and even more frequently after sending traffic to it. The 
core dump looks the same with or without traffic.

### Troubleshooting

 Debugging Data


We have collected the gdb output as requested.

[kamailio_crash1.log](https://github.com/kamailio/kamailio/files/4884682/kamailio_crash1.log)

 Log Messages



```
Jul  5 22:20:18 sip-tcploadbalancer01 /usr/sbin/kamailio[15531]: ERROR: tls 
[tls_util.h:42]: tls_err_ret(): TLS read:error:24067044:random number 
generator:rand_pool_add:internal error
Jul  5 22:20:18 sip-tcploadbalancer01 /usr/sbin/kamailio[15531]: ERROR:  
[core/tcp_read.c:1505]: tcp_read_req(): ERROR: tcp_read_req: error reading - c: 
0x7f31ec06a3e8 r: 0x7f31ec06a468 (-1)
Jul  5 22:20:19 sip-tcploadbalancer01 /usr/sbin/kamailio[15534]: CRITICAL: 
 [core/pass_fd.c:277]: receive_fd(): EOF on 76
Jul  5 22:20:21 sip-tcploadbalancer01 /usr/sbin/kamailio[15479]: ALERT:  
[main.c:744]: handle_sigs(): child process 15530 exited by a signal 11
Jul  5 22:20:21 sip-tcploadbalancer01 /usr/sbin/kamailio[15479]: ALERT:  
[main.c:747]: handle_sigs(): core was generated
```

### Additional Information

  * **Kamailio Version** - output of `kamailio -v`

```
version: kamailio 5.1.10 (x86_64/linux)
flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, 
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, 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, 
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: unknown
compiled with gcc 8.3.0
```

* **Operating System**:



```
Linux hostname 4.19.0-9-amd64 #1 SMP Debian 4.19.118-2+deb10u1 (2020-06-07) 
x86_64 GNU/Linux
```


-- 
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/2394___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] [kamailio/kamailio] $(hdr(foo)[idx]) is 0-based, textopsx.remove_hf_value("foo[idx]") is 1-based, they should be the same (#2387)

[Sebastian Damm]

### Description

We have some JS code looping over all P-Asserted-Identity headers removing some 
of the entries:

```
let headerIndex = 0;
const telUriMatcher = new RegExp("tel:");
let paiValue = ksr.pv
  .gete("$(hdr(P-Asserted-Identity)[" + headerIndex + "])")
  .toString();
while (paiValue.length > 0) {
  ksr.info(
`${ksr.pv.getw("$ci")}: Found P-A-I header with content <${ksr.pv.getw(
  "$(hdr(P-Asserted-Identity)[" + headerIndex + "])"
)}> at index ${headerIndex}\n`
  );
  if (telUriMatcher.test(paiValue)) {
ksr.info(
  `${ksr.pv.getw("$ci")}: Removed P-A-I header ${ksr.pv.getw(
"$(hdr(P-Asserted-Identity)[" + headerIndex + "])"
  )}\n`
);
ksr.textopsx.remove_hf_value(
  "P-Asserted-Identity[" + headerIndex + "]"
);
  }
  headerIndex++;
  paiValue = ksr.pv
.gete("$(hdr(P-Asserted-Identity)[" + headerIndex + "])")
.toString();
}
```
In our tests, we wanted to remove the second header, but the first one got 
removed instead. The pseudovars docs say, the index of a header is 0-based. In 
textopsx docs it doesn't explicitly say, it's 1-based, but the first example 
shows it actually is.

### Possible Solutions

Right now, we replaced the line
```
ksr.textopsx.remove_hf_value("P-Asserted-Identity[" + headerIndex + "]");
```
with this one:
```
ksr.textopsx.remove_hf_value("P-Asserted-Identity[" + (headerIndex + 1) + "]");
```
This solves the problem, but it is not what we would expect. Both header access 
methods should use the same index base.

### Additional Information

  * **Kamailio Version** - output of `kamailio -v`

```
version: kamailio 5.3.5 (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, 
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: unknown
compiled with gcc 8.3.0
```

* **Operating System**:



```
Linux hostname 4.19.0-9-amd64 #1 SMP Debian 4.19.118-2+deb10u1 (2020-06-07) 
x86_64 GNU/Linux
```


-- 
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/2387___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] [kamailio/kamailio] Kemi: sdp_with_transport() missing and sdp_transport() doesn't always help (#2194)

[Sebastian Damm]

### Description

In plain Kamailio language, we used the following line:

```
if ( sdp_with_transport("RTP/SAVP") ) {
```

Now we wanted to convert that to Kemi. Turns out, the `sdp_with_transport()` 
function is not exported to Kemi. So we thought, we could use `sdp_transport()` 
to work around the missing function. This works as long as there is only one 
transport in SDP. 

But if a phone sends two media streams in SDP, one with RTP/AVP and one with 
RTP/SAVP, `sdp_transport()` will return `-2`.


### Troubleshooting

 Reproduction

Send an INVITE to Kamailio and try to get the transport type into a variable 
with ` sdp_transport()`. This can be done for example with a snom phone where 
in the rtp section of the identity configuration the parameter "RTP/SAVP" is 
set to "optional".

 Log Messages

```
Jan 10 13:08:13 hagi /usr/sbin/kamailio[7136]: DEBUG: app_jsdt 
[app_jsdt_api.c:996]: sr_kemi_jsdt_exec_func_ex(): param[0] for: sdp_transport 
is str: $avp(mediaTransport)
Jan 10 13:08:13 hagi /usr/sbin/kamailio[7136]: DEBUG:  
[core/usr_avp.c:887]: parse_avp_ident(): Parsing 'mediaTransport'
Jan 10 13:08:13 hagi /usr/sbin/kamailio[7136]: DEBUG:  
[core/pvapi.c:368]: pv_cache_add(): pvar [$avp(mediaTransport)] added in cache
Jan 10 13:08:13 hagi /usr/sbin/kamailio[7136]: DEBUG: sdpops 
[sdpops_mod.c:1214]: sdp_transport_helper(): stream 0 of 0 - transport 
[RTP/SAVP]
Jan 10 13:08:13 hagi /usr/sbin/kamailio[7136]: DEBUG: sdpops 
[sdpops_mod.c:1214]: sdp_transport_helper(): stream 1 of 0 - transport [RTP/AVP]
Jan 10 13:08:13 hagi /usr/sbin/kamailio[7136]: DEBUG: sdpops 
[sdpops_mod.c:1219]: sdp_transport_helper(): no common transport 
```

### Additional Information

We are still running Kamailio 5.1.x, but as far as I could see, the behavior 
has not changed since then.


-- 
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/2194___
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] Kemi: Support for KSR.notice() (#2193)

[Sebastian Damm]

Closed #2193.

-- 
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/2193#event-2934974804___
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] Kemi: Support for KSR.notice() (#2193)

[Sebastian Damm]

Oh, it really is there. On this system we are still at 5.1.x, but nevertheless 
it is there. It is just missing in the docs, which is why I thought it was not 
implemented.

-- 
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/2193#issuecomment-572565239___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] [kamailio/kamailio] Kemi: Support for KSR.notice() (#2193)

[Sebastian Damm]

### Description

The Kemi framework supports `KSR.info()` and `KSR.warn()`, but the level in 
between is missing. Our legacy systems use INFO logging in our dev systems and 
NOTICE logging in production environment. So everytime we replace some legacy 
Kamailio config with Kemi code, we stumble upon then missing `KSR.notice()` 
method or the missing "notice" level parameter to `KSR.log()`.



-- 
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/2193___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] [kamailio/kamailio] Configure permissions module without database (#2037)

[Sebastian Damm]

### Description

In our setup, we try to eliminate setup configuration in database and replace 
it with files. The advantage is, that we can maintain those files via puppet or 
ansible, and since we always rewrite the whole file, we don't have to take care 
about deleting obsolete entries. We can run different Kamailio versions without 
having problems with the version table when using the same database. And 
finally, we can stop all those local mysqld processes on a lot of machines.

Modules like the dispatcher module were easy to change. But the permissions 
module is not prepared to run without database, if you want to use 
`allow_trusted()` or `allow_source_address()` and similar. The only option to 
feed those functions with data is a database table.

### Expected behavior

We would like to place files for trusted and address into the Kamailio 
directory and have Kamailio read from those files during startup or after 
reload commands.

 Actual observed behavior

Data for trusted and address have to reside inside a database.



-- 
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/2037___
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] Kemi sqlops memory leak (#2032)

[Sebastian Damm]

Closed #2032.

-- 
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/2032#event-2555766339___
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] Kemi sqlops memory leak (#2032)

[Sebastian Damm]

Thanks for opening our eyes once again, @miconda! We already thought of 
something like this, but got stuck in the second parameter. Indeed we set the 
user id as result identifier. We changed it to a static string now, I think the 
problem should disappear.

-- 
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/2032#issuecomment-521149183___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] [kamailio/kamailio] Kemi sqlops memory leak (#2032)

[Sebastian Damm]

### Description

We are running Kamailio 5.1.x in a mixed native/Kemi environment. That means, 
most of the config is still native Kamailio language, but some newer functions 
were written in JS and included via `jsdt_run("...");`. 

In one of those functions, we place an sqlops query. And since introducing this 
code, Kamailio leaks memory. Slowly, but eventually, the private memory will 
fill up.

### Troubleshooting

 Reproduction

In Kamailio, the code looks like this:
```
if (!jsdt_run("ksrIsCallAccountingRequired", 
"$(var(accentries){s.select,10,|})", "$(var(accentries){s.select,12,|})")) {
xlog("L_ERR", "JS Call of ksrIsCallAccountingRequired route 
failed.\n");
}
```

And our JS code containing sqlops looks like this:
```
extension = '1234567e0';
mastersipid = '1234567';
KSR.sqlops.sql_query(
"dbconn",
`SELECT username, grp FROM grp WHERE username IN ('${mastersipid}', 
'${extension}') AND grp = 'ourGroupName'`,
user
  );
```

For each call, this query is executed once. Depending on the traffic, you can 
see the private package memory starting to fill up quicker or slower.

 Debugging Data

### Possible Solutions

We had a similar problem about two years ago with app_lua and getting entries 
from a hash table, which we solved by introducing a temporary variable for 
using in the hash table index instead of strings. We tried doing the same thing 
in our current setup:

```
KSR.pv.sets("$var(extensionForQuery)", extension);
KSR.pv.sets("$var(masterSipidForQuery)", masterSipid);
KSR.sqlops.sql_query(
"dbconn",
"SELECT username, grp FROM grp WHERE username IN 
('$var(masterSipidForQuery)', '$var(extensionForQuery)') AND grp = 
'ourGroupName'",
user
  );
```

However, Kamailio doesn't replace the variables in the query string. Although 
the documentation of the sqlops module says, it supports pseudovars in the 
query string. We even tried putting the whole query into a variable, but ended 
up with a sqlops error.


### Additional Information

```
ersion: kamailio 5.1.4 (x86_64/linux)
flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, 
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, 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_LISTEN 16, 
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 4.7.2
```

* **Operating System**:

```
Debian Wheezy (yeah, I know... )
```


-- 
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/2032___
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] app_jsdt: KSR.x.exit() not working as intended (#1936)

[Sebastian Damm]

Thanks for pointing that out. The (Kemi) documentation for KSR.x.exit was a bit 
misleading for our scenario.

-- 
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/1936#issuecomment-486199263___
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] app_jsdt: KSR.x.exit() not working as intended (#1936)

[Sebastian Damm]

Closed #1936.

-- 
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/1936#event-2296952761___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] [kamailio/kamailio] app_jsdt: KSR.x.exit() not working as intended (#1936)

[Sebastian Damm]

### Description



In a project, we implemented parts of our routing logic with javascript. We 
don't use KEMI at the moment. So most of the routing logic still happens in 
kamailio.cfg. We have implemented the t_relay part in JS, and after that we 
want to stop the execution of the routing logic. In kamailio config we would do 
that with return or exit. In our implementation we used KSR.x.exit(), but the 
execution of the kamailio config continues.

This is how our kamailio config section looks like:

```
  # No Accounting special calls
if ( $fU =~ "^1234567$") {
resetflag(doAccounting);
}

if (!jsdt_run("routeSomeCallsHere")) {
xlog("L_ERR", "JS Call of routeSomeCallsHere 
route failed.\n");
}

# routing decision
route(makeRoutingDecision);
```

This is what the JS does:

```
function relayPacket() {
KSR.dbg("Sending out packet " + KSR.pv.get("$rm") + " statefully.\n");
if (KSR.tm.t_relay() < 0) {
KSR.err("statefulForward: error to <" + KSR.pv.get("$tu") + "> from <" 
+ KSR.pv.get("$fu") + ">\n");
if (KSR.is_method_in("IA")) {
KSR.rtpengine.rtpengine_delete0();
}
KSR.sl.sl_reply_error();
KSR.x.exit();
return false;
}
KSR.info("DONE relaying!!!");
KSR.x.exit();
return true;
};
```

Looks to us as if KSR.x.exit() does not work in our scenario. Did we miss 
something? In the end, Kamailio sends out two INVITEs, one from JS and one from 
the old routing logic.


### Additional Information

  * **Kamailio Version** - output of `kamailio -v`

```
version: kamailio 5.1.4 (x86_64/linux)
flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, 
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, 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_LISTEN 16, 
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 4.7.2
```

* **Operating System**:

Debian Wheezy


-- 
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/1936___
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] kamailio refuses custom global variable (#1773)

[Sebastian Damm]

I think, in your case, the syntax could be wrong.

Try:
```config.kamailioip=10.10.10.10```

-- 
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/1773#issuecomment-449282904___
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] Segfaults in 5.1.4 (maybe after one rtpengine disappeared) (#1613)

[Sebastian Damm]

No, we don't have an tm event routes at all. The only event routes are:

```
event_route[xhttp:request] {
event_route[dispatcher:dst-down] {
event_route[dispatcher:dst-up] {
```


-- 
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/1613#issuecomment-414230848___
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] Segfaults in 5.1.4 (maybe after one rtpengine disappeared) (#1613)

[Sebastian Damm]

First core file:

```
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
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-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /usr/sbin/kamailio...Reading symbols from 
/usr/lib/debug/.build-id/bf/0f481eacd5661e7adec0c358237730d825ea2a.debug...done.
done.
[New LWP 31359]

warning: Can't read pathname for load map: Input/output error.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/sbin/kamailio -f 
/etc/kamailio/kamailio_sip_proxy.cfg -P /var/run/kamailio'.
Program terminated with signal 11, Segmentation fault.
#0  0x00663091 in destroy_avp_list_unsafe (list=0x7efe49050bd0) at 
core/usr_avp.c:625
625 core/usr_avp.c: No such file or directory.
(gdb) frame 1
#1  0x7efe6b4daadc in free_cell_helper (dead_cell=0x7efe49050a48, silent=0, 
fname=0x7efe6b5db100 "timer.c", fline=654) at h_table.c:242
242 h_table.c: No such file or directory.
(gdb) p *dead_cell 
$1 = {next_c = 0x0, prev_c = 0x0, hash_index = 30681, label = 705812179, flags 
= 32, nr_of_outgoings = 1, ref_count = {val = 0}, from = {
s = 0x7efe48f3796d "From: 
;tag=7fcea877-80e3-4069-b\r\nCall-ID: 
DF246541ADA4EDA2@84.149.15.231\r\nEvent: message-summary\r\nSubscription-State: 
Active\r\nRoute: \r\nConte"..., len = 57}, 
callid = {
s = 0x7efe48f379a6 "Call-ID: DF246541ADA4EDA2@84.149.15.231\r\nEvent: 
message-summary\r\nSubscription-State: Active\r\nRoute: 
\r\nContent-Type: 
application/simple-message-summary\r\nVia: SIP/2.0"..., len = 41}, cseq_n = {
s = 0x7efe48f3792d "CSeq: 7950 NOTIFY\r\nTo: 
;tag=3951995175\r\nFrom: 
;tag=7fcea877-80e3-4069-b\r\nCall-ID: 
DF246541ADA4EDA2@84.149.15.231\r\nEvent: message-summary\r\nSubscription-S"..., 
len = 10}, to = {
s = 0x7efe48f37940 "To: ;tag=3951995175\r\nFrom: 
;tag=7fcea877-80e3-4069-b\r\nCall-ID: 
DF246541ADA4EDA2@84.149.15.231\r\nEvent: message-summary\r\nSubscription-State: 
Active\r\nRoute"..., len = 45}, method = {
s = 0x7efe48f378e0 "NOTIFY 
sip:1442863@84.149.15.231;uniq=29A7ECC65F8884BD635517C89AFD8 SIP/2.0\r\nCSeq: 
7950 NOTIFY\r\nTo: ;tag=3951995175\r\nFrom: 
;tag=7fcea877-80e3-4069-b\r\nCa"..., len = 6}, tmcb_hl 
= {first = 0x0, reg_types = 0}, wait_timer = {next = 0x0, prev = 0x0, expire = 
1289862248, initial_timeout = 320, data = 0x7efe49050a48, 
f = 0x7efe6b5875fa , flags = 513, slow_idx = 0}, uas = 
{request = 0x7efe48f371c8, end_request = 0x7efe48f38070 "\210", response = 
{activ_type = 481, flags = 128, t_active = 0 '\000', 
  branch = 0, buffer_len = 323, 
  buffer = 0x7efe49077660 "SIP/2.0 481 Call Leg/Transaction Does Not 
Exist\r\nVia: SIP/2.0/UDP 217.10.76.144:5060\r\nFrom: 
;tag=7fcea877-80e3-4069-b\r\nTo: 
;tag=3951995175\r\nCall-ID: DF2"..., my_T = 
0x7efe49050a48, timer = {next = 0x0, prev = 0x0, expire = 0, initial_timeout = 
0, data = 0x0, f = 0x7efe6b5870b2 , flags = 0, slow_idx = 0}, 
dst = {
send_sock = 0x7efe6dff77e0, to = {s = {sa_family = 2, sa_data = 
"\023\304\331\nL\220\000\000\000\000\000\000\000"}, sin = {sin_family = 2, 
sin_port = 50195, sin_addr = {s_addr = 2420902617}, 
sin_zero = "\000\000\000\000\000\000\000"}, sin6 = {sin6_family = 
2, sin6_port = 50195, sin6_flowinfo = 2420902617, sin6_addr = {__in6_u = 
{__u6_addr8 = '\000' , __u6_addr16 = {0, 
  0, 0, 0, 0, 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}, 
sin6_scope_id = 0}}, id = 0, proto = 1 '\001', send_flags = {f = 0, blst_imask 
= 0}}, retr_expire = 0, fr_expire = 0}, local_totag = {
  s = 0x0, len = 0}, cancel_reas = 0x0, status = 481}, uac = 
0x7efe49050c50, async_backup = {backup_route = 0, backup_branch = 0, blind_uac 
= 0, ruri_new = 0}, fwded_totags = 0x0, 
  uri_avps_from = 0x7efe49030900, uri_avps_to = 0x0, user_avps_from = 0x0, 
user_avps_to = 0x0, domain_avps_from = 0x0, domain_avps_to = 0x0, xavps_list = 
0x0, reply_mutex = {val = 0}, reply_locker_pid = {
val = 0}, reply_rec_lock_level = 0, fr_timeout = 320, fr_inv_timeout = 
2000, rt_t1_timeout_ms = 500, rt_t2_timeout_ms = 4000, end_of_life = 
1289862439, relayed_reply_branch = 0, on_failure = 0, 
  on_branch_failure = 0, on_reply = 0, on_branch = 0, on_branch_delayed = 0, 
md5 = 0x7efe49050c30 "f17e9566ecae744152b7aed3c5ba0273"}
```

The other core:
```
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
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.

Re: [sr-dev] [kamailio/kamailio] Kamailio returns "interesting" json string when querying statistics (#1595)

[Sebastian Damm]

Thanks for explaining. The stats.fetch is a lot better already, although the 
values are returned as strings instead of numbers.

-- 
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/1595#issuecomment-405255440___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] [kamailio/kamailio] Kamailio returns "interesting" json string when querying statistics (#1595)

[Sebastian Damm]

### Description

When querying Kamailio 5.1 for statistics via JSON, we get back a string like 
this (shortened):

```
kamailio:~# curl -X POST -d '{ "jsonrpc": "2.0", "method": 
"stats.get_statistics", "params": ["all"],"id": 1 }' 
http://172.20.21.3:15060/jsonrpc
{
"jsonrpc":  "2.0",
"result":   ["core:bad_URIs_rcvd = 0", "core:bad_msg_hdr = 0", 
"core:drop_replies = 0", "core:drop_requests = 4", "core:err_replies = 0", 
"core:err_requests = 0", "core:fwd_replies = 2252", "core:fwd_requests = 
16153", "core:rcv_replies = 393994", "core:rcv_replies_18x = 0"],
"id":   1
}
```

We want to graph some of the values returned by the statistics module. But the 
format makes it a bit hard. I would expect the format to be like this:

```
{
"jsonrpc":  "2.0",
"result":   {"core:bad_URIs_rcvd" : 0, "core:bad_msg_hdr" : 0, 
"core:drop_replies" : 0, "core:drop_requests" : 4, "core:err_replies" : 0, 
"core:err_requests" : 0, "core:fwd_replies" : 2252, "core:fwd_requests" : 
16153, "core:rcv_replies" : 393994, "core:rcv_replies_18x" : 0},
"id":   1
}
```

With a result like this, one could access the result["core:bad_URIs_rcvd"] 
item. The way it is returned now, one has to iterate through all values and to 
a string comparison for the desired item.

Is there a reason, why the output is as it is?

### Additional Information

  * **Kamailio Version** - output of `kamailio -v`

```
version: kamailio 5.1.4 (x86_64/linux)
flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, 
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, 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_LISTEN 16, 
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 4.7.2
```

* **Operating System**:



```
Debian Wheezy Linux hostname 3.2.0-5-amd64 #1 SMP Debian 3.2.96-3 x86_64 
GNU/Linux
```


-- 
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/1595___
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] nathelper always sends SIP pings when ping_nated_only is set to 0 (#1587)

[Sebastian Damm]

Closed #1587.

-- 
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/1587#event-1729668881___
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] nathelper always sends SIP pings when ping_nated_only is set to 0 (#1587)

[Sebastian Damm]

Hi Daniel, thanks for the quick fix. I just backported those two patches from 
yesterday and the affected loadbalancers immediately stopped sending out 
OPTIONS and started sending out 4 bytes packets instead. From my point of view 
everything is working again as expected.

I agree, that the addition of a mode parameter would help understanding the 
functionality.

-- 
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/1587#issuecomment-404425477___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] [kamailio/kamailio] nathelper always sends SIP pings in IPv6 scenario (#1587)

[Sebastian Damm]

### Description

We upgraded from Kamailio 4.4.5 to 5.1.4 today. We have a IPv6-to-v4 
loadbalancer which sends out NAT pings to keep the connection through routers 
alive. So it is not a real NAT scenario.

Kamailio 4.4.5 sent out dummy 4-byte UDP packets. Kamailio 5.1.4 sends out SIP 
OPTIONS although we didn't even configure sipping_from.

Our configuration:

```
loadmodule "nathelper.so"
modparam("nathelper", "received_avp", "$(avp(i:801))")
modparam("nathelper", "natping_interval" , 14)
modparam("nathelper", "ping_nated_only" , 0)
```

When looking into the code, Kamailio should not even be able to send out 
OPTIONS without sipping_from being configured. It does anyhow. This results in 
broken keepalive packets.

```
OPTIONS 
sip:foobar@[2003:a:c6b:8400:204:::]:6060;transport=udp;line=s4cqtu 
SIP/2.0.
Via: SIP/2.0/UDP [2001:AB7:0:0:0:0:0:1]:5060;branch=z9hG4bK9474521.
From: ;tag=uloc-5b2b6211-355f-81fc4-3f1f9b57-6a9dc2.
To: 
sip:foobar@[2003:a:c6b:8400:204:::]:6060;transport=udp;line=s4cqtu.
Call-ID: -6a9dc2-cac4404@2001:AB7:0:0:0:0:0:1.
CSeq: 1 OPTIONS.
Content-Length: 0.
.```

Those packets get rejected by some clients, bringing them offline, effectively.

After adding the sipping_from modparam, those OPTIONS get sent with a correct 
From header.

### Troubleshooting

 Reproduction

Our v4-only SIP proxies don't show the behavior, our v6-to-v4 loadbalancers do. 
I don't know if this can be reproduced with a default installation on a IPv6 
setup.

 Log Messages



```
(paste your log messages here)
```

 SIP Traffic



```
(paste your sip traffic here)
```

### Possible Solutions

Setting the sipping_from parameter at least fixes the OPTIONS packet. But we 
found no way to send those dummy UDP packets instead of full OPTIONS.


### Additional Information

Kamailio branch 5.1 pulled yesterday, 5.1.4

  * **Kamailio Version** - output of `kamailio -v`

```
version: kamailio 5.1.4 (x86_64/linux)
flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, 
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, 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_LISTEN 16, 
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 4.7.2
```

* **Operating System**:



```
Debian Wheezy,  Linux hostname 3.2.0-5-amd64 #1 SMP Debian 3.2.96-3 x86_64 
GNU/Linux
```


-- 
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/1587___
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] Kamailio 5.0.3 segfault (in redis module?) (#1342)

[Sebastian Damm]

Okay, I wasn't aware of that syntax. But of course it is stated in the 
documentation. The string we have in $vn(variable2) is data which is reduced by 
protobuf, so the %s is probably really in there. 

I have now changed the command to how you suggested it, so far I don't see a 
difference in ngrep output. 

Thanks for the quick reply. 



-- 
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/1342#issuecomment-347827198___
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] Kamailio 5.0.3 segfault (in redis module?) (#1342)

[Sebastian Damm]

Closed #1342.

-- 
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/1342#event-1363286168___
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] Kamailio 5.0.3 segfault (in redis module?) (#1342)

[Sebastian Damm]

This is the output:

```
(gdb) frame 4
#4  0x7ff057a4d6ac in redisc_exec (srv=0x7ffd7df680d0, res=0x7ffd7df680f0, 
cmd=0x7ffd7df680e0) at redis_client.c:402
402 redis_client.c: No such file or directory.
(gdb) list
397 in redis_client.c
(gdb) p cmd
$1 = (str *) 0x7ffd7df680e0
(gdb) p *cmd
$2 = {s = 0x7ff05d2a00a0 "SETEX 
activechannels_swp3pvm7jqpnu6ixphj1jc7...@sipgate.de 21600 
\n%swp3pvm7jqpnu6ixphj1jc7...@sipgate.de\022\n1234567e16\032\n4912345678\"%swp3pvm7jqpnu6ixphj1jc7...@sipgate.de",
 len = 167}
(gdb) p cmd->s
$3 = 0x7ff05d2a00a0 "SETEX activechannels_swp3pvm7jqpnu6ixphj1jc7...@sipgate.de 
21600 
\n%swp3pvm7jqpnu6ixphj1jc7...@sipgate.de\022\n1234567e16\032\n4912345678\"%swp3pvm7jqpnu6ixphj1jc7...@sipgate.de"
```

This is how we call `redis_cmd`:
```
   if ($vn(variable1) == "ADD" && $vn(variable2) != $null) {
   if (!redis_cmd("liRedis", "SETEX ACTIVECHANNELS_$ci 21600 
$vn(variable2)", "r")) {
   xlog("L_ERR", "redis SET of ACTIVECHANNELS_$ci failed");
   }
   redis_free("r");
   } else {
   if (!redis_cmd("liRedis", "DEL ACTIVECHANNELS_$ci", "r")) {
   xlog("L_ERR", "redis DEL of ACTIVECHANNELS_$ci failed");
   }
   redis_free("r");
   }
```

-- 
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/1342#issuecomment-347794449___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] [kamailio/kamailio] Kamailio 5.0.3 segfault (in redis module?) (#1342)

[Sebastian Damm]

### Description

We have a Kamailio running with a sipcapture module, then handling everything 
in app_lua and writing some information to a redis server. This Kamailio 
crashed after running for about a day.

### Troubleshooting

 Debugging Data

This is the gdb output of bt full:

```
GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
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-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/sbin/kamailio...Reading symbols from 
/usr/lib/debug/.build-id/98/6903c27311ebc3717be5ca53d70d130c092eea.debug...done.
done.
[New LWP 120921]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/sbin/kamailio -P 
/var/run/kamailio/kamailio_li_sniffer.pid -f /etc/kamaili'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7ff05e2d5c3a in strlen () from /lib/x86_64-linux-gnu/libc.so.6
#0  0x7ff05e2d5c3a in strlen () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1  0x7ff05783f2aa in redisvFormatCommand () from 
/usr/lib/x86_64-linux-gnu/libhiredis.so.0.10
No symbol table info available.
#2  0x7ff0578400a2 in redisvAppendCommand () from 
/usr/lib/x86_64-linux-gnu/libhiredis.so.0.10
No symbol table info available.
#3  0x7ff057840289 in redisvCommand () from 
/usr/lib/x86_64-linux-gnu/libhiredis.so.0.10
No symbol table info available.
#4  0x7ff057a4d6ac in redisc_exec (srv=0x7ffd7df680d0, res=0x7ffd7df680f0, 
cmd=0x7ffd7df680e0) at redis_client.c:402
rsrv = 0x7ff05d2bdba0
rpl = 0x7ff05d2eb020
c = 0 '\000'
ap = {{gp_offset = 40, fp_offset = 48, overflow_arg_area = 
0x7ffd7df680a0, reg_save_area = 0x7ffd7df67fb0}}
ap2 = {{gp_offset = 24, fp_offset = 48, overflow_arg_area = 
0x7ffd7df680a0, reg_save_area = 0x7ffd7df67fb0}}
__FUNCTION__ = "redisc_exec"
#5  0x7ff057a51156 in w_redis_cmd3 (msg=0x7ff05d30ca28, ssrv=0x7ff05d2d6088 
"p\270-]\360\177", scmd=0x7ff05d2d61b0 "\360\237-]\360\177", 
sres=0x7ff05d2d62d8 "\030z-]\360\177") at ndb_redis_mod.c:160
s = {{s = 0x7ff05d2db870 "liRedis", len = 7}, {
s = 0x7ff05d2a00a0 "SETEX 
activechannels_swp3pvm7jqpnu6ixphj1jc7...@sipgate.de 21600 
\n%swp3pvm7jqpnu6ixphj1jc7...@sipgate.de\022\n2457742e16\032\n4923256980\"%swp3pvm7jqpnu6ixphj1jc7...@sipgate.de",
 len = 167}, {
s = 0x7ff05d2d7a18 "r", len = 1}}
__FUNCTION__ = "w_redis_cmd3"
#6  0x0045ceac in do_action (h=0x7ffd7df68800, a=0x7ff05d2d6f78, 
msg=0x7ff05d30ca28) at core/action.c:1072
ret = -5
v = 1583322656
dst = {send_sock = 0x77006e, to = {s = {sa_family = 38432, sa_data 
= "_^\360\177\000\000\060\217\000\000\000\000\000"}, sin = {sin_family = 38432, 
sin_port = 24159, sin_addr = {s_addr = 32752}, 
  sin_zero = "0\217\000\000\000\000\000"}, sin6 = {sin6_family = 
38432, sin6_port = 24159, sin6_flowinfo = 32752, sin6_addr = {__in6_u = 
{__u6_addr8 = "0\217\000\000\000\000\000\000 \226_^\360\177\000", __u6_addr16 = 
{36656, 0, 
0, 0, 38432, 24159, 32752, 0}, __u6_addr32 = {36656, 0, 
1583322656, 32752}}}, sin6_scope_id = 3}}, id = 0, proto = -104 '\230', 
send_flags = {f = 191 '\277', blst_imask = 241 '\361'}}
tmp = 0x1ef559c ""
new_uri = 0x0
end = 0x0
crt = 0x 
cmd = 0x7ff05d2b9940
len = 131296
user = 0
uri = {user = {s = 0x7ffd7df68530 "\220\207\366}\375\177", len = 0}, 
passwd = {s = 0x7ffd7df68430 " ", len = 32620272}, host = {s = 0x5 , len = 2113307744}, port = {
s = 0x7ffd7df684b0 "\330\204\366}\375\177", len = 32620440}, params 
= {s = 0x7c , len = 0}, sip_params 
= {s = 0x77006e , 
len = 31080512}, headers = {s = 0x20 , len = 1583322656}, port_no = 16480, proto = 474, type = 
ERROR_URI_T, flags = (unknown: 32462272), transport = {
s = 0x20 , len = 
1580005056}, ttl = {s = 0x4 , len = 
240}, user_param = {s = 0x7ff05e5f9620 "", len = 1583322656}, maddr = {
s = 0x9 , len = 0}, 
method = {s = 0x7ff057842acf "", len = 0}, lr = {s = 0x0, len = 1580007456}, r2 
= {s = 0x7ffd7df684d8 "0\205\366}\375\177", len = -24651520}, gr = {s = 0x0, 
len = 33205536}, transport_val = {s = 0x7ffd7df68570 
"\377\377\377\177", len = 2113307952}, ttl_val = 

Re: [sr-dev] [kamailio/kamailio] tmx: t_reuse_branch() doesn't copy $du into new branch (#1264)

[Sebastian Damm]

I saw that it is documented like that, but in my eyes that makes it pretty 
useless in a scenario where $du is filled by the path from registration of a 
device. That's why I thought it was a bug.

Do you have any suggestions to circumvent that problem? How would I save a 
per-branch variable? I tried something like
`$avp(foo)[$T_branch_idx]`
but it seems like Kamailio doesn't like variables being used for an index.

-- 
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/1264#issuecomment-336175926___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] [kamailio/kamailio] tmx: t_reuse_branch() doesn't copy $du into new branch (#1264)

[Sebastian Damm]

### Description

When using the t_reuse_branch() function after a branch failure, Kamailio 
doesn't send out the call again if $du was filled and differed from $ru. 
Instead, Kamailio tries to send the call directly to $ru.

I would expect that the call gets sent out the same way as the original call.

### Troubleshooting

 Reproduction

You need a setup like this:

UAC1 K(LB) <=> K(Proxy/Registrar) <=> K(LB) => UAC2

When a UAC registers, the Path module is used to save the LB (Loadbalancer) for 
outbound calls. When UAC1 calls UAC2, the original call gets sent through K(LB) 
to UAC2. However, if the first call gets rejected and the call gets retried 
through branch failure route, K(Proxy/Registrar) tries to send the call 
directly to the request URI.

In your branch_route add a reference to a branch failure route:

```t_on_branch_failure("samplename");```

Then add a branch failure route like this:

```event_route[tm:branch-failure:handle_tls_branch] {
if(t_check_status("488")) {
if (isbflagset(0) && !isbflagset(1)) {
t_reuse_branch();
setbflag(1);
t_relay();
}
}
}```

When filling $du manually before sending out the call again, everything works.

### Possible Solutions

The original destination URI should be copied to the reused branch.

### Additional Information

  * **Kamailio Version** - output of `kamailio -v`

```
version: kamailio 4.4.5 (x86_64/linux)
flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, DISABLE_NAGLE, 
USE_MCAST, DNS_IP_HACK, SHM_MEM, 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_LISTEN 16, 
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 4.7.2
```
But from what I see in source code, the devel version still copies the same 
value.

* **Operating System**:



```
Debian Wheezy
```


-- 
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/1264___
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 when calling $sel(cfg_get...) (#1159)

[Sebastian Damm]

Closed #1159.

-- 
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/1159#event-1232961737___
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] nathelper: correct Contact received param (#1203)

[Sebastian Damm]

Okay, so should we just add a comment in the documentation warning people of 
known bugs? Or what would the clean solution be? Maybe just eliminate that 
function in master and let it die?

-- 
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/1203#issuecomment-321212755___
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] nathelper: correct Contact received param (#1203)

[Sebastian Damm]

I have never used it myself. I just wanted to help this one mailing list post, 
but of course, this commit is broken.

I just looked into the path module how it's done there, and there exists a 
struct for different transports:

```const static char *proto_strings[] = {
[PROTO_TCP] = "%3Btransport%3Dtcp",
[PROTO_TLS] = "%3Btransport%3Dtls",
[PROTO_SCTP] = "%3Btransport%3Dsctp",
[PROTO_WS] = "%3Btransport%3Dws",
[PROTO_WSS] = "%3Btransport%3Dws",
};```

This gets appended to the received param if needed. Then a Path header looks 
like this:

```Path: .```

Unfortunately I'm not able to implement that for the nathelper module as my C 
knowledge is limited to doing such trivial stuff like the commit above.

-- 
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/1203#issuecomment-320923757___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] [kamailio/kamailio] nathelper: correct Contact received param (#1203)

[Sebastian Damm]

 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
- [ ] Tested changes locally
- [ ] Related to issue # (replace  with an open issue number)

 Description

- Received param was enclosed in quotes, making some UACs stumble
  upon it. This fix removes the quotes, adding the received param
  the same way as it is done for example in the path module.
- Reported by Arslan Aseed.

You can view, comment on, or merge this pull request online at:

  https://github.com/kamailio/kamailio/pull/1203

-- Commit Summary --

  * nathelper: correct Contact received param

-- File Changes --

M src/modules/nathelper/nathelper.c (6)

-- Patch Links --

https://github.com/kamailio/kamailio/pull/1203.patch
https://github.com/kamailio/kamailio/pull/1203.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/1203
___
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 when calling $sel(cfg_get...) (#1159)

[Sebastian Damm]

Adding `desc` does not change anything.

```config.foo = "hello Daniel" desc "foo config var"```

And I at first stumbled upon it when using `sipgate.foo` variables. Just tried 
again with

```wurst.wasser = "mic check 123" desc "bla"```

and it immediately crashed again when trying to access the value.

-- 
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/1159#issuecomment-311670440___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] [kamailio/kamailio] jansson: can't extract values from string-only json array (#1171)

[Sebastian Damm]

### Description

I have a json string stored in a variable, and I want to iterate over the 
values in it. This works if there are integer values in the json string. But if 
it consists only of string values, jansson_get throws an error.

According to jsonlint, all my json strings are valid.

### Troubleshooting

 Reproduction

This is the part of kamailio.cfg leading to the error:

```
# Integer json array
$var(myIntList) = '[2,3,4,5]';
xlog("L_INFO", "Integer json string is  $var(myIntList) ");
jansson_get('[0]', $var(myIntList), "$var(intValue)");
xlog("L_INFO", "First Int Element: >> $var(intValue) <<");
jansson_get('[1]', $var(myIntList), "$var(intValue)");
xlog("L_INFO", "Second Int Element: >> $var(intValue) <<");
# String json array
$var(myStringList) = '["foo", "bar", "baz"]';
xlog("L_INFO", "String json string is  $var(myStringList) ");
jansson_get('[0]', $var(myStrList), "$var(strValue)");
xlog("L_INFO", "First Str Element: >> $var(strValue) <<");
jansson_get('[1]', $var(myStrList), "$var(strValue)");
xlog("L_INFO", "Second Str Element: >> $var(strValue) <<");
# Mixed json array
$var(myMixedList) = '[2, "bar"]';
xlog("L_INFO", "Mixed json string (int first) is  $var(myMixedList) 
");
jansson_get('[0]', $var(myMixedList), "$var(mixedValue)");
xlog("L_INFO", "First Mixed Element: >> $var(mixedValue) <<");
jansson_get('[1]', $var(myMixedList), "$var(mixedValue)");
xlog("L_INFO", "Second Mixed Element: >> $var(mixedValue) <<");
$var(myMixedList) = '["bar", 2]';
xlog("L_INFO", "Mixed json string (string first) is  
$var(myMixedList) ");
jansson_get('[0]', $var(myMixedList), "$var(mixedValue)");
xlog("L_INFO", "First Mixed Element: >> $var(mixedValue) <<");
jansson_get('[1]', $var(myMixedList), "$var(mixedValue)");
xlog("L_INFO", "Second Mixed Element: >> $var(mixedValue) <<");
```

 Log Messages

This is the output generated by the above kamailio.cfg snippet.

```
Jun 28 15:31:12 busch /usr/sbin/kamailio[29961]: INFO: 

Re: [sr-dev] [kamailio/kamailio] app_lua: add "NOTICE" loglevel to sr.log (#1162)

[Sebastian Damm]

Okay, then I'll leave it there. I added a comment providing the information 
about a replacement in the future by KEMI.

-- 
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/1162#issuecomment-310619739___
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] app_lua: add "NOTICE" loglevel to sr.log (#1162)

[Sebastian Damm]

@miconda Can you backport that to 5.0, too? And is there a 5.0 equivalent to 
this page?
 https://www.kamailio.org/wiki/embeddedapi/4.0.x/lua
I would add the new log level here: 
https://www.kamailio.org/wiki/embeddedapi/devel/lua

-- 
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/1162#issuecomment-310596735___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] git:master:c2a27bc0: app_lua: add "NOTICE" loglevel to sr.log

[Sebastian Damm]

Module: kamailio
Branch: master
Commit: c2a27bc0875aaaec877c75e9b50fbf41011918b1
URL: 
https://github.com/kamailio/kamailio/commit/c2a27bc0875aaaec877c75e9b50fbf41011918b1

Author: Sebastian Damm <d...@sipgate.de>
Committer: Sebastian Damm <d...@sipgate.de>
Date: 2017-06-22T16:22:49+02:00

app_lua: add "NOTICE" loglevel to sr.log

---

Modified: src/modules/app_lua/app_lua_sr.c

---

Diff:  
https://github.com/kamailio/kamailio/commit/c2a27bc0875aaaec877c75e9b50fbf41011918b1.diff
Patch: 
https://github.com/kamailio/kamailio/commit/c2a27bc0875aaaec877c75e9b50fbf41011918b1.patch

---

diff --git a/src/modules/app_lua/app_lua_sr.c b/src/modules/app_lua/app_lua_sr.c
index d23ddaca70..f999de3e37 100644
--- a/src/modules/app_lua/app_lua_sr.c
+++ b/src/modules/app_lua/app_lua_sr.c
@@ -96,6 +96,8 @@ static int lua_sr_log (lua_State *L)
LM_DBG("%s", txt);
} else if(strcasecmp(level, "info")==0) {
LM_INFO("%s", txt);
+   } else if(strcasecmp(level, "notice")==0) {
+   LM_NOTICE("%s", txt);
} else if(strcasecmp(level, "warn")==0) {
LM_WARN("%s", txt);
} else if(strcasecmp(level, "crit")==0) {


___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] git:5.0:9abd1e00: rabbitmq: don't create reply-to queue on publish

[Sebastian Damm]

Module: kamailio
Branch: 5.0
Commit: 9abd1e002e0b3f7a884093e7e76efc8afdd54a17
URL: 
https://github.com/kamailio/kamailio/commit/9abd1e002e0b3f7a884093e7e76efc8afdd54a17

Author: Sebastian Damm <d...@sipgate.de>
Committer: Sebastian Damm <d...@sipgate.de>
Date: 2017-05-12T15:34:39+02:00

rabbitmq: don't create reply-to queue on publish

When using the rabbitmq_publish function, there is no need to create
a reply to queue, because it will never be read. And since there is
never a real consumer, so the queue will never be deleted. This
will eventually cloak up the RabbitMQ server with millions of
generic reply queues.
This bug has been fixed in master already, so this is basically a
backport.

---

Modified: src/modules/rabbitmq/rabbitmq.c

---

Diff:  
https://github.com/kamailio/kamailio/commit/9abd1e002e0b3f7a884093e7e76efc8afdd54a17.diff
Patch: 
https://github.com/kamailio/kamailio/commit/9abd1e002e0b3f7a884093e7e76efc8afdd54a17.patch

---

diff --git a/src/modules/rabbitmq/rabbitmq.c b/src/modules/rabbitmq/rabbitmq.c
index 4cd69c9..05fa750 100644
--- a/src/modules/rabbitmq/rabbitmq.c
+++ b/src/modules/rabbitmq/rabbitmq.c
@@ -175,7 +175,6 @@ static int rabbitmq_publish(struct sip_msg* msg, char* 
in_exchange, char* in_rou
int reconnect_attempts = 0;
int log_ret;
str exchange, routingkey, messagebody, contenttype;
-   amqp_bytes_t reply_to_queue;
 
// sanity checks
if (get_str_fparam(, msg, (fparam_t*)in_exchange) < 0) {
@@ -231,44 +230,13 @@ static int rabbitmq_publish(struct sip_msg* msg, char* 
in_exchange, char* in_rou
return RABBITMQ_ERR_CHANNEL;
}
 
-   // alloc queue
-   amqp_queue_declare_ok_t *r = amqp_queue_declare(conn, 1, 
amqp_empty_bytes, 0, 0, 0, 1, amqp_empty_table);
-   if (log_on_amqp_error(amqp_get_rpc_reply(conn), "amqp_queue_declare()") 
!= AMQP_RESPONSE_NORMAL) {
-   LM_ERR("FAIL: amqp_queue_declare()\n");
-   amqp_channel_close(conn, 1, AMQP_REPLY_SUCCESS);
-   return RABBITMQ_ERR_QUEUE;
-   }
-
-   // alloc bytes
-   reply_to_queue = amqp_bytes_malloc_dup(r->queue);
-   LM_DBG("%.*s\n", (int)reply_to_queue.len, (char*)reply_to_queue.bytes);
-   if (reply_to_queue.bytes == NULL) {
-   amqp_channel_close(conn, 1, AMQP_REPLY_SUCCESS);
-   amqp_bytes_free(reply_to_queue);
-   LM_ERR("Out of memory while copying queue name");
-   return -1;
-   }
-
// alloc properties
amqp_basic_properties_t props;
props._flags = AMQP_BASIC_CONTENT_TYPE_FLAG |
AMQP_BASIC_DELIVERY_MODE_FLAG |
-   AMQP_BASIC_REPLY_TO_FLAG |
AMQP_BASIC_CORRELATION_ID_FLAG;
props.content_type = amqp_cstring_bytes(contenttype.s);
props.delivery_mode = 2; /* persistent delivery mode */
-   props.reply_to = amqp_bytes_malloc_dup(reply_to_queue);
-   if (props.reply_to.bytes == NULL) {
-   // debug
-   LM_ERR("Out of memory while copying queue name");
-
-   // cleanup
-   amqp_channel_close(conn, 1, AMQP_REPLY_SUCCESS);
-   amqp_bytes_free(reply_to_queue);
-
-   // error
-   return -1;
-   }
props.correlation_id = amqp_cstring_bytes("1");
 
// publish
@@ -285,7 +253,6 @@ static int rabbitmq_publish(struct sip_msg* msg, char* 
in_exchange, char* in_rou
 
// cleanup
amqp_channel_close(conn, 1, AMQP_REPLY_SUCCESS);
-   amqp_bytes_free(reply_to_queue);
 
// error
return RABBITMQ_ERR_PUBLISH;
@@ -295,8 +262,6 @@ static int rabbitmq_publish(struct sip_msg* msg, char* 
in_exchange, char* in_rou
LM_DBG("SUCCESS: amqp_basic_publish()\n");
 
// cleanup
-   amqp_bytes_free(props.reply_to);
-   amqp_bytes_free(reply_to_queue);
amqp_channel_close(conn, 1, AMQP_REPLY_SUCCESS);
 
// success


___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] [kamailio/kamailio] rabbitmq: create reply-to queue w/ exclusive param (#1129)

[Sebastian Damm]

RabbitMQ docs say, temporary reply-to queues should be created
with an "exclusive" parameter. This allows only the current
connection to access the queue, and when the connection ends,
the queue will automatically be deleted.
You can view, comment on, or merge this pull request online at:

  https://github.com/kamailio/kamailio/pull/1129

-- Commit Summary --

  * rabbitmq: create reply-to queue w/ exclusive param

-- File Changes --

M src/modules/rabbitmq/rabbitmq.c (4)

-- Patch Links --

https://github.com/kamailio/kamailio/pull/1129.patch
https://github.com/kamailio/kamailio/pull/1129.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/1129
___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] [kamailio/kamailio] Installation broken because of commented out mpath in example config (#1096)

[Sebastian Damm]

### Description

When installing Kamailio on a new system, Kamailio can't start because it 
doesn't know where to load the modules from. This is at least when installing 
from Debian packages.

### Troubleshooting

 Reproduction

Install Kamailio on a new system from the official Debian packages (v.5.0, v4.4 
is unaffected). dpkg will fail in configure phase because the Kamailio config 
is invalid and thus it can't be started.

### Possible Solutions

After enabling the commented out mpath line in the example configuration file, 
the installation succeeds.

There is a pull request fixing the issue:
https://github.com/kamailio/kamailio/pull/1095

### Additional Information

  * **Kamailio Version** - output of `kamailio -v`

```
version: kamailio 5.0.1 (x86_64/linux)
flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, DISABLE_NAGLE, 
USE_MCAST, DNS_IP_HACK, SHM_MEM, 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_LISTEN 16, 
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 4.9.2
```

* **Operating System**:

```
Debian Jessie Linux 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) 
x86_64 GNU/Linux
```


-- 
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/1096___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] [kamailio/kamailio] pkg/debian: Fix installation issue by enabling mpath line in example config (#1095)

[Sebastian Damm]

When installing a new Kamailio from debian packages, dpkg will fail because
Kamailio can't load any modules, resulting in a broken apt state. This is 
because
the "mpath" line in the example config is commented out. Enabling this line 
fixes
the install problem.
Tested on Debian Jessie.
You can view, comment on, or merge this pull request online at:

  https://github.com/kamailio/kamailio/pull/1095

-- Commit Summary --

  * Set module path in kamailio.cfg

-- File Changes --

M etc/kamailio.cfg (2)

-- Patch Links --

https://github.com/kamailio/kamailio/pull/1095.patch
https://github.com/kamailio/kamailio/pull/1095.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/1095
___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev