Hi all,
I'm using openser 1.3.3. And I found an issue between asterisk and openser.
When an asterisk register himself to openser this is my opeserctl ul show:
Contact:: sip:s@172.25.18.168 Q= Expires:: 116 Callid:: 76e873601b776e8a430237091a76a483@172.25.18.168 Cseq:: 103 User-agent:: Asterisk PBX 1.4 Test State:: CS_DIRTY Flags:: 0 Cflag:: 0 Socket:: udp:172.25.18.163:5060 Methods:: 4294967295
In to the postgres database into location table I have
2;"50001";"ttnnet.it";"sip:s@172.25.18.168";"";"";"2008-11-13 10:56:24";-1;"76e873601b776e8a430237091a76a483@172.25.18.168";108;"2008-11-13 10:54:24";0;0;"Asterisk PBX 1.4 Test";"udp:172.25.18.163:5060";
As you can see the methods field into the database is null!
This causes an issue when you restart openser, the asterisk pbx is unreachable until the next registration because the lookup function doesn't match the methods field.
The number 4294967295 is the max int (without sign), maybe there is a issue in the function that calculate this value and post the query.
Any clue?
Kind regards Matteo
On Thursday 13 November 2008, Matteo Piazza wrote:
I'm using openser 1.3.3. And I found an issue between asterisk and openser.
When an asterisk register himself to openser this is my opeserctl ul show: Contact:: sip:s@172.25.18.168 Q= [..] Methods:: 4294967295
In to the postgres database into location table I have
2;"50001";"ttnnet.it";"sip:s@172.25.18.168";"";"";"2008-11-13 10:56:24";-1;"76e873601b776e8a430237091a76a483@172.25.18.168";108;"2008-11- 13 10:54:24";0;0;"Asterisk PBX 1.4 Test";"udp:172.25.18.163:5060";
As you can see the methods field into the database is null!
This causes an issue when you restart openser, the asterisk pbx is unreachable until the next registration because the lookup function doesn't match the methods field.
The number 4294967295 is the max int (without sign), maybe there is a issue in the function that calculate this value and post the query.
Hi Matteo,
the value of 4294967295 is the default, when no allow header is set. This is represented in the DB as NULL. So this is probably not the source of your problem. What db_mode do you use? Normally openser should reload the contacts during startup.
Cheers,
Henning
Hello,
The issue is when I restart openser, it reads the data into the database and this is the result of the openserctl ul show:
Contact:: sip:s@172.25.18.168 Q= Expires:: 20 Callid:: 1bcc8b3150934e9d49cc88254ec31d44@172.25.18.168 Cseq:: 489 User-agent:: Asterisk PBX 1.4 Test State:: CS_SYNC Flags:: 0 Cflag:: 0 Socket:: udp:172.25.18.163:5060 Methods:: 0
As you can see the Methods is 0 and not 4294967295. So when I do a lookup(location) the function return as $retcode -2
When the asterisk register himself the methods come back to 4294967295.
This my cfg for the db_mode
# ----- usrloc params ----- modparam("usrloc", "db_mode", 2) modparam("usrloc", "db_url", "postgres://openser:openserrw@localhost/openser")
This happened if I use like client asterisk, if I use x-lite, for example, I didn't notice this problem.
Until now the solution is keep the registration time very low.
Regards Matteo
Il giorno gio, 13/11/2008 alle 14.21 +0100, Henning Westerholt ha scritto:
On Thursday 13 November 2008, Matteo Piazza wrote:
I'm using openser 1.3.3. And I found an issue between asterisk and openser.
When an asterisk register himself to openser this is my opeserctl ul show: Contact:: sip:s@172.25.18.168 Q= [..] Methods:: 4294967295
In to the postgres database into location table I have
2;"50001";"ttnnet.it";"sip:s@172.25.18.168";"";"";"2008-11-13 10:56:24";-1;"76e873601b776e8a430237091a76a483@172.25.18.168";108;"2008-11- 13 10:54:24";0;0;"Asterisk PBX 1.4 Test";"udp:172.25.18.163:5060";
As you can see the methods field into the database is null!
This causes an issue when you restart openser, the asterisk pbx is unreachable until the next registration because the lookup function doesn't match the methods field.
The number 4294967295 is the max int (without sign), maybe there is a issue in the function that calculate this value and post the query.
Hi Matteo,
the value of 4294967295 is the default, when no allow header is set. This is represented in the DB as NULL. So this is probably not the source of your problem. What db_mode do you use? Normally openser should reload the contacts during startup.
Cheers,
Henning
On Thursday 13 November 2008, Matteo Piazza wrote:
The issue is when I restart openser, it reads the data into the database and this is the result of the openserctl ul show:
Contact:: sip:s@172.25.18.168 Q= [..] Methods:: 0
As you can see the Methods is 0 and not 4294967295. So when I do a lookup(location) the function return as $retcode -2
When the asterisk register himself the methods come back to 4294967295.
Hi Matteo,
ok, now i understand the problem. It seems that this is not correctly restored during the loading after the restart. I did a few tests with the postgres driver, it behaves a little bit different then the mysql one in this case.
This my cfg for the db_mode
# ----- usrloc params ----- modparam("usrloc", "db_mode", 2) modparam("usrloc", "db_url", "postgres://openser:openserrw@localhost/openser")
This happened if I use like client asterisk, if I use x-lite, for example, I didn't notice this problem.
Until now the solution is keep the registration time very low.
I'll investigate a little bit more, this looks like a bug.
Cheers,
Henning
On Thursday 13 November 2008, Henning Westerholt wrote:
On Thursday 13 November 2008, Matteo Piazza wrote:
The issue is when I restart openser, it reads the data into the database and this is the result of the openserctl ul show:
Contact:: sip:s@172.25.18.168 Q= [..] Methods:: 0
As you can see the Methods is 0 and not 4294967295. So when I do a lookup(location) the function return as $retcode -2
When the asterisk register himself the methods come back to 4294967295.
Hi Matteo,
ok, now i understand the problem. It seems that this is not correctly restored during the loading after the restart. I did a few tests with the postgres driver, it behaves a little bit different then the mysql one in this case.
Hi Matteo,
i think i found the problem: the postgres module does not correctly evaluate the NULL values, so the usrloc module assumed incorrectly that its a '0' value, and not the ALL_METHOD flag. I already commited a fix to the trunk.
I've attached a small patch against the 1.3 branch, would be great if you could test this on your installation. If this fixes the problem, i'll do the backport to the 1.3 and 1.4 branch.
Cheers,
Henning
Hi Henning,
I have an error during the compilation of the module. See the text below. As attachment the two files after the application of the pacth
Regards Matteo
openser-1.3.3-tls# make prefix=/ modules=modules/postgres make[1]: Entering directory `/usr/local/src/openser-1.3.3-tls/modules/postgres' make[1]: Leaving directory `/usr/local/src/openser-1.3.3-tls/modules/postgres' make[1]: Entering directory `/usr/local/src/openser-1.3.3-tls/modules/postgres' Compiling db_res.c gcc -fPIC -DPIC -g -O9 -funroll-loops -Wcast-align -Wall -minline-all-stringops -falign-loops -ftree-vectorize -mtune=prescott -Wold-style-definition -Wmissing-field-initializers -DMOD_NAME='"postgres"' -DNAME='"openser"' -DVERSION='"1.3.3-notls"' -DARCH='"i386"' -DOS='"linux"' -DCOMPILER='"gcc 4.1.2"' -D__CPU_i386 -D__OS_linux -D__SMP_yes -DCFG_DIR='"//etc/openser/"' -DPKG_MALLOC -DSHM_MEM -DSHM_MMAP -DUSE_IPV6 -DUSE_MCAST -DUSE_TCP -DDISABLE_NAGLE -DHAVE_RESOLV_RES -DSTATISTICS -DCHANGEABLE_DEBUG_LEVEL -DF_MALLOC -DFAST_LOCK -DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=1024 -DHAVE_GETHOSTBYNAME2 -DHAVE_UNION_SEMUN -DHAVE_SCHED_YIELD -DHAVE_MSG_NOSIGNAL -DHAVE_MSGHDR_MSG_CONTROL -DHAVE_ALLOCA_H -DHAVE_TIMEGM -DHAVE_EPOLL -DHAVE_SIGIO_RT -DHAVE_SELECT -I/usr/include/postgresql -c db_res.c -o db_res.o db_res.c: In function ‘pg_convert_rows’: db_res.c:400: error: ‘_h’ undeclared (first use in this function) db_res.c:400: error: (Each undeclared identifier is reported only once db_res.c:400: error: for each function it appears in.) db_res.c: In function ‘pg_convert_row’: db_res.c:542: error: ‘col_len’ undeclared (first use in this function) db_res.c:502: warning: unused variable ‘row_len’ db_res.c: In function ‘pg_convert_rows’: db_res.c:710: error: expected declaration or statement at end of input make[1]: *** [db_res.o] Error 1 make[1]: Leaving directory `/usr/local/src/openser-1.3.3-tls/modules/postgres' marche:/usr/local/src/openser-1.3.3-tls# vim modules/postgres/db_
Il giorno gio, 13/11/2008 alle 17.46 +0100, Henning Westerholt ha scritto:
On Thursday 13 November 2008, Henning Westerholt wrote:
On Thursday 13 November 2008, Matteo Piazza wrote:
The issue is when I restart openser, it reads the data into the database and this is the result of the openserctl ul show:
Contact:: sip:s@172.25.18.168 Q= [..] Methods:: 0
As you can see the Methods is 0 and not 4294967295. So when I do a lookup(location) the function return as $retcode -2
When the asterisk register himself the methods come back to 4294967295.
Hi Matteo,
ok, now i understand the problem. It seems that this is not correctly restored during the loading after the restart. I did a few tests with the postgres driver, it behaves a little bit different then the mysql one in this case.
Hi Matteo,
i think i found the problem: the postgres module does not correctly evaluate the NULL values, so the usrloc module assumed incorrectly that its a '0' value, and not the ALL_METHOD flag. I already commited a fix to the trunk.
I've attached a small patch against the 1.3 branch, would be great if you could test this on your installation. If this fixes the problem, i'll do the backport to the 1.3 and 1.4 branch.
Cheers,
Henning
On Monday 17 November 2008, Matteo Piazza wrote:
I have an error during the compilation of the module. See the text below. As attachment the two files after the application of the pacth
Hi Matteo,
sorry, there happened some variables renaming between the releases that caused this problems. I've added a fixed patch.
Cheers,
Henning
Hi,
Now I can compile the modules but openser crash at the start. As attachment the output of the log message with debug=6.
Cheers,
Matteo
Il giorno lun, 17/11/2008 alle 14.53 +0100, Henning Westerholt ha scritto:
On Monday 17 November 2008, Matteo Piazza wrote:
I have an error during the compilation of the module. See the text below. As attachment the two files after the application of the pacth
Hi Matteo,
sorry, there happened some variables renaming between the releases that caused this problems. I've added a fixed patch.
Cheers,
Henning
On Thursday 20 November 2008, Matteo Piazza wrote:
Hi,
Now I can compile the modules but openser crash at the start. As attachment the output of the log message with debug=6.
Hi Matteo,
this is strange, as i tested this on the trunk of course, and here it worked fine so far. I'll investigate, thanks for the crash log and the report.
Cheers,
Henning
Ok,
to help you my openser.cfg, maybe it's an interaction with one of the others modules.
Matteo
Il giorno gio, 20/11/2008 alle 11.36 +0100, Henning Westerholt ha scritto:
On Thursday 20 November 2008, Matteo Piazza wrote:
Hi,
Now I can compile the modules but openser crash at the start. As attachment the output of the log message with debug=6.
Hi Matteo,
this is strange, as i tested this on the trunk of course, and here it worked fine so far. I'll investigate, thanks for the crash log and the report.
Cheers,
Henning
On Thursday 20 November 2008, Matteo Piazza wrote:
Hi,
Now I can compile the modules but openser crash at the start. As attachment the output of the log message with debug=6.
Hi Matteo,
from your log it seems the crash happened during the data loading of the pdt or permissions module. I found one crash (in a usrloc test), not sure if this is related. The postgres module in the 1.3 branch don't use the common DB infrastructure in the core for freeing the values. Because of the previous change in the NULL value handling it then tries to free a static dummy string value, which obviously is not valid.
Please find attached a updated patch that checks for this condition. I tested it with a few datasets in the pdt and trusted table (for permissions) too, it don't crash during startup in my setup.
When it still crash for you, then it would be really helpfull if you could activate the core dump writing, and send me the backtrace from gdb.
Thanks,
Henning
Hi Henning,
After few test it's working without crash, I think it's necessary more tests to be sure that now is fine. I will let you know if I detect any issue.
Thanks
Matteo
Il giorno gio, 20/11/2008 alle 12.57 +0100, Henning Westerholt ha scritto:
On Thursday 20 November 2008, Matteo Piazza wrote:
Hi,
Now I can compile the modules but openser crash at the start. As attachment the output of the log message with debug=6.
Hi Matteo,
from your log it seems the crash happened during the data loading of the pdt or permissions module. I found one crash (in a usrloc test), not sure if this is related. The postgres module in the 1.3 branch don't use the common DB infrastructure in the core for freeing the values. Because of the previous change in the NULL value handling it then tries to free a static dummy string value, which obviously is not valid.
Please find attached a updated patch that checks for this condition. I tested it with a few datasets in the pdt and trusted table (for permissions) too, it don't crash during startup in my setup.
When it still crash for you, then it would be really helpfull if you could activate the core dump writing, and send me the backtrace from gdb.
Thanks,
Henning
On Thursday 20 November 2008, Matteo Piazza wrote:
After few test it's working without crash, I think it's necessary more tests to be sure that now is fine. I will let you know if I detect any issue.
Hi Matteo,
thanks for the update. Yes, i also think this should be tested a little bit longer, i'll delay the backport to the stable branches.
Cheers,
Henning
-
Henning Westerholt -
Matteo Piazza