I have 3 registrars being replicated to each other using dmq_usrloc. These registrars sit behind proxy servers. I use the path header to specify the received address. When the nathelper module is enabled, the nathelper then sends keep alive options messages from all three registrars for the same contact instead of the node that processed the original registration.
I am using in-memory replication (db_mode = 0), so the server_id core parameter does not seem to be taking affect for in-memory replication, i believe this is only for database mode only. I currently have server_id set differently for each registrar, to no effect.
nathelper module configuration parameters are as follows:
```
modparam("nathelper", "natping_interval", 20)
modparam("nathelper", "natping_processes", 4)
modparam("nathelper", "ping_nated_only", 1)
modparam("nathelper", "sipping_from", "sip:keepalive@domain.com")
modparam("nathelper", "sipping_method", "OPTIONS")
modparam("nathelper", "force_socket", NAT_PING_SOCKET)
```
NAT_PING_SOCKET is set to the local interface of each registrar where I want the message to originate from:
```
# Registrar01
#!define NAT_PING_SOCKET "10.7.0.170:5060"
# Registrar02
#!define NAT_PING_SOCKET "10.7.0.171:5060"
# Registrar03
#!define NAT_PING_SOCKET "10.7.0.172:5060"
```
server_id is set for each registrar
```
# Registrar01
server_id=001
# Registrar02
server_id=002
# Registrar03
server_id=003
```
I noticed that when the force_socket is set and a registration is sent from a node that did not process the request, then an options messages is sent via the forced_socket but the originating IP is that of the primary interface of the node, in this case, the kamailio listening address on the 10.6.0.0/24 segment, and example message follows:
```
12:42:13.320519 00:50:56:91:5e:77 > 00:50:56:91:64:fe, ethertype IPv4 (0x0800), length 455: (tos 0x60, ttl 64, id 62009, offset 0, flags [none], proto UDP (17), length 441)
10.6.0.170.sip > 10.7.0.109.sip: [udp sum ok] SIP, length: 413
OPTIONS sip:subscriber01@172.16.0.138:5060;alias=78.143.152.30~49233~1 SIP/2.0
Via: SIP/2.0/UDP 10.6.0.170:5060;branch=0
Route: <sip:10.7.0.109;lr;received=sip:78.143.152.30:49233>
From: sip:keepalive@domain.com;tag=uloc-3-55e0473b-1503-af38-6cf5fbae-864c1976
To: sip:subscriber01@172.16.0.138:5060;alias=78.143.152.30~49233~1
Call-ID: 9f855711-a24ef866-112a3d5(a)10.6.0.170
CSeq: 1 OPTIONS
Content-Length: 0
```
The MAC address above confirms that the sending interface is that of force_socket for nathelper, but the source IP address is that of the primary interface of the registrar.
This results in martian source messages on the target proxy server:
```
Aug 31 12:42:13 proxy01 kernel: martian source 10.7.0.109 from 10.6.0.170, on dev eth1
Aug 31 12:42:13 proxy01 kernel: ll header: 00:50:56:91:64:fe:00:50:56:91:5e:77:08:00
```
I suspect the latter issue (martian source) will resolve itself if the registrar not processing the registration stops sending nathelper keep alive messages for contacts it did not itself process.
Please let me know if you require any additional information from me to debug this issue further.
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/310
Commit is the latest for 4.3: 48d78ce87e2f42bdc77e688a0f45ff725ea97de5
Here is the backtrace:
```
Program terminated with signal 11, Segmentation fault.
#0 0x00007f3b4fd779da in update_dialog_vars_dbinfo (cell=0x7f3b3c3aa958, var=0x3433) at dlg_db_handler.c:651
651 SET_STR_VALUE(values+2, var->key);
Missing separate debuginfos, use: debuginfo-install bzip2-libs-1.0.5-7.el6_0.x86_64 db4-4.7.25-19.el6_6.x86_64 elfutils-libelf-0.161-3.el6.x86_64 glibc-2.12-1.166.el6_7.1.x86_64 keyutils-libs-1.4-5.el6.x86_64 krb5-libs-1.10.3-42.el6.x86_64 libacl-2.2.49-6.el6.x86_64 libattr-2.4.44-7.el6.x86_64 libcap-2.16-5.5.el6.x86_64 libcom_err-1.41.12-22.el6.x86_64 libgcc-4.4.7-16.el6.x86_64 libselinux-2.0.94-5.8.el6.x86_64 lm_sensors-libs-3.1.1-17.el6.x86_64 lua-5.1.4-4.1.el6.x86_64 mysql-libs-5.1.73-5.el6_6.x86_64 net-snmp-libs-5.5-54.el6_7.1.x86_64 nspr-4.10.8-1.el6_6.x86_64 nss-3.19.1-3.el6_6.x86_64 nss-softokn-freebl-3.14.3-22.el6_6.x86_64 nss-util-3.19.1-1.el6_6.x86_64 openssl-1.0.1e-42.el6.x86_64 pcre-7.8-7.el6.x86_64 perl-libs-5.10.1-141.el6.x86_64 popt-1.13-7.el6.x86_64 rpm-libs-4.8.0-47.el6.x86_64 tcp_wrappers-libs-7.6-57.el6.x86_64 xz-libs-4.999.9-0.5.beta.20091007git.el6.x86_64 zlib-1.2.3-29.el6.x86_64
(gdb) bt
#0 0x00007f3b4fd779da in update_dialog_vars_dbinfo (cell=0x7f3b3c3aa958, var=0x3433) at dlg_db_handler.c:651
#1 0x00007f3b4fd78511 in update_dialog_dbinfo_unsafe (cell=0x7f3b3c3aa958) at dlg_db_handler.c:718
#2 0x00007f3b4fd79afc in update_dialog_dbinfo (cell=0x7f3b3c3aa958) at dlg_db_handler.c:861
#3 0x00007f3b4fdb93dc in set_dlg_variable (dlg=0x7f3b3c3aa958, key=0x7f3b508b8760, val=0x7fff7efaae60) at dlg_var.c:305
#4 0x00007f3b50696a9c in set_start_time (dialog=0x7f3b3c3aa958) at acc_cdr.c:523
#5 0x00007f3b5069c932 in cdr_on_create (dialog=0x7f3b3c3aa958, type=2, params=0x7f3b4ffda0a0) at acc_cdr.c:790
#6 0x00007f3b4fd68398 in run_create_callbacks (dlg=0x7f3b3c3aa958, msg=0x7f3b530498f0) at dlg_cb.c:230
#7 0x00007f3b4fd82590 in dlg_new_dialog (req=0x7f3b530498f0, t=0x7f3b3c7b89a8, run_initial_cbs=1) at dlg_handlers.c:865
#8 0x00007f3b4fd81006 in dlg_onreq (t=0x7f3b3c7b89a8, type=1, param=0x7f3b52df2760) at dlg_handlers.c:717
#9 0x00007f3b52b36c3a in run_reqin_callbacks_internal (hl=0x7f3b3b7eb480, trans=0x7f3b3c7b89a8, params=0x7f3b52df2760) at t_hooks.c:360
#10 0x00007f3b52b36d48 in run_reqin_callbacks (trans=0x7f3b3c7b89a8, req=0x7f3b530498f0, code=1) at t_hooks.c:385
#11 0x00007f3b52af7b58 in build_cell (p_msg=0x7f3b530498f0) at h_table.c:356
#12 0x00007f3b52b48283 in new_t (p_msg=0x7f3b530498f0) at t_lookup.c:1269
#13 0x00007f3b52b494b3 in t_newtran (p_msg=0x7f3b530498f0) at t_lookup.c:1409
#14 0x00007f3b52b1de9c in t_relay_to (p_msg=0x7f3b530498f0, proxy=0x0, proto=0, replicate=0) at t_funcs.c:236
#15 0x00007f3b52b5cbbb in _w_t_relay_to (p_msg=0x7f3b530498f0, proxy=0x0, force_proto=0) at tm.c:1476
#16 0x00007f3b52b5dd20 in w_t_relay (p_msg=0x7f3b530498f0, _foo=0x0, _bar=0x0) at tm.c:1677
#17 0x000000000041ddad in do_action (h=0x7fff7efabc80, a=0x7f3b52efc9b8, msg=0x7f3b530498f0) at action.c:1053
#18 0x000000000042a4c3 in run_actions (h=0x7fff7efabc80, a=0x7f3b52efc9b8, msg=0x7f3b530498f0) at action.c:1548
#19 0x000000000042ab28 in run_actions_safe (h=0x7fff7efac8a0, a=0x7f3b52efc9b8, msg=0x7f3b530498f0) at action.c:1613
#20 0x0000000000543c94 in rval_get_int (h=0x7fff7efac8a0, msg=0x7f3b530498f0, i=0x7fff7efac158, rv=0x7f3b52efd008, cache=0x0) at rvalue.c:912
#21 0x0000000000547ecc in rval_expr_eval_int (h=0x7fff7efac8a0, msg=0x7f3b530498f0, res=0x7fff7efac158, rve=0x7f3b52efd000) at rvalue.c:1906
#22 0x00000000005482c2 in rval_expr_eval_int (h=0x7fff7efac8a0, msg=0x7f3b530498f0, res=0x7fff7efac5e0, rve=0x7f3b52efd700) at rvalue.c:1914
#23 0x000000000041d897 in do_action (h=0x7fff7efac8a0, a=0x7f3b52efccb0, msg=0x7f3b530498f0) at action.c:1029
#24 0x000000000042a4c3 in run_actions (h=0x7fff7efac8a0, a=0x7f3b52e45308, msg=0x7f3b530498f0) at action.c:1548
#25 0x000000000042abf0 in run_top_route (a=0x7f3b52e45308, msg=0x7f3b530498f0, c=0x0) at action.c:1634
#26 0x000000000050a938 in receive_msg (
buf=0xa6fee0 "INVITE sip:09011112222@192.168.2.185:5060 SIP/2.0\r\nVia: SIP/2.0/UDP 192.168.0.186:5010;rport;branch=z9hG4bK-13146-256700-4\r\nFrom: \"user1\" <sip:user1@test1.com>;tag=13146SIPpTag00256700\r\nTo: <sip:09011"..., len=947, rcv_info=0x7fff7efacb90) at receive.c:196
#27 0x000000000060a3ea in udp_rcv_loop () at udp_server.c:495
#28 0x00000000004a7ef7 in main_loop () at main.c:1573
#29 0x00000000004ae2d2 in main (argc=7, argv=0x7fff7efacfc8) at main.c:2533
```
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/301
Module: kamailio
Branch: master
Commit: 74c84c7cd52347fcd1c90e75dca239b5f758169b
URL: https://github.com/kamailio/kamailio/commit/74c84c7cd52347fcd1c90e75dca239b…
Author: Carsten Bock <carsten(a)ng-voice.com>
Committer: Carsten Bock <carsten(a)ng-voice.com>
Date: 2015-08-28T12:11:25+02:00
db_postgres: Fix heap use after free error in db_postgres module
The result structure for a query holds a pointer returned by
PQfname. When sql_do_query executes the query it gets this
database result structure returned but the PQfname pointer
has already been free'd by a call to db_postgres_free_query
from within db_postgres_store_result.
sql_do_query then tries to copy the free'd string into another
result structure resulting in a heap use after free.
The fix here copies the PQfname result.
Fix by Chris Double
---
Modified: modules/db_postgres/km_pg_con.c
Modified: modules/db_postgres/km_res.c
---
Diff: https://github.com/kamailio/kamailio/commit/74c84c7cd52347fcd1c90e75dca239b…
Patch: https://github.com/kamailio/kamailio/commit/74c84c7cd52347fcd1c90e75dca239b…
---
diff --git a/modules/db_postgres/km_pg_con.c b/modules/db_postgres/km_pg_con.c
index ec98add..d053c55 100644
--- a/modules/db_postgres/km_pg_con.c
+++ b/modules/db_postgres/km_pg_con.c
@@ -71,10 +71,6 @@ struct pg_con* db_postgres_new_connection(struct db_id* id)
memset(ptr, 0, sizeof(struct pg_con));
ptr->ref = 1;
- memset(keywords, 0, (sizeof(char*) * 10));
- memset(values, 0, (sizeof(char*) * 10));
- memset(to, 0, (sizeof(char) * 16));
-
if (id->port) {
ports = int2str(id->port, 0);
keywords[i] = "port";
diff --git a/modules/db_postgres/km_res.c b/modules/db_postgres/km_res.c
index e9aa232..912206b 100644
--- a/modules/db_postgres/km_res.c
+++ b/modules/db_postgres/km_res.c
@@ -126,8 +126,14 @@ int db_postgres_get_columns(const db1_con_t* _h, db1_res_t* _r)
RES_NAMES(_r)[col]);
/* The pointer that is here returned is part of the result structure. */
- RES_NAMES(_r)[col]->s = PQfname(CON_RESULT(_h), col);
- RES_NAMES(_r)[col]->len = strlen(PQfname(CON_RESULT(_h), col));
+ RES_NAMES(_r)[col]->s = pkg_malloc(strlen(PQfname(CON_RESULT(_h), col))+1);
+ if (! RES_NAMES(_r)[col]->s) {
+ LM_ERR("no private memory left\n");
+ db_free_columns(_r);
+ return -4;
+ }
+ strcpy(RES_NAMES(_r)[col]->s, PQfname(CON_RESULT(_h), col));
+ RES_NAMES(_r)[col]->len = strlen(RES_NAMES(_r)[col]->s);
LM_DBG("RES_NAMES(%p)[%d]=[%.*s]\n", RES_NAMES(_r)[col], col,
RES_NAMES(_r)[col]->len, RES_NAMES(_r)[col]->s);
Hi Daniel,
I must admit this run_onsend() patch for stateful replies creation was
not quite a success story. However, I think it serves a practical
purpose, for example in Homer tracing and could be useful for the
community. Again, I propose my past solution, with some questions:
1. I am unsure if the place I introduced the run_onsend call is
appropriate since the buf used for msg_send is constructed
build_res_buf_from_sip_req and build_res_buf_from_sip_res calls.
2. Also, we can maybe unite these if call branches I created:
send_res = msg_send(&uas_rb->dst, buf, res_len);
send_res = SEND_PR_BUFFER( uas_rb, buf, res_len );
3. Do you think a get_send_socket snippet as follows should be inserted
before the /*if (onsend_route_enabled(SIP_REPLY)){*/ :
if(dst.send_sock == NULL) {
dst.send_sock=get_send_socket(msg, &dst.to, dst.proto);
if (dst.send_sock==0){
LM_ERR("cannot forward reply\n");
}
}
Thank you,
Lucian
On 10/29/2014 02:15 PM, Daniel-Constantin Mierla wrote:
> Hello Lucian,
>
> I applied your patch with some fixes.
>
> I haven't checked with stateful replies, at some point a function from
> core should be used. You can go ahead and see if it works, if not, let
> me know and I can look into it as well. You can follow the callbacks
> for TMCB_RESPONSE_OUT or TMCB_RESPONSE_FWDED inside tm code, they
> should lead to the place where a sip response is going to be sent out.
>
> Cheers,
> Daniel
>
> On 27/10/14 12:51, Lucian Balaceanu wrote:
>> Hello Daniel,
>>
>> I must admit I only saw your mail last Friday. Until the 10th of
>> October I was also on vacation. I know that you actually committed
>> some of the changes together with your comments on the 12th this month.
>>
>> I don't know if we can consider the topic of the patch closed. As far
>> as I understand, the state-full replies have not been addressed,
>> right? (There should be a change in the t_reply.c) I followed the
>> code to the relay_reply but I did not yet come to find the send
>> function. Should I pursue further?
>>
>> Thank you,
>> Lucian Balaceanu
>>
>>> Hi Lucian,
>>>
>>> somehow I forgot to follow up on this. But we need to get sorted out
>>> soon, before we release, so it works as expected with the new
>>> version. See more comments inline.
>>>
>>>
>>> On 17/09/14 18:09, Lucian Balaceanu wrote:
>>>> Hi Daniel,
>>>>
>>>> Please forgive me for my delay in responding to your mail.
>>>> Please find attached a second version of the onsend_route_reply
>>>> patch (which again has some problems). As per your previous
>>>> indications I did the following:
>>>>
>>>> *Issue1*
>>>>> From performances point of view, there can be added a config
>>>>> parameter to enable running of onsend_route for replies:
>>>>>
>>>>> onsend_route_reply = 0|1
>>>>
>>>> Following
>>>> http://www.asipto.com/pub/kamailio-devel-guide/#c08add_parameters I
>>>> have tried to add onsend_route_reply parameter. The code compiles,
>>>> but when trying to start kamailio with this parameter inside, the
>>>> parsing fails with syntax errors signaling:
>>>>
>>>> / 0(1321) :<core> [cfg.y:3423]: yyerror_at(): parse error in config
>>>> file kamailio-basic.cfg.4.1, from line 107, column 1 to line 108,
>>>> column 0: syntax error
>>>> 0(1321) : <core> [cfg.y:3423]: yyerror_at(): parse error in config
>>>> file kamailio-basic.cfg.4.1, from line 107, column 1 to line 108,
>>>> column 0:
>>>> ERROR: bad config file (2 errors)/
>>>
>>> The issue is:
>>>
>>> +<INITIAL>{ONSEND_RT_REPLY} { yylval.intval=atoi(yytext);
>>> + yy_number_str=yytext; return NUMBER; }
>>>
>>> It should be:
>>>
>>> +<INITIAL>{ONSEND_RT_REPLY} { yylval.intval=atoi(yytext);
>>> + yy_number_str=yytext; return ONSEND_RT_REPLY; }
>>>
>>>>
>>>> *Issue2*
>>>>> #define onsend_enabled(rtype)
>>>>> (onsend_rt.rlist[DEFAULT_RT]?((rtype==SIP_REPLY)?onsend_route_reply:1):0)
>>>> That is to say you see it best to take the chek for
>>>> onsend_rt.list[DEFAULT_RT] from inside run_onsend() function and
>>>> call this onsend_enabled(...) before the run_onsend()?
>>>
>>> This is to detect whether the onsend_route should be executed for
>>> SIP replies. The condition being:
>>>
>>> - if is a sip reply and onsend_route is set and the
>>> onsend_route_reply parameter is 1
>>>>
>>>> *Issue3*
>>>>> On the other hand, is onsend_route also executed for local
>>>>> requests? I had in mind it is only for received requests that are
>>>>> forwarded ... Iirc, on onsend_route, the sip message is the one
>>>>> received, the outgoing content being accessible via $snd(buf).
>>>>>
>>>> I agree with you with taking out the locally generated requests and
>>>> only left the run_onsend call in do_forward_reply function (inside
>>>> forward.c).
>>>> Could you point me to the reply relaying function that is called
>>>> for state-full processing?
>>> Stateful processing for replies is mainly done in t_reply.c from tm
>>> module. At some point there should be a send buffer function call.
>>>
>>> Cheers,
>>> Daniel
>>>>
>>>> Thank you and sorry again for my late answer,
>>>> Lucian
>>>
>>> --
>>> Daniel-Constantin Mierla
>>> http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda
>>>
>>>
>>
>
> --
> Daniel-Constantin Mierla
> http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda