### Description
during sipp "tls caller and tls callee" test, do tls.reload repeatedly, the sipp tls connection will be disconnected and tls.reload will report error and can not be recovered
### Troubleshooting
#### Reproduction
(1)write a simple request_route logic in kamailio.cfg, as follows:
request_route {
add_local_rport();
$du = "sip:192.168.131.190:1001;transport=tls";
forward();
}
(2)start sipp caller to kamailio tls:0.0.0.0:5061 and kamailio will relay this request to callee
(3)at the same time, in another console, run the following cmds:
((i = 0)); while true; do /opt/kamailio/sbin/kamcmd tls.reload && echo $i && ((i = i+1)); done;
#### Debugging Data
None
#### Log Messages
tls.reload will report the following error, and it can not work again until kamailio is restarted:
error: 500 - Error while loading TLS configuration file (consult server log)
at the same time, sipp tls connection is disconnected by kamailio, some error is shown in the kamailo.log:
--------------------------------------------------------------------------------------------------------
Dec 14 10:59:54 localhost sipproxy[64723]: ERROR: tls [tls_server.c:1330]: tls_h_read_f(): protocol level error
Dec 14 10:59:54 localhost sipproxy[64723]: ERROR: tls [tls_server.c:1334]: tls_h_read_f(): src addr: 192.168.131.190:59545
Dec 14 10:59:54 localhost sipproxy[64723]: ERROR: tls [tls_server.c:1337]: tls_h_read_f(): dst addr: 192.168.131.190:5061
Dec 14 10:59:54 localhost sipproxy[64723]: ERROR: <core> [core/tcp_read.c:1478]: tcp_read_req(): ERROR: tcp_read_req: error reading - c: 0x7f3f67c89ba8 r: 0x7f3f67c89cd0 (-1)
--------------------------------------------------------------------------------------------------------
#### SIP Traffic
<!--
If the issue is exposed by processing specific SIP messages, grab them with ngrep or save in a pcap file, then add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site).
-->
```
```
### Possible Solutions
<!--
If you found a solution or workaround for the issue, describe it. Ideally, provide a pull request with a fix.
-->
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
version: kamailio 5.6.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, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: unknown
compiled on 10:03:56 Dec 14 2022 with gcc 4.9.4
```
* **Operating System**:
<!--
Details about the operating system, the type: Linux (e.g.,: Debian 8.4, Ubuntu 16.04, CentOS 7.1, ...), MacOS, xBSD, Solaris, ...;
Kernel details (output of `lsb_release -a` and `uname -a`)
-->
```
Linux localhost.localdomain 3.10.0-327.el7.x86_64 #1 SMP Thu Nov 19 22:10:57 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3305
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3305(a)github.com>
### Description
The permissions module has two reload RPC commands, `permissions.addressReload` which reloads the `address` table, and `permissions.trustedReload`, which reloads the `trusted` table.
The module parameter `reload_delta` exists to prevent concurrent reloading of a single table:
> ##### 3.25. reload_delta (int)
> The number of seconds that have to be waited before executing a new RPC reload. By default there is a rate limiting of maximum one reload in five seconds.
>
> If set to 0, no rate limit is configured. Note carefully: use this configuration only in tests environments because executing two RPC reloads of the same table at the same time can cause to kamailio to crash.
If one of the reload rpc commands is issues (i.e. `permissions.addressReload`), then the OTHER reload command (`permissions.trustedReload`) will be blocked, despite acting against two separate tables.
### Troubleshooting
Reproduced the issue.
#### Reproduction
_(DB config for permissions module omitted for brevity)_
```
loadmodule "rtimer.so"
loadmodule "permissions.so"
loadmodule "jsonrpcs"
modparamx("rtimer", "timer", "name=permissions_reload;mode=0;interval=300")
modparam("rtimer", "exec", "timer=permissions_reload;route=RELOAD_PERMISSIONS")
route[RELOAD_PERMISSIONS] {
xnotice("Reloading trusted records\n");
jsonrpc_exec('{"jsonrpc": "2.0", "method": "permissions.trustedReload", "id": 1}');
xalert("jsonrpc response code: $jsonrpl(code) - the body is: $jsonrpl(body)\n");
xnotice("Reloading addresses\n");
jsonrpc_exec('{"jsonrpc": "2.0", "method": "permissions.addressReload", "id": 1}');
xalert("jsonrpc response code: $jsonrpl(code) - the body is: $jsonrpl(body)\n");
}
```
#### Debugging Data
The above config yields output like this:
```
2(8) NOTICE: <script>: Reloading trusted records
2(8) ALERT: <script>: jsonrpc response code: 200 - the body is: {
"jsonrpc": "2.0",
"result": "Reload OK",
"id": 1
}
2(8) NOTICE: <script>: Reloading addresses
2(8) ERROR: permissions [rpc.c:42]: rpc_check_reload(): ongoing reload
2(8) ALERT: <script>: jsonrpc response code: 500 - the body is: {
"jsonrpc": "2.0",
"error": {
"code": 500,
"message": "ongoing reload"
},
"id": 1
}
```
### Possible Solutions
Ideally each reload would be tracked separately. This could possibly involve separate `reload_delta` parameters for each table (although it seems excessive to change the interface).
It's also possible that this behavior is by design, in which case, clarification of the documentation for the `reload_delta` parameter would be nice.
### Additional Information
Problem occurs in kamailio 5.6.2. Likely within all version since the `reload_delta` parameter was added.
* **Operating System**:
Tested in Alpine, but OS seems irrelevant.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3318
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3318(a)github.com>
Dear Kamailians!
I’m trying to figure out DMQ and see how it reacts to server outages and downtime - the base protocol.
I’ve configured three nodes on different ports and run them locally. All have the others as notification peers plus one that is disabled.
They are configured like this with transport:
modparam("dmq", "notification_address", "sip:192.168.40.107:5060;transport=udp")
It quickly turns out that DMQ has every node twice - when sending ut “notification_peer” messages, it sends all six.
KDMQ sip:notification_peer@192.168.40.107:5070 SIP/2.0
Via: SIP/2.0/UDP 192.168.40.107:5080;branch=z9hG4bK96bc.875f2460000000000000000000000000.0
To: <sip:notification_peer@192.168.40.107:5070>
From: <sip:notification_peer@192.168.40.107:5080>;tag=e0f3ecb7441aaf62d1734fc723545165-9deb0be2
CSeq: 10 KDMQ
Call-ID: 0024de987491cd3e-30304(a)192.168.40.107
Content-Length: 234
User-agent: Kamailio Server 02 DMQtest
Max-Forwards: 1
Content-Type: text/plain
sip:192.168.40.107:5080;status=active
sip:192.168.40.107:5060;status=active
sip:192.168.40.107:5090;status=active
sip:192.168.40.107:5090;status=active
sip:192.168.40.107:5060;status=active
sip:192.168.40.107:5080;status=active
When I shut down one, it sends out a “disabled notification” where the other nodes responds that the other (copy) on the same IP/port is still active.
Looking into dmq with kamctl I see that three have transport “udp” and three have transport “*” (asterisk).
I don’t see transport being given as parameter in the notification_peer messages.
It seems to me like there’s a bug in here somewhere. Or is this the way it’s supposed to work?
/O
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/3313
-- Commit Summary --
* core: typos - succesSful
* misc/examples: update comments
* auth: typo statefulLy
* ims_auth: typo succesSful
* ims_registrar_pcscf: typo successfulLy
* keepalive: typo unsuccesSful
* nathelper: typo statefulLy
* pipelimit: typo unsuccesSful
* ratelimit: typo unsuccesSful
* snmpstats: typo unsuccesSful
* test/misc: typo sucesSful
* tls: typo succesSfulLy
* tls_wolfssl: type succesSfulLy
* uid_avp_db: typo succesSful
-- File Changes --
M misc/examples/kamailio/acc.cfg (2)
M misc/examples/mixed/acc.cfg (2)
M misc/examples/mixed/uas.cfg (2)
M misc/examples/obsoleted/backup.cfg (2)
M misc/examples/obsoleted/test.cfg (2)
M misc/examples/obsoleted/tmtest.cfg (2)
M src/core/tcp_main.c (2)
M src/modules/auth/auth.xml (2)
M src/modules/ims_auth/sip_messages.h (2)
M src/modules/ims_registrar_pcscf/save.c (2)
M src/modules/keepalive/doc/keepalive_admin.xml (2)
M src/modules/nathelper/examples/nathelper.cfg (2)
M src/modules/nathelper/examples/nathelper_rtpp.cfg (2)
M src/modules/pipelimit/pl_statistics.c (2)
M src/modules/ratelimit/rl_statistics.c (2)
M src/modules/snmpstats/snmp_statistics.c (2)
M src/modules/tls/tls_server.c (2)
M src/modules/tls_wolfssl/tls_server.c (2)
M src/modules/uid_avp_db/README (2)
M src/modules/uid_avp_db/doc/avp_dialogs.cfg (2)
M test/misc/cfg/acc-test.cfg (4)
M test/misc/cfg/sf.cfg (2)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/3313.patchhttps://github.com/kamailio/kamailio/pull/3313.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/3313
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/3313(a)github.com>
It is unlikely that this patch solves any eventual issues that you had.
You changed the comparison of a pointer with NULL to 0 and, in C, NULL
and 0 are the same in context of pointers:
- https://c-faq.com/null/nullor0.html
So practically there is not change in behaviour.
Cheers,
Daniel
On 21.12.22 15:41, Olle E. Johansson wrote:
> I suggest that this patch be backported :-)
>
> Cheers,
> /O
>
>> Begin forwarded message:
>>
>> *From: *Olle E. Johansson <oej(a)edvina.net>
>> *Subject: **[sr-dev] git:master:5c90e6e2: DMQ:
>> dmq_notification_address_list is initialized to NULL*
>> *Date: *21 December 2022 at 15:27:49 CET
>> *To: *sr-dev(a)lists.kamailio.org
>> *Reply-To: *"Kamailio (SER) - Development Mailing List"
>> <sr-dev(a)lists.kamailio.org>
>>
>> Module: kamailio
>> Branch: master
>> Commit: 5c90e6e2885a60a1dc5de5ff697c93d6fe59a9cb
>> URL:
>> https://github.com/kamailio/kamailio/commit/5c90e6e2885a60a1dc5de5ff697c93d…
>>
>> Author: Olle E. Johansson <oej(a)edvina.net>
>> Committer: Olle E. Johansson <oej(a)edvina.net>
>> Date: 2022-12-21T15:27:28+01:00
>>
>> DMQ: dmq_notification_address_list is initialized to NULL
>>
>> This code led to random and unpredictable behaviour when loading a
>> configuration with
>> multiple notification nodes.
>>
>> ---
>>
>> Modified: src/modules/dmq/dmq.c
>>
>> ---
>>
>> Diff:
>> https://github.com/kamailio/kamailio/commit/5c90e6e2885a60a1dc5de5ff697c93d…
>> Patch:
>> https://github.com/kamailio/kamailio/commit/5c90e6e2885a60a1dc5de5ff697c93d…
>>
>> ---
>>
>> diff --git a/src/modules/dmq/dmq.c b/src/modules/dmq/dmq.c
>> index 843b7e3e4d2..f4a66c3d847 100644
>> --- a/src/modules/dmq/dmq.c
>> +++ b/src/modules/dmq/dmq.c
>> @@ -379,7 +379,7 @@ static int
>> dmq_add_notification_address(modparam_t type, void * val)
>> }
>>
>> /* initial allocation */
>> -if (dmq_notification_address_list == 0) {
>> +if (dmq_notification_address_list == NULL) {
>> dmq_notification_address_list = pkg_malloc(sizeof(str_list_t));
>> if (dmq_notification_address_list == NULL) {
>> PKG_MEM_ERROR;
>>
>> _______________________________________________
>> Kamailio (SER) - Development Mailing List
>> To unsubscribe send an email to sr-dev-leave(a)lists.kamailio.org
>
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda