30 Jun
2010
30 Jun
'10
10:17 p.m.
Hi All,
I'm running kamailio 3.0.2.
# ----- permissions params -----
modparam("permissions", "db_url",
"mysql://openserro:openserro@localhost/openser")
#modparam("permissions", "db_mode", 1)
snip in route block:
if (!allow_source_address_group()) {
sl_send_reply("403", "Forbidden");
exit;
}
From command line:
sip-router2:/etc/kamailio# kamctl fifo address_reload
400 Address table reload failed
debug output:
during initial kamailio startup:
0(10655) DEBUG: permissions [address.c:122]: Number of rows in address table: 4
0(10655) DEBUG: permissions [address.c:164]: Tuple <1, 10.10.12.0,
24, 0> inserted into subnet table
0(10655) DEBUG: permissions [address.c:164]: Tuple <1, 10.10.14.0,
24, 0> inserted into subnet table
0(10655) DEBUG: permissions [address.c:148]: Tuple <1, 10.10.15.97,
32> inserted into address hash table
0(10655) DEBUG: permissions [address.c:148]: Tuple <1, 10.10.15.98,
32> inserted into address hash table
0(10655) DEBUG: <core> [db_res.c:81]: freeing 4 columns
0(10655) DEBUG: <core> [db_res.c:85]: freeing RES_NAMES[0] at 0x827c158
0(10655) DEBUG: <core> [db_res.c:85]: freeing RES_NAMES[1] at 0x827c220
0(10655) DEBUG: <core> [db_res.c:85]: freeing RES_NAMES[2] at 0x827c168
0(10655) DEBUG: <core> [db_res.c:85]: freeing RES_NAMES[3] at 0x827c230
0(10655) DEBUG: <core> [db_res.c:94]: freeing result names at 0x827c250
0(10655) DEBUG: <core> [db_res.c:99]: freeing result types at 0x827c1b8
0(10655) DEBUG: <core> [db_res.c:54]: freeing 4 rows
0(10655) DEBUG: <core> [db_row.c:97]: freeing row values at 0x827c710
0(10655) DEBUG: <core> [db_row.c:97]: freeing row values at 0x827c6b8
0(10655) DEBUG: <core> [db_row.c:97]: freeing row values at 0x827c660
0(10655) DEBUG: <core> [db_row.c:97]: freeing row values at 0x827c598
0(10655) DEBUG: <core> [db_res.c:62]: freeing rows at 0x827ca10
0(10655) DEBUG: <core> [db_res.c:136]: freeing result set at 0x827c1f8
0(10655) DEBUG: <core> [db_pool.c:102]: removing connection from the pool
0(10655) DEBUG: permissions [address.c:181]: address table reloaded
successfully.
result when issuing "kamctl fifo address_reload"
3(10389) DEBUG: mi_fifo [fifo_fnc.c:489]: entered consume
3(10389) DEBUG: mi_fifo [fifo_fnc.c:489]: **** done consume
3(10389) DEBUG: mi_fifo [fifo_fnc.c:503]: done parsing the mi tree
3(10389) ERROR: permissions [address.c:82]: db_handle already exists
The address table loads fine during startup and if I reload kamailio
it will load any new addresses or subnets so I know there is no syntax
error in the database.
I can reload trusted table and pdt table without an error but address
table is not working.
Any ideas on how I can trouble shoot this further?
Thanks.
JR
--
JR Richardson
Engineering for the Masses
30 Jun
30 Jun
11:51 p.m.
Hello,
On 6/30/10 10:17 PM, JR Richardson wrote:
Hi All,
I'm running kamailio 3.0.2.
hmm, checking the logs I see changes done lately that introduced some bugs:
http://git.sip-router.org/cgi-bin/gitweb.cgi?p=sip-router;a=commitdiff;h=b0…
I could spot at least:
- db handle is initialed by mi child init and then checked to be null
(the cause of error message printed)
- in some error cases, db handle is left initialized, so next times
the command won't work
I will try to fix in the next days, meanwhile you can apply revert patch
and everything should work ... the attempt by that commit is not really
solving the problem it tried to fix.
Cheers,
Daniel
# ----- permissions params -----
modparam("permissions", "db_url",
"mysql://openserro:openserro@localhost/openser")
#modparam("permissions", "db_mode", 1)
snip in route block:
if (!allow_source_address_group()) {
sl_send_reply("403", "Forbidden");
exit;
}
From command line:
sip-router2:/etc/kamailio# kamctl fifo address_reload
400 Address table reload failed
debug output:
during initial kamailio startup:
0(10655) DEBUG: permissions [address.c:122]: Number of rows in address table: 4
0(10655) DEBUG: permissions [address.c:164]: Tuple<1, 10.10.12.0,
24, 0> inserted into subnet table
0(10655) DEBUG: permissions [address.c:164]: Tuple<1, 10.10.14.0,
24, 0> inserted into subnet table
0(10655) DEBUG: permissions [address.c:148]: Tuple<1, 10.10.15.97,
32> inserted into address hash table
0(10655) DEBUG: permissions [address.c:148]: Tuple<1, 10.10.15.98,
32> inserted into address hash table
0(10655) DEBUG:<core> [db_res.c:81]: freeing 4 columns
0(10655) DEBUG:<core> [db_res.c:85]: freeing RES_NAMES[0] at 0x827c158
0(10655) DEBUG:<core> [db_res.c:85]: freeing RES_NAMES[1] at 0x827c220
0(10655) DEBUG:<core> [db_res.c:85]: freeing RES_NAMES[2] at 0x827c168
0(10655) DEBUG:<core> [db_res.c:85]: freeing RES_NAMES[3] at 0x827c230
0(10655) DEBUG:<core> [db_res.c:94]: freeing result names at 0x827c250
0(10655) DEBUG:<core> [db_res.c:99]: freeing result types at 0x827c1b8
0(10655) DEBUG:<core> [db_res.c:54]: freeing 4 rows
0(10655) DEBUG:<core> [db_row.c:97]: freeing row values at 0x827c710
0(10655) DEBUG:<core> [db_row.c:97]: freeing row values at 0x827c6b8
0(10655) DEBUG:<core> [db_row.c:97]: freeing row values at 0x827c660
0(10655) DEBUG:<core> [db_row.c:97]: freeing row values at 0x827c598
0(10655) DEBUG:<core> [db_res.c:62]: freeing rows at 0x827ca10
0(10655) DEBUG:<core> [db_res.c:136]: freeing result set at 0x827c1f8
0(10655) DEBUG:<core> [db_pool.c:102]: removing connection from the pool
0(10655) DEBUG: permissions [address.c:181]: address table reloaded
successfully.
result when issuing "kamctl fifo address_reload"
3(10389) DEBUG: mi_fifo [fifo_fnc.c:489]: entered consume
3(10389) DEBUG: mi_fifo [fifo_fnc.c:489]: **** done consume
3(10389) DEBUG: mi_fifo [fifo_fnc.c:503]: done parsing the mi tree
3(10389) ERROR: permissions [address.c:82]: db_handle already exists
The address table loads fine during startup and if I reload kamailio
it will load any new addresses or subnets so I know there is no syntax
error in the database.
I can reload trusted table and pdt table without an error but address
table is not working.
Any ideas on how I can trouble shoot this further?
Thanks.
JR
--
Daniel-Constantin Mierla
http://www.asipto.com/
1 Jul
1 Jul
12:28 a.m.
On Wed, Jun 30, 2010 at 4:51 PM, Daniel-Constantin Mierla
<miconda(a)gmail.com> wrote:
Hello,
On 6/30/10 10:17 PM, JR Richardson wrote:
Hi Daniel,
Well, you sure are a smart fella. I reverted the patch and reloading
the address table works as expected now. For clarification I was
testing with kamailio-3.0.2_src_2010-06-30_a6141a.tar.gz snapshot.
Let me know when you have the updated fix and I'll do sime testing.
Thanks.
JR
--
JR Richardson
Engineering for the Masses
Hi All,
I'm running kamailio 3.0.2.
hmm, checking the logs I see changes done lately that introduced some bugs:
http://git.sip-router.org/cgi-bin/gitweb.cgi?p=sip-router;a=commitdiff;h=b0…
I could spot at least:
- db handle is initialed by mi child init and then checked to be null (the
cause of error message printed)
- in some error cases, db handle is left initialized, so next times the
command won't work
I will try to fix in the next days, meanwhile you can apply revert patch and
everything should work ... the attempt by that commit is not really solving
the problem it tried to fix.
Cheers,
Daniel
8:28 a.m.
JR Richardson writes:
Well, you sure are a smart fella. I reverted the
patch and reloading
the address table works as expected now. For clarification I was
testing with kamailio-3.0.2_src_2010-06-30_a6141a.tar.gz snapshot.
Let me know when you have the updated fix and I'll do sime testing.
there was an address table reload bug that i tried to fix with the patch:
modules_k/permissions: fixed reloading of address table
- Database handle was not initialized when address table was reloaded.
Now it is initialized/closed at each reload. Looks like this has
never been tested before. Still don't know why mi_addr_child_init()
exists and what it is supposed to do.
reverting the patch thus most likely reintroduced this other bug.
perhaps the bug that you saw has something to do with the last sentence
of the commit.
-- juha
3:04 p.m.
-----Original Message-----
From: Juha Heinanen [mailto:jh@tutpro.com]
Sent: Thursday, July 01, 2010 1:43 AM
To: JR Richardson; SR-Users
Subject: Re: [SR-Users] permissions module address_reload not working
Juha Heinanen writes:
Yes, I tried both db_mode=1 and db_mode=0 with the same results, but that
parameter only affects the trusted table, which was reloading just fine.
JR
reverting the patch thus most likely reintroduced
this other bug.
perhaps the bug that you saw has something to do with the last sentence
of the commit.
jr,
did you try with db_mode=1? it works ok here.
-- juha
10:27 a.m.
Hello Juha,
On 7/1/10 8:28 AM, Juha Heinanen wrote:
JR Richardson writes:
I guess you use this command via rpc interface, not via mi. Looking at
the code, the mi init child is not done for rpc processes, resulting in
some mi commands not working properly when called over rpc. The fix
should be calling mi init child functions in mi_rpc module -- working on
it today.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com/
Well, you sure are a smart fella. I reverted the
patch and reloading
the address table works as expected now. For clarification I was
testing with kamailio-3.0.2_src_2010-06-30_a6141a.tar.gz snapshot.
Let me know when you have the updated fix and I'll do sime testing.
there was an address table reload bug that i tried to fix with the patch:
modules_k/permissions: fixed reloading of address table
- Database handle was not initialized when address table was reloaded.
Now it is initialized/closed at each reload. Looks like this has
never been tested before. Still don't know why mi_addr_child_init()
exists and what it is supposed to do.
reverting the patch thus most likely reintroduced this other bug.
perhaps the bug that you saw has something to do with the last sentence
of the commit.
10:44 a.m.
Daniel-Constantin Mierla writes:
I guess you use this command via rpc interface, not
via mi.
yes, i use 'ctl mi address_reload', noticed that it didn't work and then
went and fixed it.
Looking at
the code, the mi init child is not done for rpc processes, resulting in
some mi commands not working properly when called over rpc. The fix
should be calling mi init child functions in mi_rpc module -- working on
it today.
ok thanks, juha
12:28 p.m.
On 7/1/10 10:44 AM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
Juha, I just committed on master and tested over MI where works fine.
Can you do some tests over rpc? If all ok then can be backported.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com/
I guess you use this command via rpc interface,
not via mi.
yes, i use 'ctl mi address_reload', noticed that it didn't work
and then
went and fixed it.
> Looking at
> the code, the mi init child is not done for rpc processes, resulting in
> some mi commands not working properly when called over rpc. The fix
> should be calling mi init child functions in mi_rpc module -- working on
> it today.
>
12:38 p.m.
Daniel-Constantin Mierla writes:
Juha, I just committed on master and tested over MI
where works fine.
Can you do some tests over rpc? If all ok then can be backported.
it would be nice if i could, but after trying to cherry-pick my msilo
commit to sr_3.0, i got errors about debian-lenny files and after that
my repo has been unusable:
jh@rautu:/usr/src/orig/sip-router$ eg switch master
pkg/kamailio/debian-lenny/compat: needs merge
pkg/kamailio/debian-lenny/control: needs merge
pkg/kamailio/debian-lenny/copyright: needs merge
pkg/kamailio/debian-lenny/kamailio.README.Debian: needs merge
pkg/kamailio/debian-lenny/kamailio.default: needs merge
pkg/kamailio/debian-lenny/kamailio.dirs: needs merge
pkg/kamailio/debian-lenny/kamailio.examples: needs merge
pkg/kamailio/debian-lenny/kamailio.init: needs merge
pkg/kamailio/debian-lenny/kamailio.postinst: needs merge
error: you need to resolve your current index first
this debian-lenny thing has been haunting me and it would be nice to get
if somehow fixed. we cannot live with git repo that is broken.
-- juha
2 Jul
2 Jul
11:21 a.m.
On Jul 01, 2010 at 13:38, Juha Heinanen <jh(a)tutpro.com> wrote:
Daniel-Constantin Mierla writes:
The git repo is not broken, it the debian-lenny change just generates a
conflict which it does not know how to solve automatically, and it must
be solved by hand.
I'll try to cherry-pick the debian-lenny change into sr_3.0 too, but
until then you can always run:
git reset pkg/kamailio/debian-lenny
when you get this conflict during cherry pick, and then
git commit -c id_of_cherry_picked_commit.
Andrei
Juha, I just committed on master and tested over
MI where works fine.
Can you do some tests over rpc? If all ok then can be backported.
it would be nice if i could, but after trying to cherry-pick my msilo
commit to sr_3.0, i got errors about debian-lenny files and after that
my repo has been unusable:
jh@rautu:/usr/src/orig/sip-router$ eg switch master
pkg/kamailio/debian-lenny/compat: needs merge
pkg/kamailio/debian-lenny/control: needs merge
pkg/kamailio/debian-lenny/copyright: needs merge
pkg/kamailio/debian-lenny/kamailio.README.Debian: needs merge
pkg/kamailio/debian-lenny/kamailio.default: needs merge
pkg/kamailio/debian-lenny/kamailio.dirs: needs merge
pkg/kamailio/debian-lenny/kamailio.examples: needs merge
pkg/kamailio/debian-lenny/kamailio.init: needs merge
pkg/kamailio/debian-lenny/kamailio.postinst: needs merge
error: you need to resolve your current index first
this debian-lenny thing has been haunting me and it would be nice to get
if somehow fixed. we cannot live with git repo that is broken.
1 Jul
1 Jul
1:18 p.m.
Daniel-Constantin Mierla writes:
Juha, I just committed on master and tested over MI
where works fine.
Can you do some tests over rpc? If all ok then can be backported.
daniel,
i deleted whole sr git repo and downloaded a new one. after that i did
address_reload tests. it works from command line:
# sip-proxy_ctl mi address_reload
#
but not via xmlrpc:
Jul 1 14:12:29 localhost /usr/sbin/sip-proxy[11821]: INFO: Handling XMLRPC POST from
<127.0.0.1> with body <<?xml version="1.0"
?><methodCall><methodName>mi</methodName><params><param><value><string>address_reload</string></value></param></params></methodCall>>
Jul 1 14:12:29 localhost /usr/sbin/sip-proxy[11821]: ERROR: <core> [db.c:421]:
invalid parameter value
Jul 1 14:12:29 localhost /usr/sbin/sip-proxy[11821]: ERROR: permissions [address.c:84]:
failed to use table
-- juha
2:42 p.m.
On 7/1/10 1:18 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
this is another issue ... the mi commands were designed to be run from
special processes, created by mi transport modules (mi_fifo,
mi_datagram, etc). There are special init functions called for these
processes. However, with 3.0 xmlrpc module can call these functions but
the module re-uses SIP tcp processes, meaning that what is called in mi
init child function should be called in child init functions.
There are two options:
- call all mi child init functions in mi_rpc child_init even for SIP
worker process - in the previous commit I added execution only for
PROC_RPC. But then each module exporting mi commands has to be reviewed
to see if there is no overlapping (usually is about opening db
connection, thus make sure it is not opened twice in same process)
- execute per module mi init fuction specific for that module. This will
ensure that mi command become available to xmlrpc module gradually but
safe. It has a drawback of initializing MI specific stuff for each
process even when mi_rpc is not loaded, thus such things are not needed
at runtime
Both options requires check over the mi cmd modules. Right now I think
option 1 is better, because it does not initialize db connections when
not needed, other opinions?
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com/
Juha, I just committed on master and tested over
MI where works fine.
Can you do some tests over rpc? If all ok then can be backported.
daniel,
i deleted whole sr git repo and downloaded a new one. after that i did
address_reload tests. it works from command line:
# sip-proxy_ctl mi address_reload
#
but not via xmlrpc:
Jul 1 14:12:29 localhost /usr/sbin/sip-proxy[11821]: INFO: Handling XMLRPC POST
from<127.0.0.1> with body<<?xml version="1.0"
?><methodCall><methodName>mi</methodName><params><param><value><string>address_reload</string></value></param></params></methodCall>>
Jul 1 14:12:29 localhost /usr/sbin/sip-proxy[11821]: ERROR:<core> [db.c:421]:
invalid parameter value
Jul 1 14:12:29 localhost /usr/sbin/sip-proxy[11821]: ERROR: permissions [address.c:84]:
failed to use table
4:39 p.m.
Daniel-Constantin Mierla writes:
this is another issue ... the mi commands were
designed to be run from
special processes, created by mi transport modules (mi_fifo,
mi_datagram, etc). There are special init functions called for these
processes. However, with 3.0 xmlrpc module can call these functions but
the module re-uses SIP tcp processes, meaning that what is called in mi
init child function should be called in child init functions.
mi trusted_reload from the same module works fine using both crt and
xmlrpc:
# sip-proxy_ctl mi trusted_reload
#
Jul 1 17:35:35 localhost /usr/sbin/sip-proxy[11824]: INFO: Handling XMLRPC POST from
<127.0.0.1> with body <<?xml version="1.0"
?><methodCall><methodName>mi</methodName><params><param><value><string>trusted_reload</string></value></param></params></methodCall>>
so may the same kind of implementation could be used also for
address_realod.
- call all mi child init functions in mi_rpc
child_init even for SIP
worker process - in the previous commit I added execution only for
PROC_RPC. But then each module exporting mi commands has to be reviewed
to see if there is no overlapping (usually is about opening db
connection, thus make sure it is not opened twice in same process)
- execute per module mi init fuction specific for that module. This will
ensure that mi command become available to xmlrpc module gradually but
safe. It has a drawback of initializing MI specific stuff for each
process even when mi_rpc is not loaded, thus such things are not needed
at runtime
Both options requires check over the mi cmd modules. Right now I think
option 1 is better, because it does not initialize db connections when
not needed, other opinions?
another opinion is: replace permissions module mi commands with rpc
ones.
-- juha
5:54 p.m.
On 7/1/10 4:39 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
yes, checking the sources I see trusted and address operations use
different db handlers. The one for trusted is initialized from
child_init, while the other one is not. Probably because the trusted can
work in non-cache mode and need the connection for sip worker.
this is another issue ... the mi commands were
designed to be run from
special processes, created by mi transport modules (mi_fifo,
mi_datagram, etc). There are special init functions called for these
processes. However, with 3.0 xmlrpc module can call these functions but
the module re-uses SIP tcp processes, meaning that what is called in mi
init child function should be called in child init functions.
mi trusted_reload from the same module works fine using both crt and
xmlrpc:
# sip-proxy_ctl mi trusted_reload
#
Jul 1 17:35:35 localhost /usr/sbin/sip-proxy[11824]: INFO: Handling XMLRPC POST
from<127.0.0.1> with body<<?xml version="1.0"
?><methodCall><methodName>mi</methodName><params><param><value><string>trusted_reload</string></value></param></params></methodCall>>
so may the same kind of implementation could be used also for
address_realod.
it is an option, somehow in the global to-do list to replace mi with
rpc. Right now, this issue is not only for permissions module, is also
affecting other mi cmds which are going to be used over xmlrpc module --
using mi commands via rpc interface with sercmd is different and there
is no issue with that.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com/
- call all mi child init functions in mi_rpc
child_init even for SIP
worker process - in the previous commit I added execution only for
PROC_RPC. But then each module exporting mi commands has to be reviewed
to see if there is no overlapping (usually is about opening db
connection, thus make sure it is not opened twice in same process)
- execute per module mi init fuction specific for that module. This will
ensure that mi command become available to xmlrpc module gradually but
safe. It has a drawback of initializing MI specific stuff for each
process even when mi_rpc is not loaded, thus such things are not needed
at runtime
Both options requires check over the mi cmd modules. Right now I think
option 1 is better, because it does not initialize db connections when
not needed, other opinions?
another opinion is: replace permissions module mi commands with rpc
ones.
7:28 p.m.
On 7/1/10 5:54 PM, Daniel-Constantin Mierla wrote:
On 7/1/10 4:39 PM, Juha Heinanen wrote:
I just committed initialization of mi commands in sip worker processes
by mi_rpc module when xmlrpc module is loaded.
The other modules exporting mi commands were updated to avoid
re-initialization. In most of the cases was about opening db connection,
which was harmless anyhow, another connection handler was requested and
since there is a pool of connections per process, the previous one would
have been returned. However, if something else needs to be initialized,
it is now an indication that the developer should take care when doing
mi process init, which should not happen anymore as RPC control
interface is to be used for new development.
No time to do real tests, if you can run some and report back, it would
be great. Once some testing is done, can be ported to 3.0.
Thanks,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com/
Daniel-Constantin Mierla writes:
yes, checking the sources I see trusted and address operations use
different db handlers. The one for trusted is initialized from
child_init, while the other one is not. Probably because the trusted
can work in non-cache mode and need the connection for sip worker.
this is another issue ... the mi commands were
designed to be run from
special processes, created by mi transport modules (mi_fifo,
mi_datagram, etc). There are special init functions called for these
processes. However, with 3.0 xmlrpc module can call these functions but
the module re-uses SIP tcp processes, meaning that what is called in mi
init child function should be called in child init functions.
mi trusted_reload
from the same module works fine using both crt and
xmlrpc: # sip-proxy_ctl mi trusted_reload
#
Jul 1 17:35:35 localhost /usr/sbin/sip-proxy[11824]: INFO: Handling
XMLRPC POST from<127.0.0.1> with body<<?xml version="1.0"
?><methodCall><methodName>mi</methodName><params><param><value><string>trusted_reload</string></value></param></params></methodCall>>
so may the same kind of implementation could be used also for
address_realod.
it is an option, somehow in the global to-do list to replace mi with
rpc. Right now, this issue is not only for permissions module, is also
affecting other mi cmds which are going to be used over xmlrpc module
-- using mi commands via rpc interface with sercmd is different and
there is no issue with that. - call all mi child init functions in mi_rpc
child_init even for SIP
worker process - in the previous commit I added execution only for
PROC_RPC. But then each module exporting mi commands has to be reviewed
to see if there is no overlapping (usually is about opening db
connection, thus make sure it is not opened twice in same process)
- execute per module mi init fuction specific for that module. This
will
ensure that mi command become available to xmlrpc module gradually but
safe. It has a drawback of initializing MI specific stuff for each
process even when mi_rpc is not loaded, thus such things are not needed
at runtime
Both options requires check over the mi cmd modules. Right now I think
option 1 is better, because it does not initialize db connections when
not needed, other opinions?
another opinion is: replace permissions module mi
commands with rpc
ones.
8:08 p.m.
Daniel-Constantin Mierla writes:
No time to do real tests, if you can run some and
report back, it would
be great. Once some testing is done, can be ported to 3.0.
daniel,
i tested address_reload, trusted_reload, and sht_reload mi commands over
xmlrpc and they all worked fine. also 'ctl mi address_reload' worked ok.
-- juha
5050
days inactive
5052
days old
16 comments
4 participants
participants (4)
-
Andrei Pelinescu-Onciul -
Daniel-Constantin Mierla -
JR Richardson -
Juha Heinanen