[sr-dev] Re: [kamailio/kamailio] tm: add mandatory Max-Forwards header to local AC (3a34b46)
Victor Seva via sr-dev writes: > @juha-h please use ``cherry-pick -x `` when back-porting I used `git cherry-pick . This gets too complicated for me so better that I leave the git stuff to those who know. ___ Kamailio (SER) - Development Mailing List To unsubscribe send an email to sr-dev-le...@lists.kamailio.org
[sr-dev] git:5.8:3a34b468: tm: add mandatory Max-Forwards header to local AC
Module: kamailio Branch: 5.8 Commit: 3a34b468ad93904c507bd0fc7ef592b25321807f URL: https://github.com/kamailio/kamailio/commit/3a34b468ad93904c507bd0fc7ef592b25321807f Author: Juha Heinanen Committer: Juha Heinanen Date: 2024-05-20T19:54:45+03:00 tm: add mandatory Max-Forwards header to local AC --- Modified: src/modules/tm/t_msgbuilder.c --- Diff: https://github.com/kamailio/kamailio/commit/3a34b468ad93904c507bd0fc7ef592b25321807f.diff Patch: https://github.com/kamailio/kamailio/commit/3a34b468ad93904c507bd0fc7ef592b25321807f.patch --- diff --git a/src/modules/tm/t_msgbuilder.c b/src/modules/tm/t_msgbuilder.c index 362ff6c5eb5..1aa680aa9a4 100644 --- a/src/modules/tm/t_msgbuilder.c +++ b/src/modules/tm/t_msgbuilder.c @@ -1246,7 +1246,8 @@ char *build_dlg_ack(struct sip_msg *rpl, struct cell *Trans, /* headers */ *len += Trans->from_hdr.len + Trans->callid_hdr.len + to->len - + Trans->cseq_hdr_n.len + 1 + ACK_LEN + CRLF_LEN; + + Trans->cseq_hdr_n.len + 1 + ACK_LEN + +MAXFWD_HEADER_LEN + + CRLF_LEN; /* copy'n'paste Route headers */ @@ -1291,6 +1292,8 @@ char *build_dlg_ack(struct sip_msg *rpl, struct cell *Trans, append_str(p, Trans->callid_hdr.s, Trans->callid_hdr.len); append_str(p, to->s, to->len); + append_str(p, MAXFWD_HEADER, MAXFWD_HEADER_LEN); + append_str(p, Trans->cseq_hdr_n.s, Trans->cseq_hdr_n.len); append_str(p, " ", 1); append_str(p, ACK, ACK_LEN); ___ Kamailio (SER) - Development Mailing List To unsubscribe send an email to sr-dev-le...@lists.kamailio.org
[sr-dev] git:master:0054b875: Avoid 'qm_strnstr' defined but not used warning
Module: kamailio
Branch: master
Commit: 0054b875045b4badfedd3e8424bf4772d6a9bc6b
URL:
https://github.com/kamailio/kamailio/commit/0054b875045b4badfedd3e8424bf4772d6a9bc6b
Author: Juha Heinanen
Committer: Juha Heinanen
Date: 2024-03-12T22:18:20+02:00
Avoid 'qm_strnstr' defined but not used warning
---
Modified: src/core/mem/q_malloc.c
---
Diff:
https://github.com/kamailio/kamailio/commit/0054b875045b4badfedd3e8424bf4772d6a9bc6b.diff
Patch:
https://github.com/kamailio/kamailio/commit/0054b875045b4badfedd3e8424bf4772d6a9bc6b.patch
---
diff --git a/src/core/mem/q_malloc.c b/src/core/mem/q_malloc.c
index aa68debdf30..5850c07a018 100644
--- a/src/core/mem/q_malloc.c
+++ b/src/core/mem/q_malloc.c
@@ -993,6 +993,7 @@ void qm_status(void *qmp)
}
+#ifdef DBG_QM_MALLOC
static void *qm_strnstr(const void *b1, int l1, const void *b2, int l2)
{
char *sp = (char *)b1;
@@ -1012,6 +1013,7 @@ static void *qm_strnstr(const void *b1, int l1, const
void *b2, int l2)
return NULL;
}
+#endif
void qm_status_filter(void *qmp, str *fmatch, FILE *fp)
{
___
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-le...@lists.kamailio.org
[sr-dev] git:5.8:2122afae: Avoid 'qm_strnstr' defined but not used warning
Module: kamailio
Branch: 5.8
Commit: 2122afae2a6604c0bc44a43ab37ee274a15a700a
URL:
https://github.com/kamailio/kamailio/commit/2122afae2a6604c0bc44a43ab37ee274a15a700a
Author: Juha Heinanen
Committer: Juha Heinanen
Date: 2024-03-12T22:16:23+02:00
Avoid 'qm_strnstr' defined but not used warning
---
Modified: src/core/mem/q_malloc.c
---
Diff:
https://github.com/kamailio/kamailio/commit/2122afae2a6604c0bc44a43ab37ee274a15a700a.diff
Patch:
https://github.com/kamailio/kamailio/commit/2122afae2a6604c0bc44a43ab37ee274a15a700a.patch
---
diff --git a/src/core/mem/q_malloc.c b/src/core/mem/q_malloc.c
index aa68debdf30..5850c07a018 100644
--- a/src/core/mem/q_malloc.c
+++ b/src/core/mem/q_malloc.c
@@ -993,6 +993,7 @@ void qm_status(void *qmp)
}
+#ifdef DBG_QM_MALLOC
static void *qm_strnstr(const void *b1, int l1, const void *b2, int l2)
{
char *sp = (char *)b1;
@@ -1012,6 +1013,7 @@ static void *qm_strnstr(const void *b1, int l1, const
void *b2, int l2)
return NULL;
}
+#endif
void qm_status_filter(void *qmp, str *fmatch, FILE *fp)
{
___
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-le...@lists.kamailio.org
[sr-dev] git:5.8:1928af8f: core: set null-terminated char for modparam (backport from master)
Module: kamailio Branch: 5.8 Commit: 1928af8f90ebf02f610c0904bc3d24a00aaedb81 URL: https://github.com/kamailio/kamailio/commit/1928af8f90ebf02f610c0904bc3d24a00aaedb81 Author: Juha Heinanen Committer: Juha Heinanen Date: 2024-03-12T07:54:50+02:00 core: set null-terminated char for modparam (backport from master) --- Modified: src/core/modparam.c --- Diff: https://github.com/kamailio/kamailio/commit/1928af8f90ebf02f610c0904bc3d24a00aaedb81.diff Patch: https://github.com/kamailio/kamailio/commit/1928af8f90ebf02f610c0904bc3d24a00aaedb81.patch --- diff --git a/src/core/modparam.c b/src/core/modparam.c index 46ea0169e53..b48d9e82442 100644 --- a/src/core/modparam.c +++ b/src/core/modparam.c @@ -152,6 +152,7 @@ int set_mod_param_regex(char *regex, char *name, modparam_t type, void *val) return -1; } strncpy(*((char **)ptr), (char *)val2, len_param); + (*((char **)ptr))[len_param] = '\0'; break; case PARAM_STR: ___ Kamailio (SER) - Development Mailing List To unsubscribe send an email to sr-dev-le...@lists.kamailio.org
[sr-dev] Re: git:master:1acede64: core: added tcp_check_timer parameter
How about the diff below?
Also, is there plan to backport ksr_tcp_msg_data_timeout,
ksr_tcp_msg_read_timeout, and ksr_tcp_check_timer to 5.7, since they can
help in protecting from DoS attacks that we have seen in the wild.
-- Juha
diff --git a/src/main.c b/src/main.c
index 0fa2da6ec2..f3cddf8bad 100644
--- a/src/main.c
+++ b/src/main.c
@@ -535,7 +535,7 @@ int ksr_tcp_msg_read_timeout = 20; /* timeout (secs) to
read SIP message */
int ksr_tcp_msg_data_timeout =
20; /* timeout (secs) to receive first msg data */
int ksr_tcp_accept_iplimit = 1024; /* limit of accepted connections per IP */
-int ksr_tcp_check_timer = 10; /* seconds to check tcp connections */
+int ksr_tcp_check_timer = -1; /* seconds to check tcp connections */
/* memory manager */
#define SR_MEMMNG_DEFAULT "qm"
@@ -1726,12 +1726,22 @@ int main_loop(void)
cfg_main_reset_local();
#ifdef USE_TCP
- if(!tcp_disable && ksr_tcp_check_timer > 0) {
- if(sr_wtimer_add(
+ if(!tcp_disable) {
+ if(ksr_tcp_check_timer == -1) {
+ if(ksr_tcp_msg_data_timeout > 0 &&
ksr_tcp_msg_read_timeout > 0)
+ ksr_tcp_check_timer =
+ MIN(ksr_tcp_msg_data_timeout,
ksr_tcp_msg_read_timeout) / 2;
+ else
+ ksr_tcp_check_timer =
ksr_tcp_msg_data_timeout > 0 ?
+ ksr_tcp_msg_data_timeout / 2 :
ksr_tcp_msg_read_timeout / 2;
+ }
+ if(ksr_tcp_check_timer > 0) {
+ if(sr_wtimer_add(
tcp_timer_check_connections, NULL,
ksr_tcp_check_timer)
- < 0) {
- LM_CRIT("cannot add timer for tcp connection
checks\n");
- goto error;
+ < 0) {
+ LM_CRIT("cannot add timer for tcp
connection checks\n");
+ goto error;
+ }
}
}
#endif
___
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-le...@lists.kamailio.org
[sr-dev] Re: git:master:1acede64: core: added tcp_check_timer parameter
Daniel-Constantin Mierla writes: > > In order to make configuration simpler, how about having a dynamic default > > as I suggested? > > Default is half (hardcoded), but its own parameter gives more > flexibility for granularity -- one extra parameter is not adding much > complexity, imo, and case by case one may want more often checks to > clean up those that end up in timeout. I didn't suggest to remove the parameter, but change its default value if the parameter is not given. ___ Kamailio (SER) - Development Mailing List To unsubscribe send an email to sr-dev-le...@lists.kamailio.org
[sr-dev] Re: git:master:1acede64: core: added tcp_check_timer parameter
Daniel-Constantin Mierla writes: > Smaller is recommended for better accuracy. In order to make configuration simpler, how about having a dynamic default as I suggested? ___ Kamailio (SER) - Development Mailing List To unsubscribe send an email to sr-dev-le...@lists.kamailio.org
[sr-dev] Re: git:master:1acede64: core: added tcp_check_timer parameter
If so, how about defaulting to half of tcp_msg_read_timeout or tcp_msg_data_timeout whichever is smallest? ___ Kamailio (SER) - Development Mailing List To unsubscribe send an email to sr-dev-le...@lists.kamailio.org
[sr-dev] git:master:1acede64: core: added tcp_check_timer parameter
Daniel-Constantin Mierla via sr-dev writes: > core: added tcp_check_timer parameter > > - set the check interval (in seconds) for tcp connections > - default 10 Does this need to be smaller than tcp_msg_read_timeout and tcp_msg_data_timeout in order for them to have effect? ___ Kamailio (SER) - Development Mailing List To unsubscribe send an email to sr-dev-le...@lists.kamailio.org
[sr-dev] Re: [kamailio/kamailio] build warnings on bookworm (Issue #3484)
Victor Seva writes:
> @juha-h can you please test https://github.com/kamailio/kamailio/pull/3482?
> At least the OPENSSL_fork_* warnings should be solved.
I gave the PR a try and now got the warnings below (no fork warnings
anymore).
-- Juha
tls_mod.c: In function 'ksr_rand_engine_param':
tls_mod.c:520:17: warning: 'RAND_set_rand_method' is deprecated: Since OpenSSL
3.0 [-Wdeprecated-declarations]
520 | RAND_set_rand_method(RAND_ksr_krand_method());
| ^~~~
In file included from tls_rand.h:26,
from tls_mod.c:54:
/usr/include/openssl/rand.h:49:27: note: declared here
49 | OSSL_DEPRECATEDIN_3_0 int RAND_set_rand_method(const RAND_METHOD *meth);
| ^~~~
tls_mod.c:523:17: warning: 'RAND_set_rand_method' is deprecated: Since OpenSSL
3.0 [-Wdeprecated-declarations]
523 | RAND_set_rand_method(RAND_ksr_fastrand_method());
| ^~~~
/usr/include/openssl/rand.h:49:27: note: declared here
49 | OSSL_DEPRECATEDIN_3_0 int RAND_set_rand_method(const RAND_METHOD *meth);
| ^~~~
tls_mod.c:526:17: warning: 'RAND_set_rand_method' is deprecated: Since OpenSSL
3.0 [-Wdeprecated-declarations]
526 | RAND_set_rand_method(RAND_ksr_cryptorand_method());
| ^~~~
/usr/include/openssl/rand.h:49:27: note: declared here
49 | OSSL_DEPRECATEDIN_3_0 int RAND_set_rand_method(const RAND_METHOD *meth);
| ^~~~
tls_mod.c:529:17: warning: 'RAND_set_rand_method' is deprecated: Since OpenSSL
3.0 [-Wdeprecated-declarations]
529 | RAND_set_rand_method(RAND_ksr_kxlibssl_method());
| ^~~~
/usr/include/openssl/rand.h:49:27: note: declared here
49 | OSSL_DEPRECATEDIN_3_0 int RAND_set_rand_method(const RAND_METHOD *meth);
| ^~~~
tls_mod.c: In function 'mod_register':
tls_mod.c:680:9: warning: 'RAND_set_rand_method' is deprecated: Since OpenSSL
3.0 [-Wdeprecated-declarations]
680 | RAND_set_rand_method(RAND_ksr_cryptorand_method());
| ^~~~
/usr/include/openssl/rand.h:49:27: note: declared here
49 | OSSL_DEPRECATEDIN_3_0 int RAND_set_rand_method(const RAND_METHOD *meth);
| ^~~~
tls_mod.c: In function 'tls_engine_init':
tls_mod.c:715:9: warning: 'ENGINE_by_id' is deprecated: Since OpenSSL 3.0
[-Wdeprecated-declarations]
715 | e = ENGINE_by_id("dynamic");
| ^
In file included from tls_mod.c:154:
/usr/include/openssl/engine.h:336:31: note: declared here
336 | OSSL_DEPRECATEDIN_3_0 ENGINE *ENGINE_by_id(const char *id);
| ^~~~
tls_mod.c:734:9: warning: 'ENGINE_ctrl_cmd_string' is deprecated: Since OpenSSL
3.0 [-Wdeprecated-declarations]
734 | if(!ENGINE_ctrl_cmd_string(e, "SO_PATH",
| ^~
/usr/include/openssl/engine.h:479:5: note: declared here
479 | int ENGINE_ctrl_cmd_string(ENGINE *e, const char *cmd_name, const char
*arg,
| ^~
tls_mod.c:739:9: warning: 'ENGINE_ctrl_cmd_string' is deprecated: Since OpenSSL
3.0 [-Wdeprecated-declarations]
739 | if(!ENGINE_ctrl_cmd_string(e, "ID", engine_id, 0)) {
| ^~
/usr/include/openssl/engine.h:479:5: note: declared here
479 | int ENGINE_ctrl_cmd_string(ENGINE *e, const char *cmd_name, const char
*arg,
| ^~
tls_mod.c:743:9: warning: 'ENGINE_ctrl_cmd' is deprecated: Since OpenSSL 3.0
[-Wdeprecated-declarations]
743 | if(!ENGINE_ctrl_cmd(e, "LOAD", 1, NULL, NULL, 0)) {
| ^~
/usr/include/openssl/engine.h:450:27: note: declared here
450 | OSSL_DEPRECATEDIN_3_0 int ENGINE_ctrl_cmd(ENGINE *e, const char
*cmd_name,
| ^~~
tls_mod.c:752:17: warning: 'ENGINE_ctrl_cmd_string' is deprecated: Since
OpenSSL 3.0 [-Wdeprecated-declarations]
752 | if(!ENGINE_ctrl_cmd_string(e, confval->name,
confval->value, 0)) {
| ^~
/usr/include/openssl/engine.h:479:5: note: declared here
479 | int ENGINE_ctrl_cmd_string(ENGINE *e, const char *cmd_name, const char
*arg,
| ^~
tls_mod.c:758:9: warning: 'ENGINE_init' is deprecated: Since OpenSSL 3.0
[-Wdeprecated-declarations]
758 | if(!ENGINE_init(e)) {
| ^~
/usr/include/openssl/engine.h:620:27: note: declared here
620 | OSSL_DEPRECATEDIN_3_0 int ENGINE_init(ENGINE *e);
| ^~~
tls_mod.c:763:17: warning: 'ENGINE_set_default_string' is deprecated: Since
OpenSSL 3.0 [-Wdeprecated-declarations]
763 | rc = ENGINE_set_default_string(
[sr-dev] build warnings on bookworm
Kamailio 5.7 build on Debian Bookworm gave me the following build warnings. The only curl related build dependency that I have is libcurl4-openssl-dev and the only openssl related build dependency is libssl-dev. -- Juha -- CC (gcc) [M http_client.so] functions.o functions.c: In function 'curL_request_url': functions.c:158:9: warning: 'CURLOPT_PROTOCOLS' is deprecated: since 7.85.0. Use CURLOPT_PROTOCOLS_STR [-Wdeprecated-declarations] 158 | res = curl_easy_setopt( | ^~~ In file included from http_client.h:36, from functions.c:45: /usr/include/x86_64-linux-gnu/curl/curl.h:1749:3: note: declared here 1749 | CURLOPTDEPRECATED(CURLOPT_PROTOCOLS, CURLOPTTYPE_LONG, 181, | ^ functions.c:160:9: warning: 'CURLOPT_REDIR_PROTOCOLS' is deprecated: since 7.85.0. Use CURLOPT_REDIR_PROTOCOLS_STR [-Wdeprecated-declarations] 160 | res = curl_easy_setopt( | ^~~ /usr/include/x86_64-linux-gnu/curl/curl.h:1755:3: note: declared here 1755 | CURLOPTDEPRECATED(CURLOPT_REDIR_PROTOCOLS, CURLOPTTYPE_LONG, 182, | ^ functions.c:387:17: warning: 'CURLINFO_SIZE_DOWNLOAD' is deprecated: since 7.55.0. Use CURLINFO_SIZE_DOWNLOAD_T [-Wdeprecated-declarations] 387 | curl_easy_getinfo(curl, CURLINFO_SIZE_DOWNLOAD, _size); | ^ /usr/include/x86_64-linux-gnu/curl/curl.h:2841:3: note: declared here 2841 | CURLINFO_SIZE_DOWNLOAD | ^~ CC (gcc) [M tls.so] tls_mod.o tls_mod.c: In function 'mod_child': tls_mod.c:455:25: warning: 'OPENSSL_fork_prepare' is deprecated: Since OpenSSL 3.0 [-Wdeprecated-declarations] 455 | OPENSSL_fork_prepare(); | ^~~~ In file included from /usr/include/openssl/comp.h:22, from /usr/include/openssl/ssl.h:28, from tls_init.h:30, from tls_mod.c:45: /usr/include/openssl/crypto.h:427:28: note: declared here 427 | OSSL_DEPRECATEDIN_3_0 void OPENSSL_fork_prepare(void); |^~~~ tls_mod.c:467:25: warning: 'OPENSSL_fork_parent' is deprecated: Since OpenSSL 3.0 [-Wdeprecated-declarations] 467 | OPENSSL_fork_parent(); | ^~~ /usr/include/openssl/crypto.h:428:28: note: declared here 428 | OSSL_DEPRECATEDIN_3_0 void OPENSSL_fork_parent(void); |^~~ tls_mod.c:471:25: warning: 'OPENSSL_fork_child' is deprecated: Since OpenSSL 3.0 [-Wdeprecated-declarations] 471 | OPENSSL_fork_child(); | ^~ /usr/include/openssl/crypto.h:429:28: note: declared here 429 | OSSL_DEPRECATEDIN_3_0 void OPENSSL_fork_child(void); |^~ tls_mod.c: In function 'ksr_rand_engine_param': tls_mod.c:514:17: warning: 'RAND_set_rand_method' is deprecated: Since OpenSSL 3.0 [-Wdeprecated-declarations] 514 | RAND_set_rand_method(RAND_ksr_krand_method()); | ^~~~ In file included from tls_rand.h:26, from tls_mod.c:54: /usr/include/openssl/rand.h:49:27: note: declared here 49 | OSSL_DEPRECATEDIN_3_0 int RAND_set_rand_method(const RAND_METHOD *meth); | ^~~~ tls_mod.c:517:17: warning: 'RAND_set_rand_method' is deprecated: Since OpenSSL 3.0 [-Wdeprecated-declarations] 517 | RAND_set_rand_method(RAND_ksr_fastrand_method()); | ^~~~ /usr/include/openssl/rand.h:49:27: note: declared here 49 | OSSL_DEPRECATEDIN_3_0 int RAND_set_rand_method(const RAND_METHOD *meth); | ^~~~ tls_mod.c:520:17: warning: 'RAND_set_rand_method' is deprecated: Since OpenSSL 3.0 [-Wdeprecated-declarations] 520 | RAND_set_rand_method(RAND_ksr_cryptorand_method()); | ^~~~ /usr/include/openssl/rand.h:49:27: note: declared here 49 | OSSL_DEPRECATEDIN_3_0 int RAND_set_rand_method(const RAND_METHOD *meth); | ^~~~ tls_mod.c:523:17: warning: 'RAND_set_rand_method' is deprecated: Since OpenSSL 3.0 [-Wdeprecated-declarations] 523 | RAND_set_rand_method(RAND_ksr_kxlibssl_method()); | ^~~~ /usr/include/openssl/rand.h:49:27: note: declared here 49 | OSSL_DEPRECATEDIN_3_0 int RAND_set_rand_method(const RAND_METHOD *meth); | ^~~~ tls_mod.c: In function 'mod_register': tls_mod.c:674:9: warning: 'RAND_set_rand_method' is deprecated: Since OpenSSL 3.0 [-Wdeprecated-declarations] 674 |
[sr-dev] Re: clang-format changes
I guess I missed the clang-format discussion or did it happen? Fr example, I would have voted for SpaceBeforeParens: ControlStatements -- Juha ___ Kamailio (SER) - Development Mailing List To unsubscribe send an email to sr-dev-le...@lists.kamailio.org
[sr-dev] Re: clang-format changes
Daniel-Constantin Mierla writes: > I am for it, maybe the next major release will be bumped to 6.0, so > going with clang formatting would be good because makes the readability > better. Which style? https://clang.llvm.org/docs/ClangFormatStyleOptions.html supports many: LLVM A style complying with the LLVM coding standards Google A style complying with Google’s C++ style guide Chromium A style complying with Chromium’s style guide Mozilla A style complying with Mozilla’s style guide WebKit A style complying with WebKit’s style guide Microsoft A style complying with Microsoft’s style guide GNU A style complying with the GNU coding standards -- Juha ___ Kamailio (SER) - Development Mailing List To unsubscribe send an email to sr-dev-le...@lists.kamailio.org
[sr-dev] Re: [kamailio/kamailio] lcr: crash on ki_load_gws*() if called via KEMI (Issue #3435)
Daniel-Constantin Mierla writes: > I will check it, but in general the kemi function is executed by the > native kamailio.cfg function, after it evaluates its parameters with > kamailio pseudo-variables. It is nothing specific for the kemi > function than just needing the string/int values of the parameters. For example in 5.0, the test was in correct order: https://github.com/kamailio/kamailio/blob/5.0/src/modules/lcr/lcr_mod.c I don't know what has happened since then. -- Juha ___ Kamailio (SER) - Development Mailing List To unsubscribe send an email to sr-dev-le...@lists.kamailio.org
[sr-dev] Re: compiler warnings
Daniel-Constantin Mierla writes: > Hopefully the dispatcher and jsonrpcs warnings are fixed. I guess that > local.so is a custom module, you have to change the logging/printf() > specifiers from %d to%ld because some internal fields in kamailio were > changed from int to long int for a better support of values specific to > 64b CPU architectures, which are the common nowadays. Thanks, all warnings are now gone. --- Juha ___ Kamailio (SER) - Development Mailing List To unsubscribe send an email to sr-dev-le...@lists.kamailio.org
[sr-dev] presence crash
Latest K master crashes on Debian 11 when handling SUBSCRIBE message. (Earlier messages didn't go through when there was word subscribe in subject.) -- Juha -- (gdb) bt #0 0x7f58c362cad0 in trim_leading (_s=0x7f58bceeb558) at ../../core/trim.h:59 #1 0x7f58c362cbc0 in trim (_s=0x7f58bceeb558) at ../../core/trim.h:90 #2 0x7f58c363f51c in print_callid (w=0x7f58bceed731 "", dialog=0x7f58c378c350, t=0x7f58bceeb4f0) at t_msgbuilder.c:1531 #3 0x7f58c3640d78 in build_uac_req (method=0x7ffc2c640ae0, headers=0x7ffc2c640af0, body=0x0, dialog=0x7f58c378c350, branch=0, t=0x7f58bceeb4f0, len=0x7ffc2c64023c, dst=0x7ffc2c640380) at t_msgbuilder.c:1649 #4 0x7f58c36b9e34 in t_uac_prepare (uac_r=0x7ffc2c640b40, dst_req=0x7ffc2c640498, dst_cell=0x7ffc2c6404a0) at uac.c:541 #5 0x7f58c36bd786 in t_uac_with_ids (uac_r=0x7ffc2c640b40, ret_index=0x0, ret_label=0x0) at uac.c:757 #6 0x7f58c36bd743 in t_uac (uac_r=0x7ffc2c640b40) at uac.c:739 #7 0x7f58c36c00b9 in req_within (uac_r=0x7ffc2c640b40) at uac.c:986 #8 0x7f58c2e633c7 in send_notify_request (subs=0x7ffc2c640ef0, watcher_subs=0x0, n_body=0x0, force_null_body=0) at notify.c:1727 #9 0x7f58c2e64c61 in notify (subs=0x7ffc2c640ef0, watcher_subs=0x0, n_body=0x0, force_null_body=0, aux_body_processing=0x0) at notify.c:1818 #10 0x7f58c2ef234c in update_subscription (msg=0x7f58c378a860, subs=0x7ffc2c640ef0, to_tag_gen=1, sent_reply=0x7ffc2c640e1c) at subscribe.c:685 #11 0x7f58c2efa30b in handle_subscribe (msg=0x7f58c378a860, watcher_user=..., watcher_domain=...) at subscribe.c:1222 #12 0x7f58c2ef596a in handle_subscribe0 (msg=0x7f58c378a860) at subscribe.c:999 #13 0x557db29781e3 in do_action (h=0x7ffc2c641b40, a=0x7f58c37b2c50, msg=0x7f58c378a860) at core/action.c:1081 #14 0x557db2986f7b in run_actions (h=0x7ffc2c641b40, a=0x7f58c37b2c50, msg=0x7f58c378a860) at core/action.c:1587 #15 0x557db29876e9 in run_actions_safe (h=0x7ffc2c6437e0, a=0x7f58c37b2c50, msg=0x7f58c378a860) at core/action.c:1651 #16 0x557db2b4a950 in rval_get_long (h=0x7ffc2c6437e0, msg=0x7f58c378a860, i=0x7ffc2c642058, rv=0x7f58c37b2f78, cache=0x0) at core/rvalue.c:955 --Type for more, q to quit, c to continue without paging-- #17 0x557db2b4ffbb in rval_expr_eval_long (h=0x7ffc2c6437e0, msg=0x7f58c378a860, res=0x7ffc2c642058, rve=0x7f58c37b2f70) at core/rvalue.c:1855 #18 0x557db2977c13 in do_action (h=0x7ffc2c6437e0, a=0x7f58c37b3be0, msg=0x7f58c378a860) at core/action.c:1057 #19 0x557db2986f7b in run_actions (h=0x7ffc2c6437e0, a=0x7f58c37b0f10, msg=0x7f58c378a860) at core/action.c:1587 #20 0x557db297814c in do_action (h=0x7ffc2c6437e0, a=0x7f58c37b40a0, msg=0x7f58c378a860) at core/action.c:1072 #21 0x557db2986f7b in run_actions (h=0x7ffc2c6437e0, a=0x7f58c37ab6f0, msg=0x7f58c378a860) at core/action.c:1587 #22 0x557db2974125 in do_action (h=0x7ffc2c6437e0, a=0x7f58c37ab390, msg=0x7f58c378a860) at core/action.c:705 #23 0x557db2986f7b in run_actions (h=0x7ffc2c6437e0, a=0x7f58c37ab1e0, msg=0x7f58c378a860) at core/action.c:1587 #24 0x557db29877f5 in run_top_route (a=0x7f58c37ab1e0, msg=0x7f58c378a860, c=0x0) at core/action.c:1672 #25 0x557db2afdb6a in receive_msg ( buf=0x7f58bcded648 "SUBSCRIBE sip:t...@test.tutpro.com SIP/2.0\r\nRecord-Route: \r\nRecord-Route: \r\nVia: SIP/2.0/TCP 127.0.0.1:5070;branc"..., len=749, rcv_info=0x7f58bcded2b8) at core/receive.c:515 #26 0x557db2c3ee6d in receive_tcp_msg ( tcpbuf=0x7f58bcded648 "SUBSCRIBE sip:t...@test.tutpro.com SIP/2.0\r\nRecord-Route: \r\nRecord-Route: \r\nVia: SIP/2.0/TCP 127.0.0.1:5070;branc"..., len=749, rcv_info=0x7f58bcded2b8, con=0x7f58bcded2a0) at core/tcp_read.c:1368 #27 0x557db2c419f2 in tcp_read_req (con=0x7f58bcded2a0, bytes_read=0x7ffc2c643e98, read_flags=0x7ffc2c643e9c) at core/tcp_read.c:1604 #28 0x557db2c44ef3 in handle_io (fm=0x7f58c37781f0, events=1, idx=-1) at core/tcp_read.c:1780 #29 0x557db2c30835 in io_wait_loop_epoll (h=0x557db2f102c0 , t=2, repeat=0) at core/io_wait.h:1070 #30 0x557db2c47e98 in tcp_receive_loop (unix_sock=14) at core/tcp_read.c:1976 #31 0x557db2c24ab5 in tcp_init_children (woneinit=0x7ffc2c644288) at core/tcp_main.c:5239 --Type for more, q to quit, c to continue without paging-- #32 0x557db2963531 in main_loop () at main.c:1851 #33 0x557db296e0e7 in main (argc=17, argv=0x7ffc2c644978) at main.c:3086 ___ Kamailio (SER) - Development Mailing List To unsubscribe send an email to sr-dev-le...@lists.kamailio.org
[sr-dev] compiler warnings
I'm getting a few compiler warnings when building latest master on
Debian 11.
-- Juha
---
CC (gcc) [M dispatcher.so] ds_ht.o
In file included from ../../core/mem/shm.h:43,
from ../../core/mem/shm_mem.h:32,
from ds_ht.c:25:
ds_ht.c: In function 'ds_ht_dbg':
../../core/mem/../dprint.h:321:24: warning: format '%llu' expects argument of
type 'long long unsigned int', but argument 12 has type 'long unsigned int'
[-Wformat=]
321 |fprintf(stderr, "%2d(%d) %s: %.*s%s%s%s" fmt, \
|^~~~
../../core/mem/../dprint.h:345:4: note: in expansion of macro 'LOG_FX'
345 |LOG_FX(facility, level, lname, prefix, _FUNC_NAME_, fmt, ## args)
|^~
../../core/mem/../dprint.h:351:4: note: in expansion of macro 'LOG_FL'
351 |LOG_FL(facility, level, NULL, prefix, fmt, ## args)
|^~
../../core/mem/../dprint.h:354:4: note: in expansion of macro 'LOG_FP'
354 |LOG_FP(DEFAULT_FACILITY, (level), LOC_INFO, fmt, ## args)
|^~
../../core/mem/../dprint.h:392:31: note: in expansion of macro 'LOG'
392 | # define ERR(fmt, args...)LOG(L_ERR,fmt , ## args)
| ^~~
../../core/mem/../dprint.h:418:16: note: in expansion of macro 'ERR'
418 | #define LM_ERR ERR
|^~~
ds_ht.c:337:4: note: in expansion of macro 'LM_ERR'
337 |LM_ERR("\thid: %u expire: %llu initexpire: %llu\n", it->cellid,
|^~
../../core/mem/../dprint.h:321:24: warning: format '%llu' expects argument of
type 'long long unsigned int', but argument 13 has type 'long unsigned int'
[-Wformat=]
321 |fprintf(stderr, "%2d(%d) %s: %.*s%s%s%s" fmt, \
|^~~~
../../core/mem/../dprint.h:345:4: note: in expansion of macro 'LOG_FX'
345 |LOG_FX(facility, level, lname, prefix, _FUNC_NAME_, fmt, ## args)
|^~
../../core/mem/../dprint.h:351:4: note: in expansion of macro 'LOG_FL'
351 |LOG_FL(facility, level, NULL, prefix, fmt, ## args)
|^~
../../core/mem/../dprint.h:354:4: note: in expansion of macro 'LOG_FP'
354 |LOG_FP(DEFAULT_FACILITY, (level), LOC_INFO, fmt, ## args)
|^~
../../core/mem/../dprint.h:392:31: note: in expansion of macro 'LOG'
392 | # define ERR(fmt, args...)LOG(L_ERR,fmt , ## args)
| ^~~
../../core/mem/../dprint.h:418:16: note: in expansion of macro 'ERR'
418 | #define LM_ERR ERR
|^~~
ds_ht.c:337:4: note: in expansion of macro 'LM_ERR'
337 |LM_ERR("\thid: %u expire: %llu initexpire: %llu\n", it->cellid,
|^~
---
CC (gcc) [M jsonrpcs.so]jsonrpcs_mod.o
jsonrpcs_mod.c: In function 'jsonrpc_send_mode':
jsonrpcs_mod.c:418:44: warning: format '%lld' expects argument of type 'long
long int', but argument 4 has type 'long int' [-Wformat=]
418 | snprintf(_jsonrpcs_stored_id, 62, "%lld",
(int64_t)nj->valuedouble);
| ~~~^
|| |
|| long int
|long long int
| %ld
jsonrpcs_mod.c:428:42: warning: '%s' directive output may be truncated writing
up to 63 bytes into a region of size 61 [-Wformat-truncation=]
428 | snprintf(_jsonrpcs_stored_id, 62, "\"%s\"", ctx->jsrid_val);
| ^~
jsonrpcs_mod.c:428:5: note: 'snprintf' output between 3 and 66 bytes into a
destination of size 62
428 | snprintf(_jsonrpcs_stored_id, 62, "\"%s\"", ctx->jsrid_val);
| ^~~
---
CC (gcc) [M local.so] functions.o
In file included from ../../core/mem/pkg.h:32,
from ../../core/mem/mem.h:41,
from functions.c:26:
functions.c: In function 'set_attr':
../../core/mem/../dprint.h:321:24: warning: format '%d' expects argument of
type 'int', but argument 11 has type 'long int' [-Wformat=]
321 |fprintf(stderr, "%2d(%d) %s: %.*s%s%s%s" fmt, \
|^~~~
../../core/mem/../dprint.h:345:4: note: in expansion of macro 'LOG_FX'
345 |LOG_FX(facility, level, lname, prefix, _FUNC_NAME_, fmt, ## args)
|^~
../../core/mem/../dprint.h:351:4: note: in expansion of macro 'LOG_FL'
351 |LOG_FL(facility, level, NULL, prefix, fmt, ## args)
|^~
../../core/mem/../dprint.h:354:4: note: in expansion of macro 'LOG_FP'
354 |LOG_FP(DEFAULT_FACILITY, (level), LOC_INFO, fmt, ## args)
|^~
../../core/mem/../dprint.h:392:31: note: in expansion of macro 'LOG'
392 | #
Re: [sr-dev] new master branch compiler warnings (Debian Buster)
Michael Furmur writes: > https://github.com/kamailio/kamailio/pull/2812 Thanks, Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] new master branch compiler warnings (Debian Buster)
C (gcc) [M outbound.so] outbound_mod.o outbound_mod.c: In function 'mod_init': outbound_mod.c:112:25: warning: pointer targets in passing argument 1 of 'SHA1' differ in signedness [-Wpointer-sign] SHA1(flow_token_secret.s, flow_token_secret.len, ob_key.s); ~^~ In file included from outbound_mod.c:28: /usr/include/openssl/sha.h:44:16: note: expected 'const unsigned char *' but argument is of type 'char *' unsigned char *SHA1(const unsigned char *d, size_t n, unsigned char *md); ^~~~ outbound_mod.c:112:58: warning: pointer targets in passing argument 3 of 'SHA1' differ in signedness [-Wpointer-sign] SHA1(flow_token_secret.s, flow_token_secret.len, ob_key.s); ~~^~ In file included from outbound_mod.c:28: /usr/include/openssl/sha.h:44:16: note: expected 'unsigned char *' but argument is of type 'char *' unsigned char *SHA1(const unsigned char *d, size_t n, unsigned char *md); ^~~~ ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] param.count broken in latest master?
Daniel-Constantin Mierla writes: > Give it a try again with latest master, I did also some basic tests and > seems ok. Thanks, works now. -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] param.count broken in latest master?
This used to work:
$var(count) = $(var(servers){param.count,%});
but latest master gives:
Jun 1 16:02:04 lab sip-proxy[11965]: 0(12020) INFO: pv [pv_shv.c:60]:
shvar_init_locks(): locks array size 16
Jun 1 16:02:04 lab sip-proxy[11965]: 0(12020) ERROR: pv [pv_trans.c:3254]:
tr_parse_paramlist(): invalid count transformation: count,%}!
Jun 1 16:02:04 lab sip-proxy[11965]: 0(12020) ERROR:
[core/pvapi.c:1799]: tr_lookup(): error parsing [{param.count,%}]
Jun 1 16:02:04 lab sip-proxy[11965]: 0(12020) ERROR:
[core/pvapi.c:1106]: pv_parse_spec2(): bad tr in pvar name "var"
Jun 1 16:02:04 lab sip-proxy[11965]: 0(12020) ERROR:
[core/pvapi.c:1131]: pv_parse_spec2(): invalid parsing in
[$(var(servers){param.count,%})] at (4)
Jun 1 16:02:04 lab sip-proxy[11965]: 0(12020) CRITICAL:
[core/cfg.y:3683]: yyerror_at(): parse error in config file
/etc/sip-proxy/sip-proxy.cfg, line 7591, column 19-48: Can't get from cache:
$(var(servers){param.count,%})
-- Juha
___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] topos_redis enhancement
Daniel-Constantin Mierla writes: > Regarding topos_redis, I just pushed a commit to it in master branch, > can you give it another try? Still when A receives 183 Session Progress from P1 and send PRACK, P1 rejects it with 404 Not Found (pcap enclosed). Didn't have debug on, but can do if needed. -- Juha tshark.pcap Description: pcap ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] topos_redis enhancement
Daniel-Constantin Mierla writes: > The idea was to try to optimize and tailor it for redis specific > operation, otherwise you can try with topos+db_redis, which should give > a more SQL-like approach and the columns in mysql tables should appear > as attributes inside redis db. The db_redis was added after topos_redis, > being generic and should be capable of replacing other db_* modules. There exists topos_d and topos_t schema files in /usr/share/kamailio/db_redis/kamailio directory, but is it also necessary to define "keys" parameters for these tables? -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] topos_redis enhancement
Daniel, I studied a bit topos_redis source and noticed that it lacks x_context td and tt keys. Is there something else missing in order to make spirals work also when redis backend is in use? -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] git:master:764d5be0: core/mem: q_malloc - use #else with DBG_QM_MALLOC for debug on freed fragments
Daniel-Constantin Mierla writes: > Author: Daniel-Constantin Mierla > Committer: Daniel-Constantin Mierla > Date: 2021-04-26T11:22:20+02:00 > > core/mem: q_malloc - use #else with DBG_QM_MALLOC for debug on freed fragments The large number of log messages are still there, but perhaps this was not supposed to fix the issue. -- Juha Apr 26 16:20:32 edge /usr/bin/edge-proxy[7301]: INFO: [core/mem/q_malloc.c:529]: qm_free(): freeing a free fragment (0x7fac5cace480/0x7fac5cace490) - ignore Apr 26 16:20:32 edge /usr/bin/edge-proxy[7301]: INFO: [core/mem/q_malloc.c:529]: qm_free(): freeing a free fragment (0x7fac5cace580/0x7fac5cace590) - ignore Apr 26 16:20:32 edge /usr/bin/edge-proxy[7301]: INFO: [core/mem/q_malloc.c:529]: qm_free(): freeing a free fragment (0x7fac5cace2c0/0x7fac5cace2d0) - ignore ___ 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] add ca_path param to tls module (#2682)
Daniel-Constantin Mierla writes: > Pushed a commit to fix the error message. Now kamailio starts, but when baresip sip client tries to connect over TLS, I get these errors: Mar 23 14:02:23 lohi /usr/bin/sip-proxy[1732]: ERROR: tls [tls_server.c:1283]: tls_h_read_f(): protocol level error Mar 23 14:02:23 lohi /usr/bin/sip-proxy[1732]: ERROR: tls [tls_util.h:42]: tls_err_ret(): TLS accept:error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed Mar 23 14:02:23 lohi /usr/bin/sip-proxy[1732]: ERROR: tls [tls_server.c:1287]: tls_h_read_f(): source IP: 192.168.43.253 Mar 23 14:02:23 lohi /usr/bin/sip-proxy[1732]: ERROR: tls [tls_server.c:1290]: tls_h_read_f(): destination IP: 192.168.43.160 If I in tls.cfg replace ca_path with ca_list, the same client connects without errors. -- Juha ___ 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] add ca_path param to tls module (#2682)
Daniel-Constantin Mierla writes: > I pushed a commit to make that error message print the file name. Try > again with latest master and paste here again the new error message to > see what's there. Mar 23 13:41:37 lohi /usr/bin/sip-proxy[7261]: ERROR: tls [tls_domain.c:604]: load_ca_list(): TLSs: Error while setting client CA list file [/3] Mar 23 13:41:37 lohi /usr/bin/sip-proxy[7261]: ERROR: tls [tls_util.h:42]: tls_err_ret(): load_ca_list:error:0200100E:system library:fopen:Bad address Mar 23 13:41:37 lohi /usr/bin/sip-proxy[7261]: ERROR: tls [tls_util.h:42]: tls_err_ret(): load_ca_list:error:20074002:BIO routines:file_ctrl:system lib -- Juha ___ 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] add ca_path param to tls module (#2682)
I got latest master properly installed and gave ca_path a try. I placed four ca certs in directory /etc/sip-proxy/certs/ca_list: # ls /etc/sip-proxy/certs/ca_list class3_X0E.crt dst_root_ca_x3.pem lets-encrypt-x3-cross-signed.pem root_X0F.crt Then I created file ca_list.pem that contained all of them: # cat /etc/sip-proxy/certs/ca_list/* > /etc/sip-proxy/certs/ca_list.pem In tls config file I had: [client:default] ... ca_list = /etc/sip-proxy/certs/ca_list.pem [server:default] ... ca_list = /etc/sip-proxy/certs/ca_list.pem Result was that kamailio started OK. Then in tls config file I replaced ca_list with ca_path: ca_path = /etc/sip-proxy/certs/ca_list and kamailio failed to start: Mar 23 12:19:06 lohi /usr/bin/sip-proxy[1435]: INFO: tls [tls_domain.c:329]: ksr_tls_fill_missing(): TLSs: ca_list='(null)' Mar 23 12:19:06 lohi /usr/bin/sip-proxy[1435]: INFO: tls [tls_domain.c:336]: ksr_tls_fill_missing(): TLSs: ca_path='/etc/sip-proxy/certs/ca_list' ... Mar 23 12:19:06 lohi /usr/bin/sip-proxy[1435]: ERROR: tls [tls_domain.c:601]: load_ca_list(): TLSs: Error while setting client CA list Mar 23 12:19:06 lohi /usr/bin/sip-proxy[1435]: ERROR: tls [tls_util.h:42]: tls_err_ret(): load_ca_list:error:0200100E:system library:fopen:Bad address Mar 23 12:19:06 lohi /usr/bin/sip-proxy[1435]: ERROR: tls [tls_util.h:42]: tls_err_ret(): load_ca_list:error:20074002:BIO routines:file_ctrl:system lib Mar 23 12:19:06 lohi /usr/bin/sip-proxy[1435]: ERROR: [core/sr_module.c:865]: init_mod_child(): error while initializing module tls (/usr/lib/x86_64-linux-gnu/sip-proxy/modules/tls.so) (idx: 0 rank: -127 desc: [main]) ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] git:master:dc6d44b6: core: execute event_route[core:worker-one-init] for sctp or tcp
Daniel-Constantin Mierla writes:
> I was just about to write you on the other thread to test and see if
> works, as I did the development but without having the time to test.
I tested with tcp and tls listeners
Mar 12 20:16:43 sip-proxy[21780]: Listening on
Mar 12 20:16:43 sip-proxy[21780]: tcp: 192.168.43.160
[192.168.43.160]:5060
Mar 12 20:16:43 sip-proxy[21780]: tcp: 127.0.0.1 [127.0.0.1]:5070
Mar 12 20:16:43 sip-proxy[21780]: tcp: 127.0.0.1 [127.0.0.1]:6060
Mar 12 20:16:43 sip-proxy[21780]: tls: 192.168.43.160
[192.168.43.160]:5061 name ext_tls
and this is config:
event_route[core:worker-one-init] {
xinfo("* executed core:worker-one-init\n");
}
At start I got to syslog as expected:
Mar 12 20:16:43 /usr/bin/sip-proxy[21867]: INFO: * executed
core:worker-one-init
-- Juha
___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] git:master:dc6d44b6: core: execute event_route[core:worker-one-init] for sctp or tcp
Daniel-Constantin Mierla writes: > core: execute event_route[core:worker-one-init] for sctp or tcp > > - if no udp worker is started, the event route is executed by next > available transport, in the order: sctp, tcp (or tls) Thanks, Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] git:master:857e9deb: Improved README.
Module: kamailio
Branch: master
Commit: 857e9deb4c2455ee2ea0c05446da54f97e1f0a63
URL:
https://github.com/kamailio/kamailio/commit/857e9deb4c2455ee2ea0c05446da54f97e1f0a63
Author: Juha Heinanen
Committer: Juha Heinanen
Date: 2021-02-11T17:44:19+02:00
Improved README.
---
Modified: src/modules/rr/doc/rr_admin.xml
---
Diff:
https://github.com/kamailio/kamailio/commit/857e9deb4c2455ee2ea0c05446da54f97e1f0a63.diff
Patch:
https://github.com/kamailio/kamailio/commit/857e9deb4c2455ee2ea0c05446da54f97e1f0a63.patch
---
diff --git a/src/modules/rr/doc/rr_admin.xml b/src/modules/rr/doc/rr_admin.xml
index 7dc08b7b5c..7916789a82 100644
--- a/src/modules/rr/doc/rr_admin.xml
+++ b/src/modules/rr/doc/rr_admin.xml
@@ -628,7 +628,8 @@ record_route_advertised_address("1.2.3.4:5080");
Adds a parameter to the Record-Route URI (param must be in
;name=value format. The function may be called also
- before or after the record_route() or record_route_advertised_address()
+ before or after the record_route(),
+ record_route_advertised_address(), and record_route_preset()
calls (see or )).
___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] git:master:76b886da: rr: use rr params with record_route_preset()
Daniel-Constantin Mierla writes: > rr: use rr params with record_route_preset() > > - param buffer was checked, but not used Thanks. Tested and now add_rr_param() has effect on R-R headers added by record_route_preset(). add_rr_param() can be called both before and after record_route_preset(). -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] git:master:2664a51c: Fixed typo.
Module: kamailio Branch: master Commit: 2664a51c35a1e8b5adc4c7e6cedde60bc01f0b28 URL: https://github.com/kamailio/kamailio/commit/2664a51c35a1e8b5adc4c7e6cedde60bc01f0b28 Author: Juha Heinanen Committer: Juha Heinanen Date: 2021-02-11T17:27:44+02:00 Fixed typo. --- Modified: src/modules/rr/doc/rr_admin.xml --- Diff: https://github.com/kamailio/kamailio/commit/2664a51c35a1e8b5adc4c7e6cedde60bc01f0b28.diff Patch: https://github.com/kamailio/kamailio/commit/2664a51c35a1e8b5adc4c7e6cedde60bc01f0b28.patch --- diff --git a/src/modules/rr/doc/rr_admin.xml b/src/modules/rr/doc/rr_admin.xml index a925014715..7dc08b7b5c 100644 --- a/src/modules/rr/doc/rr_admin.xml +++ b/src/modules/rr/doc/rr_admin.xml @@ -560,7 +560,7 @@ remove_record_route(); scheme (sip: or sips:), one is added based on routing requirements. Thus the value has to be like "address:port;parameters", the port and parameters are optional. If the second parameter is provided, do not - forget to add the parameter "r2=0" so the proxy processes both + forget to add the parameter "r2=on" so the proxy processes both corresponding Route headers at once. When the outbound module was loaded before this ___ 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] keepalive.add hangs (#2625)
Daniel-Constantin Mierla writes:
> @juha-h - can you try with latest master again? I found an issue in
> ctl module that was introduced in master branch a while ago, but after
> 5.4. It may be that one. If it is not fixed, then get the `kamctl
> trap` after it hangs, to see where the processes are stuck (you need
> gdb installed).
Thanks, it works now:
```
# sip-proxy_ctl keepalive.list
# sip-proxy_ctl keepalive.add sip:username@domain listname
# sip-proxy_ctl keepalive.list
{
uri: sip:username@domain
owner: listname
last checked: Thu Feb 11 10:39:22 2021
last up: Thu Jan 1 02:00:00 1970
last down: Thu Jan 1 02:00:00 1970
state: 0
}
```
___
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] keepalive.list crash (#2618)
Daniel-Constantin Mierla writes: > I pushed a fix for two cases when allocation was not initialized. Can > you try with latest master? Thanks, now keepalive.list works when there is nothing in the list. But the second issue (that I didn't create yet) still exists, i.e., trying to add something to a list hangs and never returns, for example kamailio_ctl> keepalive.add sip:example.com:5060 test ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] keepalive crash
Juha Heinanen writes: > keepalive.list rpc command causes kamailio master to crash (at least > when there is nothing in the list). I tried to add something to the list with rpc command: keepalive.add sip:example.com test and the command hangs. Perhaps keepalive module is not supported anymore? -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] keepalive crash
keepalive.list rpc command causes kamailio master to crash (at least
when there is nothing in the list).
-- Juha
---
gdb) bt full
#0 rpc_struct_add (s=0x560b4df75830, fmt=0x7f2da23322c3 "SS") at
binrpc_run.c:1092
ap = {{gp_offset = 32, fp_offset = 48, overflow_arg_area =
0x7ffebd54cfc0,
reg_save_area = 0x7ffebd54ced0}}
err = -1118515440
avp = {name = {s = 0x7f2da23322bf "uri", len = 3}, type = 1, u =
{strval = {s = 0x0,
len = 0}, fval = 0, intval = 0, end = 0}}
rs = 0x7ffebd54d0e0
__func__ = "rpc_struct_add"
#1 0x7f2da2322776 in keepalive_rpc_list (rpc=0x7f2da2f022e0
,
ctx=0x7ffebd54d0e0) at keepalive_rpc.c:86
sub = 0x560b4df75830
dest = 0x1
t_buf = '\000'
#2 0x7f2da2ecc993 in process_rpc_req (
buf=0x560b4df55784 "\241\003\021'\332D}\221\017keepalive.list", size=24,
bytes_needed=0x7ffebd54d1e8, sh=0x7ffebd54d250, saved_state=0x560b4df65788)
at binrpc_run.c:683
err = 0
val = {name = {s = 0x7ffebd54d1c0 " \323T\275\376\177", len =
-1561476359}, type = 1,
u = {strval = {s = 0x560b4df5578d "keepalive.list", len = 14},
fval = 4.6741847488088159e-310, intval = 1307924365, end =
1307924365}}
rpc_e = 0x7f2da3c91910
f_ctx = {in = {ctx = {tlen = 17, cookie = 668615805, type = 0, flags =
1,
offset = 17, in_struct = 0, in_array = 0}, s = 0x560b4df5579c "",
end = 0x560b4df5579c "", record_no = 0, in_struct = 0}, out = {pkt
= {
body = 0x560b4df65820 "\003\203", end = 0x560b4df75820 "",
crt = 0x560b4df65822 ""}, structs = {next = 0x560b4df75830,
prev = 0x560b4df75830}}, send_h = 0x7ffebd54d250,
method = 0x560b4df5578d "keepalive.list", gc = 0x0, replied = 0,
err_code = 0,
--Type for more, q to quit, c to continue without paging--
err_phrase = {s = 0x0, len = 0}}
ctx = 0x7ffebd54d0e0
__func__ = "process_rpc_req"
#3 0x7f2da2ee9ae9 in handle_stream_read (s_c=0x560b4df55750, idx=-1) at
io_listener.c:511
bytes_free = 65535
bytes_read = 24
bytes_needed = 1307733728
bytes_processed = 22027
r = 0x560b4df55770
sh = {fd = 15, type = 0, from = {sa_in = {s = {sa_family = 0,
sa_data =
"\000\000\000\000\000\000\001\000\377\377\377\377\377\377"}, sin = {
sin_family = 0, sin_port = 0, sin_addr = {s_addr = 0},
sin_zero = "\001\000\377\377\377\377\377\377"}, sin6 =
{sin6_family = 0,
sin6_port = 0, sin6_flowinfo = 0, sin6_addr = {__in6_u = {
__u6_addr8 = "\001\000", '\377' ,
__u6_addr16 = {1,
65535, 65535, 65535, 65535, 65535, 65535, 65535},
__u6_addr32 = {
4294901761, 4294967295, 4294967295, 4294967295}}},
sin6_scope_id = 0},
sas = {ss_family = 0,
__ss_padding = "\000\000\000\000\000\000\001\000", '\377'
, '\000' ,
"\001\000\000\000\000\000\000\000\260:\n\232-\177", '\000' ,
"\340\322T\275\001\000\000\000\260:\n\232-\177\000\000\340\322T\275\376\177\000\000\231{\355\242-\177\000\000\000\000\300\000\000\000\000\000\260:\n\232-\177\000",
__ss_align = 10513424}}, sa_un = {sun_family = 0,
sun_path = "\000\000\000\000\000\000\001\000", '\377' , '\000' ,
"\001\000\000\000\000\000\000\000\260:\n\232-\177", '\000' ,
"\340\322T\275\001\000\000\000\260:\n\232-\177\000\000\340\322T\275\376\177\000\000\231{\355\242-\177\000\000\000\000\300\000\000"}},
from_len = 0}
__func__ = "handle_stream_read"
#4 0x7f2da2eeb870 in handle_io (fm=0x7f2da3ca38a8, events=1, idx=-1) at
io_listener.c:706
--Type for more, q to quit, c to continue without paging--
ret = 1
__func__ = "handle_io"
#5 0x7f2da2ee2092 in io_wait_loop_epoll (h=0x7f2da2f02380 ,
t=10, repeat=0)
at ../../core/io_wait.h:1070
n = 1
r = 0
fm = 0x7f2da3ca38a8
revents = 1
__func__ = "io_wait_loop_epoll"
#6 0x7f2da2ee6707 in io_listen_loop (fd_no=1, cs_lst=0x560b4df26ee0) at
io_listener.c:281
max_fd_no = 295
poll_err = 0x0
poll_method = 2
cs = 0x0
type = 2
__func__ = "io_listen_loop"
#7 0x7f2da2ef1aa2 in mod_child (rank=0) at ctl.c:338
pid = 0
cs = 0x7f2d9a0a2850
rpc_handler = 1
__func__ = "mod_child"
#8 0x560b4d8349f7 in init_mod_child (m=0x7f2da3cc0370, rank=0) at
core/sr_module.c:827
__func__ = "init_mod_child"
#9 0x560b4d834612 in init_mod_child (m=0x7f2da3cc07a0, rank=0) at
core/sr_module.c:823
__func__ = "init_mod_child"
#10 0x560b4d834612 in init_mod_child (m=0x7f2da3cc0ad0, rank=0) at
core/sr_module.c:823
__func__ = "init_mod_child"
#11 0x560b4d834612 in init_mod_child (m=0x7f2da3cc12b0, rank=0) at
[sr-dev] [kamailio/kamailio] nat_traversal: TCP transport support (#2564)
sergey-safarov writes: > In this case, the TCP session may be expired on the NAT device, and > future calls to the user phone not possible. Usually clients generate TCP keepalives and there is no need for Kamailio proxy to do anything. -- Juha ___ 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] Dump Configuration and Exit (new flag -C [filename]) (#2546)
I gave --cfg-print a try. I have this in config:
loadmodule "tls"
...
# -- tls params
#!ifdef MOD_tls
modparam("tls", "config", "/etc/sip-proxy/tls.cfg")
modparam("tls", "cipher_list", "HIGH:!ADH:!AECDH")
#!endif
# -- tm params
and --cfg-print gave this kind of output:
loadmodule "tls"
...
# -- tls params
# -- tm params
Since tls module is loaded I would have expected tls modparams to show
up in the output.
-- Juha
___
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] Dump Configuration and Exit (new flag -C [filename]) (#2546)
Daniel-Constantin Mierla writes: > So for now, if someone doesn't want the #!KAMAILIO (or the other > variants) in the first line, can add it temporarily only when it uses > the --cfg-print, then remove it. Of course, if someone wants to look > more into it, is more than welcome to make pull requests. It is OK to have that in the first line, but my question was, can there be something else on the first line after #!KAMAILIO? So is the test first_line == "#!KAMAILIO" or starts_with(first_line, "#!KAMAILIO") ? -- juha ___ 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] Dump Configuration and Exit (new flag -C [filename]) (#2546)
Daniel-Constantin Mierla writes: > Very important - for now the `--cfg-print` works if the main > configuration file has the first line: > #!KAMAILIO Can there be other stuff on the line after #!KAMAILIO? For example emacs can be told about the major mode used in the file by checking if first non-blank line contains -*--*-. So I would like the definition go like this: `--cfg-print` works if the main configuration file starts with #!KAMAILIO -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] use_dst_blacklist syntax error
Daniel-Constantin Mierla writes: > This is due to some ongoing work started in the morning -- I just > updated the wiki core cookbook and the upgrade guidelines: Just after sending the email, I saw the emails of the related commits and figured out the change. -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] event_route [xhttp:request] is not run
Daniel-Constantin Mierla writes: > I looked at the code and indeed there was an issue with the flag-based > protocol detection. I pushed a commit to fix it, let me know if works ok > now. Works now, thanks, -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] event_route [xhttp:request] is not run
Daniel-Constantin Mierla writes: > Actually that error message log is after non-sip msg callback. That part > should not be affected by my changes and execution should not get there > if xhttp module is properly loaded and configured. Can you check if > other error messages are printed? Maybe the regression was introduced > with flag-based detection of sip/http protocols... No other error message. I'm using 5.4 for now, so there is no hurry to find a fix. -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] event_route [xhttp:request] is not run
Daniel-Constantin Mierla writes: > For the moment set core parameter: > > sip_parser_mode=0 Didn't help. Still Oct 14 20:53:47 lohi /usr/bin/sip-proxy[23198]: ERROR: [core/receive.c:356]: receive_msg(): no via found in request -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] event_route [xhttp:request] is not run
With current master, event_route [xhttp:request] is not run. Instead error message shows up: Oct 14 20:00:48 lohi /usr/bin/sip-proxy[8820]: ERROR: [core/receive.c:356]: receive_msg(): no via found in request After spending one hour in trying to figure out, what is wrong in my config, I build K using 5.4 instead of master and the problem disappeared. So I suspect something is broken in master. -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] source addr param to pike_check_req()
Daniel-Constantin Mierla writes: > I am fine to add it. So far I preferred to discard unwanted traffic at > the brorder of the core platform, so I didn't need such feature. I agree, better to do blocking at the edge. -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] source addr param to pike_check_req()
How about adding source addr param to pike_check_req()? Motivation is that main proxy may be front-ended by another proxy that passes the real source addr to the main proxy in a header. -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] K master crash
Daniel-Constantin Mierla writes: > I pushed a commit to fix it, can you try with latest master? Tried with latest master and crash does not happen anymore at shutdown. Thanks, Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] K master crash
Daniel-Constantin Mierla writes: > The kamailio wiki has a turorial about troubleshooting with core files > where it gives the details about how to enable core file per pid (I am > on mobile link right now, not easy to give the url). OK, will try to look. > To understand that it crashes only on shut down anyhow, not a runtime > crash? I think that so far only at shutdown. -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] K master crash
Juha Heinanen writes: > Just built K from current master and it crashes every time with similar > gdb trace when I stop it using 'service sip-proxy stop'. As a test, djJust build K from latest 5.4 branch and it does not crash at stop with exactly same config setup and environment. So looks like something is broken in master. -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] K master crash
Daniel-Constantin Mierla writes: > The backtrace is for the main process during shut down, which can be a > side effect of the real issue. You should enable core dump per pid to > see if you get core files from more than one process, then grab > backtraces from all those core files to figure out what was the first > reason of the crash. Sorry, but don't know how to enable core dump per pid. Didn't find any cli option for that. > Is it the last master version or some older one (kamailio -v should > print the commit id, if you compiled from sources)? Just built K from current master and it crashes every time with similar gdb trace when I stop it using 'service sip-proxy stop'. -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] K master crash
K master has recently crashed several times on Debian 10. Could this have something to do with openssl libs? -- Juha Oct 5 08:32:21 lohi systemd[1]: Stopping LSB: Start/stop OpenSIPg SIP Proxy... Oct 5 08:32:21 lohi sip-proxy[19922]: Stopping sip-proxy Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30820]: NOTICE: [main.c:735]: handle_sigs(): Thank you for flying sip-proxy!!! Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30860]: INFO: [main.c:857]: sig_usr(): signal 15 received Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30859]: INFO: [main.c:857]: sig_usr(): signal 15 received Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30858]: INFO: [main.c:857]: sig_usr(): signal 15 received Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30857]: INFO: [main.c:857]: sig_usr(): signal 15 received Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30853]: INFO: [main.c:857]: sig_usr(): signal 15 received Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30856]: INFO: [main.c:857]: sig_usr(): signal 15 received Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30850]: INFO: [main.c:857]: sig_usr(): signal 15 received Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30854]: INFO: [main.c:857]: sig_usr(): signal 15 received Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30834]: INFO: [main.c:857]: sig_usr(): signal 15 received Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30847]: INFO: [main.c:857]: sig_usr(): signal 15 received Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30852]: INFO: [main.c:857]: sig_usr(): signal 15 received Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30849]: INFO: [main.c:857]: sig_usr(): signal 15 received Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30851]: INFO: [main.c:857]: sig_usr(): signal 15 received Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30841]: INFO: [main.c:857]: sig_usr(): signal 15 received Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30830]: INFO: [main.c:857]: sig_usr(): signal 15 received Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30848]: INFO: [main.c:857]: sig_usr(): signal 15 received Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30846]: INFO: [main.c:857]: sig_usr(): signal 15 received Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30836]: INFO: [main.c:857]: sig_usr(): signal 15 received Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30827]: INFO: [main.c:857]: sig_usr(): signal 15 received Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30844]: INFO: [main.c:857]: sig_usr(): signal 15 received Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30845]: INFO: [main.c:857]: sig_usr(): signal 15 received Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30833]: INFO: [main.c:857]: sig_usr(): signal 15 received Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30842]: INFO: [main.c:857]: sig_usr(): signal 15 received Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30839]: INFO: [main.c:857]: sig_usr(): signal 15 received Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30829]: INFO: [main.c:857]: sig_usr(): signal 15 received Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30822]: INFO: [main.c:857]: sig_usr(): signal 15 received Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30840]: INFO: [main.c:857]: sig_usr(): signal 15 received Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30838]: INFO: [main.c:857]: sig_usr(): signal 15 received Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30826]: INFO: [main.c:857]: sig_usr(): signal 15 received Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30837]: INFO: [main.c:857]: sig_usr(): signal 15 received Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30824]: INFO: [main.c:857]: sig_usr(): signal 15 received Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30835]: INFO: [main.c:857]: sig_usr(): signal 15 received Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30823]: INFO: [main.c:857]: sig_usr(): signal 15 received Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30832]: INFO: [main.c:857]: sig_usr(): signal 15 received Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30831]: INFO: [main.c:857]: sig_usr(): signal 15 received Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30828]: INFO: [main.c:857]: sig_usr(): signal 15 received Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30843]: INFO: [main.c:857]: sig_usr(): signal 15 received Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30825]: INFO: [main.c:857]: sig_usr(): signal 15 received Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30821]: INFO: [main.c:857]: sig_usr(): signal 15 received Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30855]: INFO: [main.c:857]: sig_usr(): signal 15 received Oct 5 08:32:21 lohi /usr/bin/sip-proxy[30820]: INFO: [core/sctp_core.c:53]: sctp_core_destroy(): SCTP API not initialized Oct 5 08:32:21 lohi kernel: [176646.851504] sip-proxy[30820]: segfault at 7f84196c7730 ip 7f8421adce26 sp 7ffde899c0f0 error 4 in libcrypto.so.1.1[7f84219d8000+19e000] Oct 5 08:32:21 lohi kernel: [176646.851513] Code: 1f 44 00 00 c7 05 9a d9 15 00 01 00 00 00 c7 05 8c d9 15 00 01 00 00 00 c3 66 66 2e 0f 1f 84 00 00 00 00 00 48 85 ff 74 5b 53 <8b> 0f 48 89 fb 85 c9 75 29 8b 53 04 85 d2 75 2e 8b 43 08 85 c0 75 (gdb) where #0 0x7f8421adce26 in ?? () from
[sr-dev] git:master:d93de03c: sqlops module: added one more sql query function return value to README
Module: kamailio
Branch: master
Commit: d93de03c10eb7b88024d7eb9ba85200601cf6c7a
URL:
https://github.com/kamailio/kamailio/commit/d93de03c10eb7b88024d7eb9ba85200601cf6c7a
Author: Juha Heinanen
Committer: Juha Heinanen
Date: 2020-08-25T20:11:59+03:00
sqlops module: added one more sql query function return value to README
---
Modified: src/modules/sqlops/doc/sqlops_admin.xml
---
Diff:
https://github.com/kamailio/kamailio/commit/d93de03c10eb7b88024d7eb9ba85200601cf6c7a.diff
Patch:
https://github.com/kamailio/kamailio/commit/d93de03c10eb7b88024d7eb9ba85200601cf6c7a.patch
---
diff --git a/src/modules/sqlops/doc/sqlops_admin.xml
b/src/modules/sqlops/doc/sqlops_admin.xml
index aaec64f302..671fe79858 100644
--- a/src/modules/sqlops/doc/sqlops_admin.xml
+++ b/src/modules/sqlops/doc/sqlops_admin.xml
@@ -237,6 +237,10 @@ modparam("sqlops", "connect_mode", 1)
2 - query successful, no rows
returned
+
+ 3 - query successful, at least one
row
+returned, but result parameter was not given
+
___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] [kamailio/kamailio] pua: different behavior depending on db_mode (#2414)
Juha Heinanen writes: > Victor Seva writes: > > > I cannot be sure 100% but from what I understand if you set etag... it has > > the same behavior than previously. > > If is the first PUBLISH, there's no record, so no changes in logic. > > > > Change is merged already do you detect any regression? > > I can test when the merge is backported to 5.4, since I don't at present > have a live master system. I installed latest master and looks like pua_rpc pua_publish with explicit etag args works OK. -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] [kamailio/kamailio] pua: different behavior depending on db_mode (#2414)
Victor Seva writes: > I cannot be sure 100% but from what I understand if you set etag... it has > the same behavior than previously. > If is the first PUBLISH, there's no record, so no changes in logic. > > Change is merged already do you detect any regression? I can test when the merge is backported to 5.4, since I don't at present have a live master system. ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] [SR-Users] new in upcoming Kamailio 5.4.0
Henning Westerholt writes: > * 5 new modules have been added (pv_headers, kafka, secsipid, > * systemdops, dlgs) Could not find many of these on page: https://kamailio.org/docs/modules/devel/ -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] json request fails
Daniel-Constantin Mierla writes: > I pushed a fix for it (not tested) -- it was the new siptrace mode > trying to save to database using core callbacks and not checking it is > sip traffic or not. The errors were for the http traffic. Thanks, the error messages are now gone. -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] json request fails
This is the config command that my SIP proxy executes on the incoming JSON over HTTP request: jsonrpc_dispatch(); -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] json request fails
Juha Heinanen writes: > I noticed that json rpc commands have started to fail, for example, Actually, the commands still work even when error messages are produced. -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] json request fails
I noticed that json rpc commands have started to fail, for example,
May 2 15:41:15 char /usr/bin/sip-proxy[10440]: INFO: Executing JSON request
<{"jsonrpc":"2.0","method":"siptrace.status","params":["on"],"id":1}> from
<127.0.0.1> with host <127.0.0.1:6060>
May 2 15:41:15 char /usr/bin/sip-proxy[10440]: ERROR:
[core/parser/parse_from.c:53]: parse_from_header(): bad msg or missing FROM
header
May 2 15:41:15 char /usr/bin/sip-proxy[10440]: ERROR: siptrace
[siptrace_send.c:55]: sip_trace_prepare(): cannot parse FROM header
Has something changed that I have missed? I didn't find anything
related on the wiki upgrade page.
-- Juha
___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] undefined symbol: ul_cseq_delay
Daniel-Constantin Mierla writes: > It was introduced by my previous commit. I pushed the fix for it. OK, thanks, running now. -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] undefined symbol: ul_cseq_delay
I build my sip proxy from today's master and it didn't start: May 2 15:12:51 char sip-proxy[22422]: 0(22474) ERROR: [core/sr_module.c:512]: load_module(): could not open module : /usr/lib/x86_64-linux-gnu/sip-proxy/modules/usrloc.so: undefined symbol: ul_cseq_delay -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] git:master:c2512ac4: siptrace: docs for trace_init_mode parameter
So if tracing is controlled only by rpc commands, then trace_init_mode can have value 1? -- Juha > + 1 - module initialized to do tracing only with > core callback > + functions (see also 'trace_mode' parameter). ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] siptrace inconsistency
Daniel-Constantin Mierla writes: > On the other hand, as enhancement, would it make sense to have > trace_mode also changeable via rpc? Not sure if someone would want to > change from mirroring to hep or uri to storing to database, or the other > way around ... It might be useful to be able to configure via rpc where the trace goes, but I don't have immediate need for that. When I looked at the code a few months ago, I noticed that the callback is permanently registered. Might save some CPU cycles if the callback would be unregistered when tracing is off. -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] siptrace inconsistency
Daniel-Constantin Mierla writes:
> Can you try the master branch with trace_on=1 and trace_mode=2 for
> siptrace module? You need to set also the db connection parameters,
> otherwise no siptrace flag set or function use in routing blocks. See
> also the docs of trace_mode param.
Thanks for the new feature. I tested and it worked OK. In the config I
used
modparam("siptrace", "trace_on", 0)
so that tracing is by default off when K starts.
-- Juha
___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] siptrace inconsistency
Daniel-Constantin Mierla writes: > That might not be that complex to do, right now all traffic can be > mirrored via HEP by setting the trace_mode parameter. If someone wants > to test it, I can extend it when I get a bit of time during the next few > days with an option to write the traffic to database, controlled to > turn/on off by the rcp command (already available). I would be delighted to test siptrace module RPC on/off capability. > > I could then do transaction/dialog/whatever level post-processing of the > > traffic based on the records in the database and I don't need any help > > from K regarding that. > > I guess that this kind of filtering is needed for instances with a lot > of traffic, where mirroring everything can become a big overhead. Having > support for such filtering doesn't exclude to have the above variant > (which is simpler -- again, most of it already implemented for HEP > mirroring). Yes, I agree that there are situations where filtering by K is needed. -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] siptrace inconsistency
Federico Cabiddu writes: > I would like to have the developers' feedback before opening a PR, there > could be other scenarios/use cases I'm not considering here. My feeedback as a K user is this: I would prefer capability to turn on/off tracing of all messages (requests/replies) that enter/leave K via an rpc command rather than by setting the flag and calling sip_trace() in the config. I could then do transaction/dialog/whatever level post-processing of the traffic based on the records in the database and I don't need any help from K regarding that. -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] siptrace inconsistency
Daniel-Constantin Mierla writes:
> OK, indeed, the previous behaviour should be preserved in this case. Is
> sip_trace() without params now doing transaction mode capturing?
If I remember correctly, there was discussion about this a few months
ago.
Behavior of
modparam("siptrace", "db_url", "MYSQL_SIP_PROXY_USAGE_URL")
modparam("siptrace", "trace_flag", TRACE)
...
setflag(TRACE);
sip_trace();
should be what it has been for many years.
-- Juha
___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] master compiler warnings
Daniel-Constantin Mierla writes: > Apparently clang-libc on bsd/macos has different types for tmval fields > than gcc on linux. I pushed a commit to do casts and avoid warning in > any of those platforms. Thanks, warnings are now gone on Debian. -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] master xml warnings
version.xml:14: namespace error : Namespace prefix db on para is not defined ^ ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] master compiler warnings
CC (gcc) [M usrloc.so] ul_keepalive.o
ul_keepalive.c: In function 'ul_ka_urecord':
ul_keepalive.c:61:18: warning: format '%x' expects argument of type 'unsigned
int', but argument 26 has type '__suseconds_t' {aka 'long int'} [-Wformat=]
#define ULKA_MSG "%.*s %.*s SIP/2.0\r\n" \
^~~
ul_keepalive.c:193:50: note: in expansion of macro 'ULKA_MSG'
kabuf_len = snprintf(kabuf, ULKA_BUF_SIZE - 1, ULKA_MSG,
^~~~
ul_keepalive.c:64:34: note: format string is defined here
"From: <%.*s>;tag=%.*s-%x-%lx-%x-%x.%x\r\n" \
~^
%lx
In file included from ul_keepalive.c:30:
ul_keepalive.c: In function 'ul_ka_reply_received':
../../core/dprint.h:316:24: warning: format '%u' expects argument of type
'unsigned int', but argument 11 has type '__suseconds_t' {aka 'long int'}
[-Wformat=]
fprintf(stderr, "%2d(%d) %s: %.*s%s%s%s" fmt, \
^~~~
../../core/dprint.h:340:4: note: in expansion of macro 'LOG_FX'
LOG_FX(facility, level, lname, prefix, _FUNC_NAME_, fmt, ## args)
^~
../../core/dprint.h:346:4: note: in expansion of macro 'LOG_FL'
LOG_FL(facility, level, NULL, prefix, fmt, ## args)
^~
../../core/dprint.h:349:4: note: in expansion of macro 'LOG_FP'
LOG_FP(DEFAULT_FACILITY, (level), LOC_INFO, fmt, ## args)
^~
../../core/dprint.h:396:32: note: in expansion of macro 'LOG'
# define DBG(fmt, args...)LOG(L_DBG, fmt , ## args)
^~~
../../core/dprint.h:400:30: note: in expansion of macro 'DBG'
# define DEBUG(fmt, args...) DBG(fmt , ## args)
^~~
../../core/dprint.h:417:16: note: in expansion of macro 'DEBUG'
#define LM_DBG DEBUG
^
ul_keepalive.c:366:2: note: in expansion of macro 'LM_DBG'
LM_DBG("tv usec is [%u]\n", tvm.tv_usec);
^~
ul_keepalive.c:366:23: note: format string is defined here
LM_DBG("tv usec is [%u]\n", tvm.tv_usec);
~^
%lu
___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] pv module problems on master
Daniel-Constantin Mierla writes: > They were from the previous commits indeed -- clang on mac was not > reporting them. I just pushed patches to fix them. Thanks, works now, Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] pv module problems on master
May have something to do with recent two commits. -- Juha --- CC (gcc) [M pv.so] pv_trans.o pv_trans.c: In function 'tr_eval_string': pv_trans.c:539:22: warning: pointer targets in passing argument 1 of 'base64url_enc' differ in signedness [-Wpointer-sign] i = base64url_enc((unsigned char *) val->rs.s, val->rs.len, ^~~ In file included from pv_trans.c:40: ../../core/basex.h:867:5: note: expected 'char *' but argument is of type 'unsigned char *' int base64url_enc(char *in, int ilen, char *out, int osize); ^ pv_trans.c:540:6: warning: pointer targets in passing argument 3 of 'base64url_enc' differ in signedness [-Wpointer-sign] (unsigned char *) _tr_buffer, TR_BUFFER_SIZE-1); ^~~~ In file included from pv_trans.c:40: ../../core/basex.h:867:5: note: expected 'char *' but argument is of type 'unsigned char *' int base64url_enc(char *in, int ilen, char *out, int osize); ^ pv_trans.c:552:22: warning: pointer targets in passing argument 1 of 'base64url_dec' differ in signedness [-Wpointer-sign] i = base64url_dec((unsigned char *) val->rs.s, val->rs.len, ^~~ In file included from pv_trans.c:40: ../../core/basex.h:868:5: note: expected 'char *' but argument is of type 'unsigned char *' int base64url_dec(char *in, int ilen, char *out, int osize); ^ pv_trans.c:553:6: warning: pointer targets in passing argument 3 of 'base64url_dec' differ in signedness [-Wpointer-sign] (unsigned char *) _tr_buffer, TR_BUFFER_SIZE-1); ^~~~ In file included from pv_trans.c:40: ../../core/basex.h:868:5: note: expected 'char *' but argument is of type 'unsigned char *' int base64url_dec(char *in, int ilen, char *out, int osize); ^ pv_trans.c:565:22: warning: pointer targets in passing argument 1 of 'base64url_enc' differ in signedness [-Wpointer-sign] i = base64url_enc((unsigned char *) val->rs.s, val->rs.len, ^~~ In file included from pv_trans.c:40: ../../core/basex.h:867:5: note: expected 'char *' but argument is of type 'unsigned char *' int base64url_enc(char *in, int ilen, char *out, int osize); ^ pv_trans.c:566:6: warning: pointer targets in passing argument 3 of 'base64url_enc' differ in signedness [-Wpointer-sign] (unsigned char *) _tr_buffer, TR_BUFFER_SIZE-1); ^~~~ In file included from pv_trans.c:40: ../../core/basex.h:867:5: note: expected 'char *' but argument is of type 'unsigned char *' int base64url_enc(char *in, int ilen, char *out, int osize); ^ pv_trans.c:597:23: warning: pointer targets in passing argument 1 of 'base64url_dec' differ in signedness [-Wpointer-sign] i = base64url_dec((unsigned char *) st.s, st.len, ^~ In file included from pv_trans.c:40: ../../core/basex.h:868:5: note: expected 'char *' but argument is of type 'unsigned char *' int base64url_dec(char *in, int ilen, char *out, int osize); ^ pv_trans.c:598:7: warning: pointer targets in passing argument 3 of 'base64url_dec' differ in signedness [-Wpointer-sign] (unsigned char *) _tr_buffer, TR_BUFFER_SIZE-1); ^~~~ In file included from pv_trans.c:40: ../../core/basex.h:868:5: note: expected 'char *' but argument is of type 'unsigned char *' int base64url_dec(char *in, int ilen, char *out, int osize); ^ pv_trans.c:600:23: warning: pointer targets in passing argument 1 of 'base64url_dec' differ in signedness [-Wpointer-sign] i = base64url_dec((unsigned char *) val->rs.s, val->rs.len, ^~~ In file included from pv_trans.c:40: ../../core/basex.h:868:5: note: expected 'char *' but argument is of type 'unsigned char *' int base64url_dec(char *in, int ilen, char *out, int osize); ^ pv_trans.c:601:7: warning: pointer targets in passing argument 3 of 'base64url_dec' differ in signedness [-Wpointer-sign] (unsigned char *) _tr_buffer, TR_BUFFER_SIZE-1); ^~~~ In file included from pv_trans.c:40: ../../core/basex.h:868:5: note: expected 'char *' but argument is of type 'unsigned char *' int base64url_dec(char *in, int ilen, char *out, int osize); ^ Mar 7 00:15:46 char sip-proxy[21381]: 0(21433) ERROR: [core/sr_module.c:512]: load_module(): could not open module : /usr/lib/x86_64-linux-gnu/sip-proxy/modules/pv.so: undefined symbol: base64url_enc ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org
[sr-dev] git:master:51d95e0e: modukles/tm: added t_clean() script function
Module: kamailio Branch: master Commit: 51d95e0e7cce0483c517e2bcfc5000b60a7e35be URL: https://github.com/kamailio/kamailio/commit/51d95e0e7cce0483c517e2bcfc5000b60a7e35be Author: Juha Heinanen Committer: Juha Heinanen Date: 2020-03-06T09:08:12+02:00 modukles/tm: added t_clean() script function --- Modified: src/modules/tm/README Modified: src/modules/tm/doc/functions.xml Modified: src/modules/tm/tm.c --- Diff: https://github.com/kamailio/kamailio/commit/51d95e0e7cce0483c517e2bcfc5000b60a7e35be.diff Patch: https://github.com/kamailio/kamailio/commit/51d95e0e7cce0483c517e2bcfc5000b60a7e35be.patch ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] sl module lacks API function to unregister a callback
I tried to implement dynamic registering/unregistering of siptrace module sl callbacks, but it turned out that sl module lacks API function to unregister a callback. -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] sip_trace() broken in master
Daniel-Constantin Mierla writes: > There is also a rpc command to turn tracinf on/off, but it doesn't > affect the trace_mode=1. Again, for the next major release we should > revise and make those options work for all variants: mirroring or save > to db, with control via modparams and rpc... I looked at the code and looks like callbacks are not unregistered/registered again when tracing is turned off/on by rpc command. Doesn't that affect performance negatively? -- Juha ___ 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] Systemd unit update (#1889)
sergey-safarov writes: > Now unit contains > ``` > RuntimeDirectory=kamailio > ``` ... > Look as current definition correct Yes, RuntimeDirectory is correct, but not this: PIDFile=/var/run/kamailio/kamailio.pid since it hardwires /var/run rather than using $RUNTIME_DIRECTORY. -- Juha ___ 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] Systemd unit update (#1889)
Daniel-Constantin Mierla writes: > Does this one still needs to be addressed, or are we fine with the > version included in the deb/rpm packages right now? It works right now (with the syslog message), but according systemd documentation, the dir is /run, not /var/run: https://www.freedesktop.org/software/systemd/man/systemd.exec.html#RuntimeDirectory= Perhaps the best would be to use $RUNTIME_DIRECTORY environment var. -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] debian buster systemd pid file location
Looks like systemd service pid files should nowadays be placed in /run dir instead of /var/run. I noticed this when I got complaint about fail2ban to syslog: Oct 17 20:59:35 lab systemd[1]: /lib/systemd/system/fail2ban.service:12: PIDFile= references path below legacy directory /var/run/, updating /var/run/fail2ban/fail2ban.pid → /run/fail2ban/fail2ban.pid; please update the unit file accordingly. I haven't tried yet with Kamailio, but suspect that a similar warning would be issued. So how about making the change in https://github.com/kamailio/kamailio/blob/master/pkg/kamailio/deb/buster/kamailio.service -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] removing 200-canceling response from kamailio
vinod mn writes: > For a cancel message from a user kamailio is send "200-canceling" so I want > to supress this for some reasons. Relay the request statelessly and then on reply route drop the 200. -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] removing 200-canceling response from kamailio
vinod mn writes: > how to remove the "200-canceling" response from kamailio it is very > urgent. So you ask, how to make Kamailio break RFC3261? -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] siptrace errors
Daniel-Constantin Mierla writes: > The callbacks for tm are used also for database storage, those from the > core for packet-in/packet-out are for hep only at this moment. What if only messages are traced, i.e., not transactions nor dialogs. Are callbacks still used? -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] siptrace errors
Daniel-Constantin Mierla writes: > There are transaction callbacks enabled because some of them can be set > only at startup, detection whether siptrace should be done or not for > that transaction being done later in that function, once the pointer to > the message is figure out. My understanding is that callbacks are used only in hep mode. If so, no callbacks should be enabled when hep mode is off. -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] siptrace errors
Using 5.3 branch, I have sip-proxy_ctl> siptrace.status check Disabled but still these kind of errors appear in syslog: Oct 16 12:07:10 salmon /usr/bin/sip-proxy[26459]: ERROR: siptrace [siptrace.c:1250]: trace_onreq_out(): retransmission Oct 16 12:07:11 salmon /usr/bin/sip-proxy[26459]: ERROR: siptrace [siptrace.c:1250]: trace_onreq_out(): retransmission Oct 16 12:07:13 salmon /usr/bin/sip-proxy[26459]: ERROR: siptrace [siptrace.c:1250]: trace_onreq_out(): retransmission How is it possible? -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] git:5.3:c32bccf1: tls: switch to TLSv1.2 in example cfg, usage of TLS 1.0 is not recommended anymore
Henning Westerholt writes: > tls: switch to TLSv1.2 in example cfg, usage of TLS 1.0 is not > recommended anymore How about TLSv1.3? baresip, for example, would like to use it. Isn't there TLSv1.2+ value? -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] git:master:dd594481: modules: readme files regenerated - siptrace ... [skip ci]
README still needs clatifications. In Overview: * by setting “trace_mode” to mirror all traffic. => * by setting “trace_mode” to mirror all traffic if HEP mode is on. or has this now changed in master? 3.18. trace_mode (integer) If set to 1, the module uses core events triggered when receiving or sending SIP traffic to mirror traffic to a SIP capture server using HEP. -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] sip_trace() broken in master
Daniel-Constantin Mierla writes: > The db storage and hep mirroring were developed independently, not > expecting to have them in pair always, but based on this discussion, it > seems you would like some of the capabilities from one tracing type to > be also in the other. Then also trace_mode should have been called hep_trace_mode. And if RPC commands don't work when trace_mode == 1, README needs more editing. -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] sip_trace() broken in master
Daniel-Constantin Mierla writes: > given the changes done in the module to track the message, transaction > or dialog, it should be fine to do this right now, because it is the > testing period for 5.3, where it is supposed to clean up of issue and > make coherent the new changes for this release. It is not like a new > brand feature, only how an existing feature can be used in config. Since this is quite a mess now (also RPC Commands section is confusing), it would be great if cleanup could be done before 5.3. So trace_mode=1 and RPC commands should be effective also when HEP is not in use. -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] sip_trace() broken in master
Daniel-Constantin Mierla writes: > There is a parameter trace_mode which can turn on automatic capture of > all sip messages, but is for mirroring the traffic. Probably, for the > next major release, it should be extended to do the save in the database > as well, if that is wanted via some modparam. That is what I just asked before reading this. It would make sense that independent of hep, trace_mode=1 would cause tracing of all messages. > There is also a rpc command to turn tracinf on/off, but it doesn't > affect the trace_mode=1. Again, for the next major release we should > revise and make those options work for all variants: mirroring or save > to db, with control via modparams and rpc... ... and rpc command would be effective too. -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] git:master:41f6ddb8: modules: readme files regenerated - siptrace ... [skip ci]
Kamailio Dev writes: > If set to 1, the module uses core events triggered when receiving or > sending SIP traffic to mirror traffic to a SIP capture server using > - HEP. It will automatically do the mirroring of all traffic, no need to > - set the siptrace flag per request. > + HEP. It will automatically do the mirroring of all SIP traffic. It is > + no longer needed to set the siptrace flag per request or execute > + sip_trace(), if it is done, then there mirroring is duplicated. > > If set to 0, no automatic mirroring of SIP traffic via HEP. So if hep_mode_on is not set (defaults to 0), is setting of the flag and calling of sip_trace() still needed if trace_mode is set to 1? -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] unused variable
Daniel-Constantin Mierla writes: > The variable is used in my version of code from master branch. Can you > check and see if you don't have a modified version you did to disable > mysql connection ping? That may have been the case. Sorry again. Now build works fine. -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] sip_trace() broken in master
Juha Heinanen writes: > For me it would be best and simplest if tracing of all request and > responses would happen automatically when siptrace module is loaded and > suitable parameters are set and when tracing is turned on via an rpc > command, i.e., without any function calls in the config. > > If that cannot be achived and a function call is needed, one must be > enough. So, load siptrace module, set params appropriately, and call a function: trace_request_or_response_if_tracing_is_enabled_by_rpc_command(); This function should not have any parameters, because they would need to be parsed for vain if tracing is not enabled. -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] unused variable
Juha Heinanen writes: > It would be nice if devs would try to compile the code after making changes. I apologize. It was stupid statement. -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] sip_trace() broken in master
Daniel-Constantin Mierla writes: > Can you try with latest master? I pushed a commit that hopefully fixes > it. It works now. > On the other hand, the use of flag looks like no longer necessary if > tracing mode parameter is set to 't'. Would it be acceptable to just add > a new function sip_trace_mode() that will accept one parameter to > specify what to track (message, transaction, dialog)? It would be a > short form of sip_trace() with 3 parameters, when the two are not > needed. I think it would be more coherent for the future to get rid of > using also the message flag for tracking the transaction. For me it would be best and simplest if tracing of all request and responses would happen automatically when siptrace module is loaded and suitable parameters are set and when tracing is turned on via an rpc command, i.e., without any function calls in the config. If that cannot be achived and a function call is needed, one must be enough. -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] unused variable
With latest master, I got this: CC (gcc) [M db_mysql.so]km_dbase.o km_dbase.c: In function 'db_mysql_submit_query': km_dbase.c:71:9: warning: unused variable 't' [-Wunused-variable] time_t t; ^ It would be nice if devs would try to compile the code after making changes. -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] sip_trace() broken in master
Daniel-Constantin Mierla writes: > It is about storing in database? Or also mirroring? Storing to db. Don't know about mirroring. -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] sip_trace() broken in master
In 5.2 setflag(TRACE); sip_trace(); traces both requests and responses. In master, only requests. Please fix. -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] mysql_ping in db_mysql_submit_query
I build libmariadbclient18 with symbols (below) and got a new backtrace
of the hanging process.
I guess the only choice is to try with the newer lib that comes with
Debian Buster or give up use of db_cluster module with MySQL.
-- Juha
---start 24717 -
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x7f517466d8a0 in __poll_nocancel () at
../sysdeps/unix/syscall-template.S:84
84 ../sysdeps/unix/syscall-template.S: No such file or directory.
#0 0x7f517466d8a0 in __poll_nocancel () at
../sysdeps/unix/syscall-template.S:84
No locals.
#1 0x7f51725f3ef1 in poll (__timeout=2000, __nfds=1, __fds=0x7ffed132f808)
at /usr/include/x86_64-linux-gnu/bits/poll2.h:46
No locals.
#2 vio_io_wait (vio=vio@entry=0x560529eb39d8,
event=event@entry=VIO_IO_EVENT_READ, timeout=2000) at ./vio/viosocket.c:992
ret =
revents =
pfd = {fd = 18, events = 3, revents = 0}
state = {m_flags = 3509778656, m_socket = 0x7ffed132f820, m_thread =
0x0, m_number_of_bytes = 21474836512, m_timer_start = 140732408199414, m_timer
= 0x7ffed132f8fc, m_operation = 3509778680, m_src_file = 0x7ffed132f8fc
"\376\177", m_src_line = 16, m_wait = 0x7f517398d010}
#3 0x7f51725f3f78 in vio_socket_io_wait (vio=vio@entry=0x560529eb39d8,
event=event@entry=VIO_IO_EVENT_READ) at ./vio/viosocket.c:108
timeout =
ret = -516
#4 0x7f51725f4082 in vio_read (vio=vio@entry=0x560529eb39d8,
buf=0x560529eb3bd8 "\001", size=size@entry=16384) at ./vio/viosocket.c:184
error =
ret =
flags = 64
#5 0x7f51725f4145 in vio_read_buff (vio=0x560529eb39d8, buf=0x560529eb7be8
"\001", size=4) at ./vio/viosocket.c:232
rc =
#6 0x7f51725cfe91 in my_real_read (net=0x7f5173d674e0,
complen=complen@entry=0x7ffed132f9f8, header=0 '\000') at ./sql/net_serv.cc:877
pos = 0x560529eb7be8 "\001"
length =
i =
retry_count =
len =
expect_error_packet =
alarmed = 0 '\000'
remain = 4
#7 0x7f51725d0d1c in my_net_read_packet (net=net@entry=0x7f5173d674e0,
read_from_server=read_from_server@entry=0 '\000') at ./sql/net_serv.cc:1140
len =
complen = 0
#8 0x7f51725c28af in cli_safe_read (mysql=mysql@entry=0x7f5173d674e0) at
./sql-common/client.c:587
net = 0x7f5173d674e0
len =
#9 0x7f51725c8323 in cli_advanced_command (mysql=0x7f5173d674e0,
command=, header=0x0, header_length=0, arg=0x0, arg_length=0,
skip_check=0 '\000', stmt=0x0) at ./sql-common/client.c:729
net = 0x7f5173d674e0
result = 0 '\000'
stmt_skip =
#10 0x7f51725be2a1 in mysql_ping (mysql=) at
./libmysql/libmysql.c:982
res =
#11 0x7f5172bb14e6 in db_mysql_submit_query (_h=0x7f51739ecff0,
_s=0x7f5172fff2d0 ) at km_dbase.c:83
t = 1568791290
i = 0
code = 22021
__func__ = "db_mysql_submit_query"
#12 0x7f5172deeb88 in db_do_submit_query (_h=0x7f51739ecff0,
_query=0x7f5172fff2d0 , submit_query=0x7f5172bb1149
) at db_query.c:58
ret = 32593
tvb = {tv_sec = 94580176772804, tv_usec = 139987808866288}
tve = {tv_sec = 109108585221, tv_usec = 1365799600152}
tz = {tz_minuteswest = 24, tz_dsttime = 65147}
tdiff = 1755212864
__func__ = "db_do_submit_query"
#13 0x7f5172df11ca in db_do_insert_cmd (_h=0x7f51739ecff0,
_k=0x7f51689e6960 , _v=0x7f51689e6c40 , _n=24,
val2str=0x7f5172baf7b8 , submit_query=0x7f5172bb1149
, mode=0) at db_query.c:242
off = 707
ret = 318
__func__ = "db_do_insert_cmd"
...
___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
