24 Jul
2012
24 Jul
'12
3:49 a.m.
Hello,
having trouble running LCR in kamailio 3.3 (head).
Here is my DB excerpt which i use to reproduce the problem:
INSERT INTO `lcr_rule` VALUES (2617960,90,'118','.*',1,1,'.*');
INSERT INTO `lcr_rule_target` VALUES (7771454,90,2617960,1424,0,100);
INSERT INTO `lcr_gw` VALUES
(1424,90,'OP1','10.10.10.10','',5060,NULL,1,0,NULL,'11#',1,NULL,NULL);
I stripped all other LCR data from my DB and only this rule with
from_uri and request_uri seems to bother me.
Tried this version on debian lenny and debian squeeze. On Lenny i am not
able to load lcr tables at all, get a segfault.
On squeeze, lcr tables loads up, but this rule gets marked as disabled.
Here is config part which i use to load a rule:
if (load_gws(90, $rU, $fu)) {
if (next_gw()) {
t_on_failure("FAIL_GW");
} else {
route(NO_ROUTE);
}
On squeeze, if i add following code to lcr_mod.c:1249 :
LM_INFO("LOADING lcr rule <%u> \n", rule_id);
right after:
rule_id = (unsigned int)VAL_INT(ROW_VALUES(row));
rule_id is still printed, but i get segfault like this:
Jul 24 10:17:43 sp1 kernel: [23482626.105865] kamailio[15136]: segfault
at a4 ip 00007fde15cb8802 sp 00007fff39d68320 error 4 in
lcr.so[7fde15ca8000+23000]
Not sure what i do terribly wrong. Setting from_uri and request_uri to
anythig but NULL makes the code to segfault with that print line added.
Without print line, kamailio starts, but never loads that rule.
Any help would be appreciated.
best regards,
Antanas Masevicius
NTT
26 Jul
26 Jul
5:12 a.m.
Antanas Masevicius writes:
Here is my DB excerpt which i use to reproduce the
problem:
INSERT INTO `lcr_rule` VALUES (2617960,90,'118','.*',1,1,'.*');
INSERT INTO `lcr_rule_target` VALUES (7771454,90,2617960,1424,0,100);
INSERT INTO `lcr_gw` VALUES
(1424,90,'OP1','10.10.10.10','',5060,NULL,1,0,NULL,'11#',1,NULL,NULL);
when i try the above, last insert gives:
INSERT INTO `lcr_gw` VALUES
->
(1424,90,'OP1','10.10.10.10','',5060,NULL,1,0,NULL,'11#',1,NULL,NULL);
ERROR 1048 (23000): Column 'flags' cannot be null
looks like you have made some mistake in above, because according to the
schema, flags column cannot be null.
-- juha
4:03 p.m.
Hello Juha,
it looks like column order a bit changed in my system after using alter table during
migrations.
That is prefix col is not it its place. Thus this data:
(1424,90,'OP1','10.10.10.10','',5060,NULL,1,0,NULL,'11#',1,NULL,NULL);
should be fixed as:
(1424,90,'OP1','10.10.10.10','',5060,NULL,1,0,NULL,NULL,'11#',1,NULL);
Antanas
NTT
On 2012.07.26 12:12, Juha Heinanen wrote:
Antanas Masevicius writes:
Here is my DB excerpt which i use to reproduce
the problem:
INSERT INTO `lcr_rule` VALUES (2617960,90,'118','.*',1,1,'.*');
INSERT INTO `lcr_rule_target` VALUES (7771454,90,2617960,1424,0,100);
INSERT INTO `lcr_gw` VALUES
(1424,90,'OP1','10.10.10.10','',5060,NULL,1,0,NULL,'11#',1,NULL,NULL);
when i try the above, last insert gives:
INSERT INTO `lcr_gw` VALUES
->
(1424,90,'OP1','10.10.10.10','',5060,NULL,1,0,NULL,'11#',1,NULL,NULL);
ERROR 1048 (23000): Column 'flags' cannot be null
looks like you have made some mistake in above, because according to the
schema, flags column cannot be null.
-- juha
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
27 Jul
27 Jul
5:41 a.m.
Antanas Masevicius writes:
it looks like column order a bit changed in my system
after using alter table during migrations.
That is prefix col is not it its place. Thus this data:
(1424,90,'OP1','10.10.10.10','',5060,NULL,1,0,NULL,'11#',1,NULL,NULL);
should be fixed as:
(1424,90,'OP1','10.10.10.10','',5060,NULL,1,0,NULL,NULL,'11#',1,NULL);
antanas,
i tried with your lcr data and calling 118 worked fine. by changing
load_gw function syslog log messages to INFOs, i got:
Jul 27 12:18:56 siika /usr/sbin/sip-proxy[7260]: INFO: lcr [lcr_mod.c:1855]: load_gws(90,
118, sip:+35832345670@test.fi)
Jul 27 12:18:56 siika /usr/sbin/sip-proxy[7260]: INFO: lcr [lcr_mod.c:1929]: added
matched_gws[0]=[1, 3, 0, 545355600]
and then my proxy tried to send the request to the given ip address.
check that your lcr_count param value is at least 90. name of the param is
misleading. it should be called max_lcr_id.
-- juha
6:37 a.m.
Hello Juha,
i have my lcr_count set as modparam("lcr", "lcr_count", 102).
This is really messy then. Is there something else which could help to
understand the cause of this?
I see you use sip-proxy as flavorful, maybe there something is a bit
different?
Antanas
On 2012.07.27 12:41, Juha Heinanen wrote:
Antanas Masevicius writes:
--
Antanas Masevičius
Technikos direktorius
UAB "Nacionalinis telekomunikaciju tinklas"
Tel. +370 5 2056000
Tel. +370 700 00031 (tiesioginis)
Fax. +370 700 00034
el.p: antanas.masevicius(a)ntt.lt
www.ntt.lt
www.spykas.com
it looks like column order a bit changed in my
system after using alter table during migrations.
That is prefix col is not it its place. Thus this data:
(1424,90,'OP1','10.10.10.10','',5060,NULL,1,0,NULL,'11#',1,NULL,NULL);
should be fixed as:
(1424,90,'OP1','10.10.10.10','',5060,NULL,1,0,NULL,NULL,'11#',1,NULL);
antanas,
i tried with your lcr data and calling 118 worked fine. by changing
load_gw function syslog log messages to INFOs, i got:
Jul 27 12:18:56 siika /usr/sbin/sip-proxy[7260]: INFO: lcr [lcr_mod.c:1855]: load_gws(90,
118, sip:+35832345670@test.fi)
Jul 27 12:18:56 siika /usr/sbin/sip-proxy[7260]: INFO: lcr [lcr_mod.c:1929]: added
matched_gws[0]=[1, 3, 0, 545355600]
and then my proxy tried to send the request to the given ip address.
check that your lcr_count param value is at least 90. name of the param is
misleading. it should be called max_lcr_id.
-- juha
6:44 a.m.
Antanas Masevicius writes:
i have my lcr_count set as modparam("lcr",
"lcr_count", 102).
This is really messy then. Is there something else which could help to
understand the cause of this?
i did my tests on amd64 architecture, but it should not matter because
all ints in your data fit into unsigned ints also on 32 bit architecture.
-- juha
4550
days inactive
4553
days old
5 comments
3 participants
participants (3)
-
Antanas Masevicius -
Antanas Masevicius -
Juha Heinanen