[sr-dev] git:master:95c18631: - added AUTH_USERNAME_EXPIRED auth api return code and used it in auth
Module: kamailio
Branch: master
Commit: 95c18631032c5510d4dc1e6b7aa815256ff3e688
URL:
https://github.com/kamailio/kamailio/commit/95c18631032c5510d4dc1e6b7aa815256ff3e688
Author: Juha Heinanen
Committer: Juha Heinanen
Date: 2019-03-27T11:10:16+02:00
- added AUTH_USERNAME_EXPIRED auth api return code and used it in auth
ephemeral authentication, when username is expired
---
Modified: src/modules/auth/api.h
Modified: src/modules/auth_ephemeral/authorize.c
---
Diff:
https://github.com/kamailio/kamailio/commit/95c18631032c5510d4dc1e6b7aa815256ff3e688.diff
Patch:
https://github.com/kamailio/kamailio/commit/95c18631032c5510d4dc1e6b7aa815256ff3e688.patch
---
diff --git a/src/modules/auth/api.h b/src/modules/auth/api.h
index 9730b409ed..33d131840a 100644
--- a/src/modules/auth/api.h
+++ b/src/modules/auth/api.h
@@ -39,6 +39,7 @@
*/
typedef enum auth_cfg_result {
AUTH_USER_MISMATCH = -8,/*!< Auth user != From/To user */
+ AUTH_USERNAME_EXPIRED = -7, /*!< Ephemeral auth username expired */
AUTH_NONCE_REUSED = -6, /*!< Returned if nonce is used more than
once */
AUTH_NO_CREDENTIALS = -5, /*!< Credentials missing */
AUTH_STALE_NONCE = -4, /*!< Stale nonce */
diff --git a/src/modules/auth_ephemeral/authorize.c
b/src/modules/auth_ephemeral/authorize.c
index 745f12d7ab..216332b321 100644
--- a/src/modules/auth_ephemeral/authorize.c
+++ b/src/modules/auth_ephemeral/authorize.c
@@ -203,7 +203,7 @@ int autheph_verify_timestamp(str *_username)
if (cur_time > expires)
{
LM_WARN("username has expired\n");
- return -1;
+ return AUTH_USERNAME_EXPIRED;
}
return 0;
@@ -255,10 +255,16 @@ static inline int digest_authenticate(struct sip_msg *_m,
str *_realm,
username = ((auth_body_t *) h->parsed)->digest.username.whole;
LM_DBG("username: %.*s\n", username.len, username.s);
- if (autheph_verify_timestamp(&username) < 0)
+ int res = autheph_verify_timestamp(&username);
+ if (res < 0)
{
- LM_ERR("invalid timestamp in username\n");
- return AUTH_ERROR;
+ if (res == -1)
+ {
+ LM_ERR("invalid timestamp in username\n");
+ return AUTH_ERROR;
+ } else {
+ return AUTH_USERNAME_EXPIRED;
+ }
}
SECRET_LOCK;
@@ -489,10 +495,16 @@ int ki_autheph_authenticate(sip_msg_t *_m, str
*susername, str *spassword)
return AUTH_ERROR;
}
- if (autheph_verify_timestamp(susername) < 0)
+ int res = autheph_verify_timestamp(susername);
+ if (res < 0)
{
- LM_ERR("invalid timestamp in username\n");
- return AUTH_ERROR;
+ if (res == -1)
+ {
+ LM_ERR("invalid timestamp in username\n");
+ return AUTH_ERROR;
+ } else {
+ return AUTH_USERNAME_EXPIRED;
+ }
}
LM_DBG("username: %.*s\n", susername->len, susername->s);
___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] git:5.2:ca470cb6: pv: add $def pseudo variable
Many of today's commits by Sergey Safarov seem to add new features to stable release, for example: Module: kamailio Branch: 5.2 Commit: ca470cb6c5f341c518b208e8e595be2ed1309802 URL: https://github.com/kamailio/kamailio/commit/ca470cb6c5f341c518b208e8e595be2ed1309802 Author: lazedo Committer: Sergey Safarov Date: 2019-03-30T15:08:50+03:00 pv: add $def pseudo variable Could someone explain what is going on? Has the "bug fixes only" policy regarding stable releases been relaxed? -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] git:5.2:ca470cb6: pv: add $def pseudo variable
Daniel-Constantin Mierla writes: > They were pushed by mistake and they were reverted -- if you spot one > that wasn't, list it here and it will be reverted as well. OK, thanks, Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] master siptrace not backwards compatible
I built K master and tried to use 5.2 config. That resulted in error: Apr 30 15:47:10 salmon /usr/bin/sip-proxy[1659]: ERROR: siptrace [siptrace.c:908]: w_sip_trace3(): no duplicate_uri modparam nor duplicate uri sip_trace() argument provided! I think it has been practice that backwards compatibility is provided by the next version. ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] master siptrace not backwards compatible
Juha Heinanen writes:
> I built K master and tried to use 5.2 config. That resulted in error:
>
> Apr 30 15:47:10 salmon /usr/bin/sip-proxy[1659]: ERROR: siptrace
> [siptrace.c:908]: w_sip_trace3(): no duplicate_uri modparam nor duplicate uri
> sip_trace() argument provided!
>
> I think it has been practice that backwards compatibility is provided by
> the next version.
This is my 5.2 config:
# -- siptrace params
modparam("siptrace", "db_url", "MYSQL_SIP_PROXY_USAGE_URL")
modparam("siptrace", "trace_flag", TRACE)
# -- function call
sip_trace();
I has to work as before without messing up with any duplicate stuff.
___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] siptrace module of master back to 5.2 level
I haven't got any response about the misery with siptrace module. I checked its commit history and become to the conclusion that many commits to master were done without any review whatsoever. For example, there was this commit: siptrace: remove unused trace flag ionutionita92 authored and henningw committed on Mar 19 which obviously badly broke normal use of the module. Then 10 days later the commit was reverted: siptrace: add trace_flag after it was removed ionutionita92 authored and henningw committed 29 days ago This is not how Kamailio should be developed. I'm proposing to revert the module back to 5.2 level after which new commits can be made to it provided that each commit is carefully tested before deployed. -- 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 module of master back to 5.2 level
Henning Westerholt writes: > About the actual issue - I had a look to this as well. It seems that the > logic for the duplicate_uri string might need to be changed. > > I will have another look and fix it or will refer it to the original > developer. I'm getting en error message to syslog from every request that my sip proxy is handling. This is pretty serious and should have been noticed if there was any real review of the commits. I'm also worried about possible performance implications of these commits. There should be none compared to 5.2 usage of sip_trace() function call, -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] still no fix to siptrace
siptrace module is still broken. would it be high time to revert back to 5.2 level and then make a new commit when the problem is fixed and fix properly tested? -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] still no fix to siptrace
Henning Westerholt writes: > In the end this is the git master development and should be not used > in production. I'm not using it for production but for testing where I need siptrace module due to tls. There should be some kind of policy regarding broken commits, i.e., for how long K can remain broken until a revert is done. -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] still no fix to siptrace
Daniel-Constantin Mierla writes: > This will be fixed, just a time when a lot of devs are traveling to > Berlin. It's a regression by a large enhancement of the module, there > are many commits there, so reverting is not the easiest option here, > because the enhancement has to stay, only the regression needs to be > fixed. It is very easy to revert to 5.2 level: - copy *.c and *.h from 5.2 siptrace to master - git commit -a I don't understand why it cannot be done while waiting for the fix to current master. I have GUI for siptrace, not for sipdump. -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] still no fix to siptrace
Daniel-Constantin Mierla writes:
> Anyhow, with Kamailio World finished, I just got a bit of time and
> pushed a commit -- no time to test right now, but maybe you can give it
> a try and then report if works. If not, I will dig further soon, just
> give the new error messages/details/...
There is no error messages anymore, but from a test call only ACK
appeared in db table:
modparam("siptrace", "db_url", "MYSQL_SIP_PROXY_USAGE_URL")
modparam("siptrace", "trace_flag", TRACE)
if (isflagset(TRACE)) {
INFO(Tracing $rm);
sip_trace();
};
May 9 13:03:49 host /usr/bin/sip-proxy[16575]: INFO: Tracing INVITE
May 9 13:03:51 host /usr/bin/sip-proxy[16575]: INFO: Tracing ACK
May 9 13:03:55 host /usr/bin/sip-proxy[16575]: INFO: Tracing BYE
You don't need to spend your time on this, since your commits didn't
break the module. Just go back to 5.2 level and let the person who
implemented the new features to fix the code.
-- 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] siptrace: fix tracing messages to database when destination uri not set (#1951)
Ionut Ionita writes: > I did the fix but I think the implementation as it was it's a little > broken. That is because you can trace only to database using sip_trace > with no arguments, but you can't trace only to database if using > correlation_id(this was the case in previous versions). With the new > additions you can't trace a dialog only to database. I respected > previous implementation, that's why duplicate URI was mandatory, but > this check is skipped if sip_trace is used with 0 or 1 argument, which > I didn't notice. I don't understand from the above, if after this fix the very basic existing usage of siptrace module (if flag is set sip_trace(); adds the trace to db) works or not. I would feel comfortable, if you would leave the 5.2 code of the simple usage untouched and write your extensions in new sections of the code rather than making the simple usage a special case in a more complex implementation. -- 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] siptrace: fix tracing messages to database when destination uri not set (#1951)
Ionut Ionita writes:
> Yes it works but the code in 5.2 is broken. Here's an example, maybe
> it's more clear:
>
> sip_trace(); /* traces to database only no db url */
> sip_trace("", "$var(correlation_id)"); /* does not work; requires valid
> duplicate uri */
> // with my additions
> sip_trace("", "$var(correlation_id)", "d"); /* does not work; requires valid
> duplicate uri */
>
> So there are basically 2 functions:
> - no arguments - trace to dabase only;
> - with any kind of arguments - trace to duplicate uri and(if set) to
> database;
Then leave implementation of the working part (sip_trace();) as is and
add code to fix the broken part.
-- Juha
___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] [SR-Users] Plans for next major release - v5.3.0
Daniel-Constantin Mierla writes: > Any preference for one of the two options? I would prefer release after holidays. Freeze and testing OK during that period. -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] mysql related warning when building 5.2 on Debian Buster
I got this warning when building 5.2 on Debian Buster: CC (gcc) [M db_mysql.so]km_dbase.o In file included from km_dbase.c:38: /usr/include/mariadb/mysql_version.h:3:2: warning: #warning This file should not be included by clients, include only [-Wcpp] #warning This file should not be included by clients, include only ^~~ -- 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 related warning when building 5.2 on Debian Buster
Henning Westerholt writes: > does it still compile if you remove the header on buster? K master compiles OK and it doesn't have #include -- 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 related warning when building 5.2 on Debian Buster
Henning Westerholt writes: > I backported the fix from Victor as well to 5.1 and 5.2. 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:fe6614fe: modules/rtpengine: set_rtpengine_set fix
Module: kamailio
Branch: master
Commit: fe6614feb5f9b062a556de82fd7df6fc12c96471
URL:
https://github.com/kamailio/kamailio/commit/fe6614feb5f9b062a556de82fd7df6fc12c96471
Author: Juha Heinanen
Committer: Juha Heinanen
Date: 2019-08-23T10:05:33+03:00
modules/rtpengine: set_rtpengine_set fix
---
Modified: src/modules/rtpengine/rtpengine.c
---
Diff:
https://github.com/kamailio/kamailio/commit/fe6614feb5f9b062a556de82fd7df6fc12c96471.diff
Patch:
https://github.com/kamailio/kamailio/commit/fe6614feb5f9b062a556de82fd7df6fc12c96471.patch
---
diff --git a/src/modules/rtpengine/rtpengine.c
b/src/modules/rtpengine/rtpengine.c
index 7a6b73d747..6e436083ec 100644
--- a/src/modules/rtpengine/rtpengine.c
+++ b/src/modules/rtpengine/rtpengine.c
@@ -3079,6 +3079,15 @@ select_rtpp_node_old(str callid, str viabranch, int
do_test, enum rtpe_operation
return node;
}
+unsigned int node_in_set(struct rtpp_node *node, struct rtpp_set *set) {
+ struct rtpp_node *current = set->rn_first;
+ while (current) {
+ if (current->idx == node->idx) return 1;
+ current = current->rn_next;
+ }
+ return 0;
+}
+
/*
* Main balancing routine. This DO try to keep the same proxy for
* the call if some proxies were disabled or enabled (e.g. kamctl command)
@@ -3107,7 +3116,7 @@ select_rtpp_node(str callid, str viabranch, int do_test,
struct rtpp_node **quer
node = select_rtpp_node_old(callid, viabranch, do_test, op);
// check node
- if (!node) {
+ if (!node || (node_in_set(node, active_rtpp_set) == 0)) {
// run the selection algorithm
node = select_rtpp_node_new(callid, viabranch, do_test,
queried_nodes_ptr, queried_nodes);
___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] mysql_ping in db_mysql_submit_query
As was found out in "Kamailio stops processing requests over UDP"
thread, db_mysql_submit_query() in some circumstances hangs when it
executes mysql_ping here:
if (my_ping_interval) {
t = time(0);
if ((t - CON_TIMESTAMP(_h)) > my_ping_interval) {
for (i=0; i < (db_mysql_auto_reconnect ? 3 : 1); i++) {
if (mysql_ping(CON_CONNECTION(_h))) {
LM_INFO("driver error on ping: %s\n",
mysql_error(CON_CONNECTION(_h)));
counter_inc(mysql_cnts_h.driver_err);
} else {
break;
}
}
}
...
}
Comment in front of db_mysql_submit_query() function tells:
* Send a SQL query to the database server. This methods tries to reconnect
* to the server if the connection is gone and the auto_reconnect parameter is
* enabled. It also issues a mysql_ping before the query to connect again after
* a long waiting period because for some older mysql versions the auto
reconnect
* don't work sufficient. If auto_reconnect is enabled and the server supports
it,
* then the mysql_ping is probably not necessary, but its safer to do it in this
* cases too.
*
The text was most likely written many years ago and auto reconnect now
works OK in mysql versions in use today.
I would like to test if the hangup could be prevented without the above
code. Would it be possible to make the code optional via a compilation
flag or by some other means?
-- 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
Daniel-Constantin Mierla writes: > I would suggest to add a new module parameter to control it, it is > better than a compile time flag. > > Being code that tries to resolve a bug/issue, it can still be pushed to > master branch even it is testing phase, and if proves to be useless can > be reverted later. I'll comment the ping code away locally and do tests without it. If hanging doesn't happen without it, I'll add the module param. -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] siptrace warning
On masterm, I noticed that I have started to get a warning from siptrace mod_init() even when there is nothing to warn about: Sep 7 15:21:45 salmon /usr/bin/sip-proxy[30966]: WARNING: siptrace [siptrace.c:338]: mod_init(): can't load dlg api. Will not install dialog callbacks. -- 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 warning
Henning Westerholt writes: > just to understand it correctly: > > - is the dialog module loaded and acc generates the warning nevertheless? > > - is the dialog module not loaded, but you don't use the dialog > functionality of acc? Dialog module is not loaded and I'm not tracing dialogs. -- 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:ce19d921: siptrace: turn warn into info message about loading dlg api
Daniel-Constantin Mierla writes: > siptrace: turn warn into info message about loading dlg api Info is better than warning, but I would prefer no message at all. These kind of things are in README file and don't need to appear in syslog. The code should check if dialog module is available when tracing of a dialog is attempted and issue an error if that is not the case. There are lots of other similar cases when a function cannot be executed if required modules are not loaded or if a certain module variable is not set accordingly. -- Juha ___ 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:ce19d921: siptrace: turn warn into info message about loading dlg api
Daniel-Constantin Mierla writes: > There will be no message for this case when the way to disable dialog > tracking is figured out. 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] mysql_ping in db_mysql_submit_query
Juha Heinanen writes:
> I'll comment the ping code away locally and do tests without it. If
> hanging doesn't happen without it, I'll add the module param.
Unfortunately udp receiver hangs also without mysql_ping. Now hang
happens in insert (below).
Will try next without cluster if regular insert would work.
-- Juha
---start 4576 -
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x7fa641ed98a0 in __poll_nocancel () at
../sysdeps/unix/syscall-template.S:84
84 ../sysdeps/unix/syscall-template.S: No such file or directory.
#0 0x7fa641ed98a0 in __poll_nocancel () at
../sysdeps/unix/syscall-template.S:84
No locals.
#1 0x7fa63fe5fec1 in ?? () from
/usr/lib/x86_64-linux-gnu/libmariadbclient.so.18
No symbol table info available.
#2 0x7fa63fe5ff48 in ?? () from
/usr/lib/x86_64-linux-gnu/libmariadbclient.so.18
No symbol table info available.
#3 0x7fa63fe60052 in ?? () from
/usr/lib/x86_64-linux-gnu/libmariadbclient.so.18
No symbol table info available.
#4 0x7fa63fe60115 in ?? () from
/usr/lib/x86_64-linux-gnu/libmariadbclient.so.18
No symbol table info available.
#5 0x7fa63fe3be51 in ?? () from
/usr/lib/x86_64-linux-gnu/libmariadbclient.so.18
No symbol table info available.
#6 0x7fa63fe3ccec in ?? () from
/usr/lib/x86_64-linux-gnu/libmariadbclient.so.18
No symbol table info available.
#7 0x7fa63fe2e87f in ?? () from
/usr/lib/x86_64-linux-gnu/libmariadbclient.so.18
No symbol table info available.
#8 0x7fa63fe2ffae in mysql_free_result () from
/usr/lib/x86_64-linux-gnu/libmariadbclient.so.18
No symbol table info available.
#9 0x7fa63fe31936 in mysql_real_query () from
/usr/lib/x86_64-linux-gnu/libmariadbclient.so.18
No symbol table info available.
#10 0x7fa64040c05c in db_mysql_submit_query (_h=0x7fa641258a90,
_s=0x7fa64086b2d0 ) at km_dbase.c:112
i = 0
code = 32678
__func__ = "db_mysql_submit_query"
#11 0x7fa64065ab88 in db_do_submit_query (_h=0x7fa641258a90,
_query=0x7fa64086b2d0 , submit_query=0x7fa64040bcf1
) at db_query.c:58
ret = 32678
tvb = {tv_sec = 94212721508036, tv_usec = 140352034278032}
tve = {tv_sec = 108261778181, tv_usec = 1382979469336}
tz = {tz_minuteswest = 24, tz_dsttime = 65147}
tdiff = 908405824
__func__ = "db_do_submit_query"
#12 0x7fa64065d1ca in db_do_insert_cmd (_h=0x7fa641258a90,
_k=0x7fa636252960 , _v=0x7fa636252c40 , _n=24,
val2str=0x7fa6404255a6 , submit_query=0x7fa64040bcf1
, mode=0) at db_query.c:242
off = 711
ret = 322
__func__ = "db_do_insert_cmd"
#13 0x7fa64065d831 in db_do_insert (_h=0x7fa641258a90, _k=0x7fa636252960
, _v=0x7fa636252c40 , _n=24, val2str=0x7fa6404255a6
, submit_query=0x7fa64040bcf1 ) at
db_query.c:257
No locals.
#14 0x7fa640410a6a in db_mysql_insert (_h=0x7fa641258a90, _k=0x7fa636252960
, _v=0x7fa636252c40 , _n=24) at km_dbase.c:494
No locals.
#15 0x7fa63768055c in db_cluster_insert (_h=0x7fa64145cd90,
_k=0x7fa636252960 , _v=0x7fa636252c40 , _n=24) at
dbcl_api.c:379
ret = -1
i = 5
k = 32678
sec = 56341002
rc = 0
rok = 0
j = 0
dbh = 0x7fa641258a90
cls = 0x7fa641274c20
__func__ = "db_cluster_insert"
#16 0x7fa63601d66c in acc_db_request (rq=0x7fa6292a26f0) at acc.c:476
m = 24
n = 690628336
i = 24
o = 17
t = 0x7fa6292a35a8
dtime = -2.8399536906951675e-300
__func__ = "acc_db_request"
#17 0x7fa636030230 in acc_onreply (t=0x7fa6292a9c50, req=0x7fa6292ad410,
reply=0x, code=408) at acc_logic.c:604
...
___
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
Juha Heinanen writes: > Unfortunately udp receiver hangs also without mysql_ping. Now hang > happens in insert (below). > > Will try next without cluster if regular insert would work. So far no hang when acc is not using cluster db_url. Cluster has two connections with mode "5s5s". If I have understood correctly, underlying db_mysql module is not aware of the cluster. If so, how could use of cluster cause hang in libmariadb? -- 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
Daniel-Constantin Mierla writes: > Are the two connections going to the same mysql server? Or different ones? Different ones. > Are you able to see from the logs if writing to the first connection > failed and it tried to the second one? No, everything seems normal. Here is the last working acc insert before the freeze: Sep 2 12:00:20 rox2 /usr/bin/sip-proxy[341]: DEBUG: acc [acc_logic.c:446]: should_acc_reply(): acc is on Sep 2 12:00:20 rox2 /usr/bin/sip-proxy[341]: DEBUG: db_cluster [dbcl_api.c:482]: db_cluster_use_table(): use table (accounting) - cluster [sip_proxy_usage_cluster] Sep 2 12:00:20 rox2 /usr/bin/sip-proxy[341]: DEBUG: db_cluster [dbcl_api.c:491]: db_cluster_use_table(): set read table (accounting) - cluster [sip_proxy_usage_cluster] (5/0) Sep 2 12:00:20 rox2 /usr/bin/sip-proxy[341]: DEBUG: db_cluster [dbcl_api.c:501]: db_cluster_use_table(): set write table (accounting) - cluster [sip_proxy_usage_cluster] (5/0) Sep 2 12:00:20 rox2 /usr/bin/sip-proxy[341]: DEBUG: db_cluster [dbcl_api.c:491]: db_cluster_use_table(): set read table (accounting) - cluster [sip_proxy_usage_cluster] (4/0) Sep 2 12:00:20 rox2 /usr/bin/sip-proxy[341]: DEBUG: db_cluster [dbcl_api.c:501]: db_cluster_use_table(): set write table (accounting) - cluster [sip_proxy_usage_cluster] (4/0) Sep 2 12:00:20 rox2 /usr/bin/sip-proxy[341]: DEBUG: db_cluster [dbcl_api.c:378]: db_cluster_insert(): executing db cluster insert command Sep 2 12:00:20 rox2 /usr/bin/sip-proxy[341]: DEBUG: db_cluster [dbcl_api.c:379]: db_cluster_insert(): serial operation - cluster [sip_proxy_usage_cluster] (5/0) Sep 2 12:00:20 rox2 /usr/bin/sip-proxy[341]: DEBUG: acc [acc_extra.h:63]: free_strar_mem(): Freeing memory, type is 2, message_index 7, index i 0 Sep 2 12:00:20 rox2 /usr/bin/sip-proxy[341]: DEBUG: tm [t_reply.c:1667]: cleanup_uac_timers(): RETR/FR timers reset Sep 2 12:00:20 rox2 /usr/bin/sip-proxy[341]: DEBUG: [core/receive.c:442]: receive_msg(): reply-route executed in: 1395 usec Sep 2 12:00:20 rox2 /usr/bin/sip-proxy[341]: DEBUG: [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) Sep 2 12:00:20 rox2 /usr/bin/sip-proxy[341]: DEBUG: [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) Sep 2 12:00:20 rox2 /usr/bin/sip-proxy[341]: DEBUG: [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) Sep 2 12:00:20 rox2 /usr/bin/sip-proxy[341]: DEBUG: [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) Sep 2 12:00:20 rox2 /usr/bin/sip-proxy[341]: DEBUG: [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) Sep 2 12:00:20 rox2 /usr/bin/sip-proxy[341]: DEBUG: [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) Sep 2 12:00:20 rox2 /usr/bin/sip-proxy[341]: DEBUG: [core/xavp.c:495]: xavp_destroy_list(): destroying xavp list (nil) Sep 2 12:00:20 rox2 /usr/bin/sip-proxy[341]: DEBUG: [core/receive.c:458]: receive_msg(): cleaning up Sep 2 12:00:20 rox2 /usr/bin/sip-proxy[341]: DEBUG: [core/udp_server.c:491]: udp_rcv_loop(): received on udp socket: (112/100/1063) [[INVITE ...]] After that there is a couple of these: Sep 2 12:00:21 rox2 /usr/bin/sip-proxy[341]: DEBUG: acc [acc_logic.c:413]: should_acc_reply(): probing acc state - code: 183 flags: 0x200209c0 Sep 2 12:00:21 rox2 /usr/bin/sip-proxy[341]: DEBUG: acc [acc_logic.c:442]: should_acc_reply(): early media acc is off And finally the last should_acc_reply() before the freeze that does not result to any kind db_cluster entry in syslog: Sep 2 12:00:21 rox2 /usr/bin/sip-proxy[341]: DEBUG: acc [acc_logic.c:413]: should_acc_reply(): probing acc state - code: 480 flags: 0x240005c4 Sep 2 12:00:21 rox2 /usr/bin/sip-proxy[341]: DEBUG: acc [acc_logic.c:430]: should_acc_reply(): failed acc is on Sep 2 12:00:21 rox2 /usr/bin/sip-proxy[341]: DEBUG: tm [t_lookup.c:]: t_check_msg(): msg (0x7f2383bea9e0) id=12872/341 global id=12872/341 T end=0x7f236b1cc3f0 Sep 2 12:00:21 rox2 /usr/bin/sip-proxy[341]: DEBUG: tm [t_reply.c:2243]: reply_received(): transaction found - T:0x7f236b1cc3f0 branch:0 Next process 341 entry in syslog is 13+ minutes later after the freeze: Sep 2 12:13:55 rox2 /usr/bin/sip-proxy[341]: DEBUG: tm [t_reply.c:2256]: reply_received(): org. status uas=408, uac[0]=408 local=0 is_invite=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] mysql_ping in db_mysql_submit_query
Juha Heinanen writes:
> And finally the last should_acc_reply() before the freeze that does not
> result to any kind db_cluster entry in syslog:
>
> Sep 2 12:00:21 rox2 /usr/bin/sip-proxy[341]: DEBUG: acc [acc_logic.c:413]:
> should_acc_reply(): probing acc state - code: 480 flags: 0x240005c4
> Sep 2 12:00:21 rox2 /usr/bin/sip-proxy[341]: DEBUG: acc [acc_logic.c:430]:
> should_acc_reply(): failed acc is on
> Sep 2 12:00:21 rox2 /usr/bin/sip-proxy[341]: DEBUG: tm [t_lookup.c:]:
> t_check_msg(): msg (0x7f2383bea9e0) id=12872/341 global id=12872/341 T
> end=0x7f236b1cc3f0
> Sep 2 12:00:21 rox2 /usr/bin/sip-proxy[341]: DEBUG: tm [t_reply.c:2243]:
> reply_received(): transaction found - T:0x7f236b1cc3f0 branch:0
I guess because process 341 is waiting for a lock (below). Before this
acc attempt I have not found any failing ones. They have all ended up in
cleaning of memory, cleanup_uac_timers(), and reply-route executed.
-- Juha
---start 341 -
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
38 ../sysdeps/unix/sysv/linux/x86_64/syscall.S: No such file or directory.
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
No locals.
#1 0x7f2380e7f05d in futex_get (lock=0x7f236b1cc5c0) at
../../core/parser/../mem/../futexlock.h:108
v = 2
i = 1024
#2 0x7f2380e80f10 in _lock (s=0x7f236b1cc5c0) at lock.h:80
No locals.
#3 0x7f2380ea04e8 in tm_reply_mutex_lock (t=0x7f236b1cc3f0) at
t_reply.c:2928
mypid = 341
#4 0x7f2380e9ab51 in reply_received (p_msg=0x7f2383bea9e0) at
t_reply.c:2248
msg_status = 2011789584
last_uac_status = 271554156
ack = 0x1ffb
ack_len = 2011789776
branch = 0
reply_status = 32765
onreply_route = 271554156
cancel_data = {cancel_bitmap = 2213206539, reason = {cause = 24, u =
{text = {s = 0x7ffd77e97a90 "\227\224D\017AV", len = 271554144}, e2e_cancel =
0x7ffd77e97a90, packed_hdrs = {s = 0x7ffd77e97a90 "\227\224D\017AV", len =
271554144
uac = 0x31343341101bac10
...
___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] missing db structure changes
Upgrade instructions to 5.3 are missing db structure changes: https://www.kamailio.org/wiki/install/upgrade/stable-to-devel I remember seeing many in the commits. It would be a good idea (actually Kamailio policy) to immediately update the wiki when a db change is made. -- Juha ___ Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] missing db structure changes
Daniel-Constantin Mierla writes: > I generated the sql statements for upgrading from 5.2 to 5.3, most of them > being increase of size for columns. The wiki page is: > > * https://www.kamailio.org/wiki/install/upgrade/5.2.x-to-5.3.0 Thanks. As I mentioned, it would be good if people who make db schema changes in their modules, would at the same time update the wiki 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] 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
[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] 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] 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: > 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
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
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
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
[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] 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
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: > 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
[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
[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] 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
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
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
[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] 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] 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] [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
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
[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
[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] 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] 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 https://lists.kamailio.o
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] is liblua5.3 supported?
debian stretch has liblua5.3. is that version supported by kamailio or is 5.1 still required? -- 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:91a81625: srdb1/schema: made 'domain_attrs_domain_attrs_idx' index not unique
Module: kamailio
Branch: master
Commit: 91a81625f89da38e5890f3b3c84ed4141eb3652c
URL:
https://github.com/kamailio/kamailio/commit/91a81625f89da38e5890f3b3c84ed4141eb3652c
Author: Juha Heinanen
Committer: Juha Heinanen
Date: 2017-04-15T17:39:39+03:00
srdb1/schema: made 'domain_attrs_domain_attrs_idx' index not unique
and removed 'value' field from the index
- generated sql files from schema
---
Modified: src/lib/srdb1/schema/domain_attrs.xml
Modified: utils/kamctl/db_sqlite/domain-create.sql
Modified: utils/kamctl/mysql/domain-create.sql
Modified: utils/kamctl/oracle/domain-create.sql
Modified: utils/kamctl/postgres/domain-create.sql
---
Diff:
https://github.com/kamailio/kamailio/commit/91a81625f89da38e5890f3b3c84ed4141eb3652c.diff
Patch:
https://github.com/kamailio/kamailio/commit/91a81625f89da38e5890f3b3c84ed4141eb3652c.patch
---
diff --git a/src/lib/srdb1/schema/domain_attrs.xml
b/src/lib/srdb1/schema/domain_attrs.xml
index 6f60781..0dedf38 100644
--- a/src/lib/srdb1/schema/domain_attrs.xml
+++ b/src/lib/srdb1/schema/domain_attrs.xml
@@ -65,7 +65,5 @@
domain_attrs_idx
-
-
diff --git a/utils/kamctl/db_sqlite/domain-create.sql
b/utils/kamctl/db_sqlite/domain-create.sql
index 5586eee..399e10e 100644
--- a/utils/kamctl/db_sqlite/domain-create.sql
+++ b/utils/kamctl/db_sqlite/domain-create.sql
@@ -14,9 +14,10 @@ CREATE TABLE domain_attrs (
name VARCHAR(32) NOT NULL,
type INTEGER NOT NULL,
value VARCHAR(255) NOT NULL,
-last_modified TIMESTAMP WITHOUT TIME ZONE DEFAULT '2000-01-01 00:00:01'
NOT NULL,
-CONSTRAINT domain_attrs_domain_attrs_idx UNIQUE (did, name, value)
+last_modified TIMESTAMP WITHOUT TIME ZONE DEFAULT '2000-01-01 00:00:01'
NOT NULL
);
+CREATE INDEX domain_attrs_domain_attrs_idx ON domain_attrs (did, name);
+
INSERT INTO version (table_name, table_version) values ('domain_attrs','1');
diff --git a/utils/kamctl/mysql/domain-create.sql
b/utils/kamctl/mysql/domain-create.sql
index 393fdab..44238e1 100644
--- a/utils/kamctl/mysql/domain-create.sql
+++ b/utils/kamctl/mysql/domain-create.sql
@@ -14,9 +14,10 @@ CREATE TABLE `domain_attrs` (
`name` VARCHAR(32) NOT NULL,
`type` INT UNSIGNED NOT NULL,
`value` VARCHAR(255) NOT NULL,
-`last_modified` DATETIME DEFAULT '2000-01-01 00:00:01' NOT NULL,
-CONSTRAINT domain_attrs_idx UNIQUE (`did`, `name`, `value`)
+`last_modified` DATETIME DEFAULT '2000-01-01 00:00:01' NOT NULL
);
+CREATE INDEX domain_attrs_idx ON domain_attrs (`did`, `name`);
+
INSERT INTO version (table_name, table_version) values ('domain_attrs','1');
diff --git a/utils/kamctl/oracle/domain-create.sql
b/utils/kamctl/oracle/domain-create.sql
index ee1fe99..39e41a0 100644
--- a/utils/kamctl/oracle/domain-create.sql
+++ b/utils/kamctl/oracle/domain-create.sql
@@ -22,8 +22,7 @@ CREATE TABLE domain_attrs (
name VARCHAR2(32),
type NUMBER(10),
value VARCHAR2(255),
-last_modified DATE DEFAULT to_date('2000-01-01 00:00:01','-mm-dd
hh24:mi:ss'),
-CONSTRAINT domain_attrs_domain_attrs_idx UNIQUE (did, name, value)
+last_modified DATE DEFAULT to_date('2000-01-01 00:00:01','-mm-dd
hh24:mi:ss')
);
CREATE OR REPLACE TRIGGER domain_attrs_tr
@@ -34,5 +33,7 @@ END domain_attrs_tr;
/
BEGIN map2users('domain_attrs'); END;
/
+CREATE INDEX domain_attrs_domain_attrs_idx ON domain_attrs (did, name);
+
INSERT INTO version (table_name, table_version) values ('domain_attrs','1');
diff --git a/utils/kamctl/postgres/domain-create.sql
b/utils/kamctl/postgres/domain-create.sql
index c358bdf..e4345ff 100644
--- a/utils/kamctl/postgres/domain-create.sql
+++ b/utils/kamctl/postgres/domain-create.sql
@@ -14,9 +14,10 @@ CREATE TABLE domain_attrs (
name VARCHAR(32) NOT NULL,
type INTEGER NOT NULL,
value VARCHAR(255) NOT NULL,
-last_modified TIMESTAMP WITHOUT TIME ZONE DEFAULT '2000-01-01 00:00:01'
NOT NULL,
-CONSTRAINT domain_attrs_domain_attrs_idx UNIQUE (did, name, value)
+last_modified TIMESTAMP WITHOUT TIME ZONE DEFAULT '2000-01-01 00:00:01'
NOT NULL
);
+CREATE INDEX domain_attrs_domain_attrs_idx ON domain_attrs (did, name);
+
INSERT INTO version (table_name, table_version) values ('domain_attrs','1');
___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Re: [sr-dev] is liblua5.3 supported?
Daniel-Constantin Mierla writes: > In the Makefile the module tries to detect lua 5.1 or 5.2, so I guess > both should be fine. I haven't tried with 5.3 -- does it give compile > errors? I haven't tried either. Perhaps it better to stick with lua 5.2, since it is still used with lots of other Debian Stretch packages. -- Juha ___ 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
[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
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
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] 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: > 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
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: > 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
[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
[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
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] 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
[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
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
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] [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] [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
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
[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
[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 /lib/x86_64-linux-
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
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 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
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
[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] 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] 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] 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
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: > 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
[sr-dev] git:master:f2996bf7: registrar: added note about branch flags in save()/lookup() doc
Module: kamailio
Branch: master
Commit: f2996bf733a0b5e00fe124440353b9a69a3532a2
URL:
https://github.com/kamailio/kamailio/commit/f2996bf733a0b5e00fe124440353b9a69a3532a2
Author: Juha Heinanen
Committer: Juha Heinanen
Date: 2020-10-20T11:04:58+03:00
registrar: added note about branch flags in save()/lookup() doc
---
Modified: src/modules/registrar/doc/registrar_admin.xml
---
Diff:
https://github.com/kamailio/kamailio/commit/f2996bf733a0b5e00fe124440353b9a69a3532a2.diff
Patch:
https://github.com/kamailio/kamailio/commit/f2996bf733a0b5e00fe124440353b9a69a3532a2.patch
---
diff --git a/src/modules/registrar/doc/registrar_admin.xml
b/src/modules/registrar/doc/registrar_admin.xml
index 4fb1e8a5e8..94ce4b3a0b 100644
--- a/src/modules/registrar/doc/registrar_admin.xml
+++ b/src/modules/registrar/doc/registrar_admin.xml
@@ -1180,7 +1180,8 @@ kamcmd cfg.set_now_int registrar use_expired_contacts 0
modify location records (in usrloc) depending on Contact and
Expires header fields in the
REGISTER message. On success and when called from the
REQUEST_ROUTE,
200 OK will be returned listing all contacts
that are currently in
- the location database. On an error, an error message will be
sent with a short
+ the location database. As a side effect, also branch flags are
+stored in usrloc. On an error, an error message will be sent with a
short
description in reason phrase.
Meaning of the parameters is as follows:
@@ -1281,6 +1282,7 @@ save("location", "0x00", "sip:t...@kamailio.org");
Request-URI will be overwritten with the contact that has
the highest q value and optionally the rest will be appended to
the message (depending on append_branches parameter value).
+As a side effect, also branch flags are restored from usrloc.
If the method_filtering option is enabled and
___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
[sr-dev] use_dst_blacklist syntax error
Latest master does not like this line in config: use_dst_blacklist=on Start with option -c gives: 0(19289) CRITICAL: [core/cfg.y:3611]: yyerror_at(): parse error in config file /etc/pres-serv/pres-serv.cfg, line 137, column 18: syntax error 0(19289) CRITICAL: [core/cfg.y:3611]: yyerror_at(): parse error in config file /etc/pres-serv/pres-serv.cfg, line 137, column 18: unknown config variable 0(19289) CRITICAL: [core/cfg.y:3608]: yyerror_at(): parse error in config file /etc/pres-serv/pres-serv.cfg, line 137, column 19-20: ERROR: bad config file (3 errors) According to core cookbook, the var exists. With 5.4 the same config file is accepted. -- 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] [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] [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)
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
[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
[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
core
[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
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
