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
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
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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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
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:
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
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
-
Antanas Masevicius -
Antanas Masevicius -
Juha Heinanen