15 Oct
2010
15 Oct
'10
7:14 a.m.
I had the following code as a register handler:
t_check_request();
if(!www_authorize("$td", "subscriber")) {
switch($rc) {
case -1:
xlog(something about authentication error);
break;
case -2:
xlog(something about invalid password);
send_reply("403", "Forbidden");
exit;
case -3:
xlog(something about invalid user);
send_reply("403", "Forbidden");
exit;
default:
xlog(something else)
}
www_challenge("$td", "1");
t_release();
exit;
}
It worked fine with the initial 3.1.0 tarball from last week. But it
crashes with the tarball that is on the website right now:
Core was generated by `/usr/local/sbin/kamailio -P
/var/run/kamailio/kamailio.pid -m 64 -u root -g roo'.
Program terminated with signal 11, Segmentation fault.
#0 atomic_and_int (id=2116215340, p=128 '\200')
at ../../atomic/atomic_x86.h:227
227 ../../atomic/atomic_x86.h: No such file or directory.
in ../../atomic/atomic_x86.h
(gdb) where
#0 atomic_and_int (id=2116215340, p=128 '\200')
at ../../atomic/atomic_x86.h:227
#1 otn_new (id=2116215340, p=128 '\200') at ot_nonce.c:196
#2 0xb6fe5bba in get_challenge_hf (msg=0x836a63c, stale=0,
realm=0xbffb0ad4,
nonce=0x0, algorithm=0x0, qop=0xb6fee9d0, hftype=13, ahf=0xbffb0acc)
at challenge.c:181
#3 0xb6fe3c4f in auth_challenge (msg=0x836a63c, p1=<value optimized out>,
p2=0x835fd8c "`\022\060\b\001", hftype=13) at auth_mod.c:613
#4 0x08059de4 in do_action (h=0xbffb2098, a=0x830453c, msg=0x836a63c)
at action.c:1099
#5 0x080615b0 in run_actions (h=0xbffb2098, a=0x8304498, msg=0x836a63c)
at action.c:1553
#6 0x0805a530 in do_action (h=0xbffb2098, a=0x830720c, msg=0x836a63c)
at action.c:1259
#7 0x080615b0 in run_actions (h=0xbffb2098, a=0x830720c, msg=0x836a63c)
at action.c:1553
#8 0x0805a61d in do_action (h=0xbffb2098, a=0x830787c, msg=0x836a63c)
at action.c:1084
#9 0x080615b0 in run_actions (h=0xbffb2098, a=0x8304090, msg=0x836a63c)
at action.c:1553
#10 0x0805a26c in do_action (h=0xbffb2098, a=0x82ea7d8, msg=0x836a63c)
at action.c:711
#11 0x080615b0 in run_actions (h=0xbffb2098, a=0x82ea7d8, msg=0x836a63c)
at action.c:1553
#12 0x0805a61d in do_action (h=0xbffb2098, a=0x82eb090, msg=0x836a63c)
at action.c:1084
#13 0x080615b0 in run_actions (h=0xbffb2098, a=0x82eb090, msg=0x836a63c)
at action.c:1553
#14 0x0805caff in do_action (h=0xbffb2098, a=0x82eb134, msg=0x836a63c)
at action.c:1088
#15 0x080615b0 in run_actions (h=0xbffb2098, a=0x82eb134, msg=0x836a63c)
at action.c:1553
#16 0x0805caff in do_action (h=0xbffb2098, a=0x82eb1d8, msg=0x836a63c)
---Type <return> to continue, or q <return> to quit---
at action.c:1088
#17 0x080615b0 in run_actions (h=0xbffb2098, a=0x82e9124, msg=0x836a63c)
at action.c:1553
#18 0x0805a61d in do_action (h=0xbffb2098, a=0x82ebbb0, msg=0x836a63c)
at action.c:1084
#19 0x080615b0 in run_actions (h=0xbffb2098, a=0x82df70c, msg=0x836a63c)
at action.c:1553
#20 0x08061854 in run_top_route (a=0x82df70c, msg=0x836a63c, c=0x0)
at action.c:1626
#21 0x080d5866 in receive_msg (
buf=0x827e880 "REGISTER sip:sip.evaristesys.com SIP/2.0\r\nVia:
SIP/2.0/UDP
208.52.173.7:5060;branch=z9hG4bK39b78214;rport\r\nMax-Forwards:
32\r\nFrom: <sip:abalashov@sip.evaristesys.com>;tag=as4854d363\r\nTo:
<sip:abalasho"...,
len=678, rcv_info=0xbffb22dc) at receive.c:205
#22 0x0815b512 in udp_rcv_loop () at udp_server.c:532
#23 0x080a2917 in main_loop () at main.c:1554
#24 0x080a5142 in main (argc=13, argv=0xbffb2574) at main.c:2398
I have not tried with sip-router:master:HEAD yet.
--
Alex Balashov - Principal
Evariste Systems LLC
1170 Peachtree Street
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
15 Oct
15 Oct
7:17 a.m.
On 10/15/2010 12:14 AM, Alex Balashov wrote:
I had the following code as a register handler:
t_check_request();
I meant t_lookup_request().
if(!www_authorize("$td", "subscriber")) {
switch($rc) {
case -1:
xlog(something about authentication error);
break;
case -2:
xlog(something about invalid password);
send_reply("403", "Forbidden");
exit;
case -3:
xlog(something about invalid user);
send_reply("403", "Forbidden");
exit;
default:
xlog(something else)
}
www_challenge("$td", "1");
t_release();
exit;
}
It worked fine with the initial 3.1.0 tarball from last week. But it
crashes with the tarball that is on the website right now:
Core was generated by `/usr/local/sbin/kamailio -P
/var/run/kamailio/kamailio.pid -m 64 -u root -g roo'.
Program terminated with signal 11, Segmentation fault.
#0 atomic_and_int (id=2116215340, p=128 '\200')
at ../../atomic/atomic_x86.h:227
227 ../../atomic/atomic_x86.h: No such file or directory.
in ../../atomic/atomic_x86.h
(gdb) where
#0 atomic_and_int (id=2116215340, p=128 '\200')
at ../../atomic/atomic_x86.h:227
#1 otn_new (id=2116215340, p=128 '\200') at ot_nonce.c:196
#2 0xb6fe5bba in get_challenge_hf (msg=0x836a63c, stale=0,
realm=0xbffb0ad4,
nonce=0x0, algorithm=0x0, qop=0xb6fee9d0, hftype=13, ahf=0xbffb0acc)
at challenge.c:181
#3 0xb6fe3c4f in auth_challenge (msg=0x836a63c, p1=<value optimized out>,
p2=0x835fd8c "`\022\060\b\001", hftype=13) at auth_mod.c:613
#4 0x08059de4 in do_action (h=0xbffb2098, a=0x830453c, msg=0x836a63c)
at action.c:1099
#5 0x080615b0 in run_actions (h=0xbffb2098, a=0x8304498, msg=0x836a63c)
at action.c:1553
#6 0x0805a530 in do_action (h=0xbffb2098, a=0x830720c, msg=0x836a63c)
at action.c:1259
#7 0x080615b0 in run_actions (h=0xbffb2098, a=0x830720c, msg=0x836a63c)
at action.c:1553
#8 0x0805a61d in do_action (h=0xbffb2098, a=0x830787c, msg=0x836a63c)
at action.c:1084
#9 0x080615b0 in run_actions (h=0xbffb2098, a=0x8304090, msg=0x836a63c)
at action.c:1553
#10 0x0805a26c in do_action (h=0xbffb2098, a=0x82ea7d8, msg=0x836a63c)
at action.c:711
#11 0x080615b0 in run_actions (h=0xbffb2098, a=0x82ea7d8, msg=0x836a63c)
at action.c:1553
#12 0x0805a61d in do_action (h=0xbffb2098, a=0x82eb090, msg=0x836a63c)
at action.c:1084
#13 0x080615b0 in run_actions (h=0xbffb2098, a=0x82eb090, msg=0x836a63c)
at action.c:1553
#14 0x0805caff in do_action (h=0xbffb2098, a=0x82eb134, msg=0x836a63c)
at action.c:1088
#15 0x080615b0 in run_actions (h=0xbffb2098, a=0x82eb134, msg=0x836a63c)
at action.c:1553
#16 0x0805caff in do_action (h=0xbffb2098, a=0x82eb1d8, msg=0x836a63c)
---Type <return> to continue, or q <return> to quit---
at action.c:1088
#17 0x080615b0 in run_actions (h=0xbffb2098, a=0x82e9124, msg=0x836a63c)
at action.c:1553
#18 0x0805a61d in do_action (h=0xbffb2098, a=0x82ebbb0, msg=0x836a63c)
at action.c:1084
#19 0x080615b0 in run_actions (h=0xbffb2098, a=0x82df70c, msg=0x836a63c)
at action.c:1553
#20 0x08061854 in run_top_route (a=0x82df70c, msg=0x836a63c, c=0x0)
at action.c:1626
#21 0x080d5866 in receive_msg (
buf=0x827e880 "REGISTER sip:sip.evaristesys.com SIP/2.0\r\nVia:
SIP/2.0/UDP
208.52.173.7:5060;branch=z9hG4bK39b78214;rport\r\nMax-Forwards:
32\r\nFrom: <sip:abalashov@sip.evaristesys.com>;tag=as4854d363\r\nTo:
<sip:abalasho"...,
len=678, rcv_info=0xbffb22dc) at receive.c:205
#22 0x0815b512 in udp_rcv_loop () at udp_server.c:532
#23 0x080a2917 in main_loop () at main.c:1554
#24 0x080a5142 in main (argc=13, argv=0xbffb2574) at main.c:2398
I have not tried with sip-router:master:HEAD yet.
--
Alex Balashov - Principal
Evariste Systems LLC
1170 Peachtree Street
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
7:59 a.m.
It crashes with the current master HEAD too.
On 10/15/2010 12:17 AM, Alex Balashov wrote:
On 10/15/2010 12:14 AM, Alex Balashov wrote:
--
Alex Balashov - Principal
Evariste Systems LLC
1170 Peachtree Street
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
I had the following code as a register handler:
t_check_request();
I meant t_lookup_request().
if(!www_authorize("$td", "subscriber")) {
switch($rc) {
case -1:
xlog(something about authentication error);
break;
case -2:
xlog(something about invalid password);
send_reply("403", "Forbidden");
exit;
case -3:
xlog(something about invalid user);
send_reply("403", "Forbidden");
exit;
default:
xlog(something else)
}
www_challenge("$td", "1");
t_release();
exit;
}
It worked fine with the initial 3.1.0 tarball from last week. But it
crashes with the tarball that is on the website right now:
Core was generated by `/usr/local/sbin/kamailio -P
/var/run/kamailio/kamailio.pid -m 64 -u root -g roo'.
Program terminated with signal 11, Segmentation fault.
#0 atomic_and_int (id=2116215340, p=128 '\200')
at ../../atomic/atomic_x86.h:227
227 ../../atomic/atomic_x86.h: No such file or directory.
in ../../atomic/atomic_x86.h
(gdb) where
#0 atomic_and_int (id=2116215340, p=128 '\200')
at ../../atomic/atomic_x86.h:227
#1 otn_new (id=2116215340, p=128 '\200') at ot_nonce.c:196
#2 0xb6fe5bba in get_challenge_hf (msg=0x836a63c, stale=0,
realm=0xbffb0ad4,
nonce=0x0, algorithm=0x0, qop=0xb6fee9d0, hftype=13, ahf=0xbffb0acc)
at challenge.c:181
#3 0xb6fe3c4f in auth_challenge (msg=0x836a63c, p1=<value optimized out>,
p2=0x835fd8c "`\022\060\b\001", hftype=13) at auth_mod.c:613
#4 0x08059de4 in do_action (h=0xbffb2098, a=0x830453c, msg=0x836a63c)
at action.c:1099
#5 0x080615b0 in run_actions (h=0xbffb2098, a=0x8304498, msg=0x836a63c)
at action.c:1553
#6 0x0805a530 in do_action (h=0xbffb2098, a=0x830720c, msg=0x836a63c)
at action.c:1259
#7 0x080615b0 in run_actions (h=0xbffb2098, a=0x830720c, msg=0x836a63c)
at action.c:1553
#8 0x0805a61d in do_action (h=0xbffb2098, a=0x830787c, msg=0x836a63c)
at action.c:1084
#9 0x080615b0 in run_actions (h=0xbffb2098, a=0x8304090, msg=0x836a63c)
at action.c:1553
#10 0x0805a26c in do_action (h=0xbffb2098, a=0x82ea7d8, msg=0x836a63c)
at action.c:711
#11 0x080615b0 in run_actions (h=0xbffb2098, a=0x82ea7d8, msg=0x836a63c)
at action.c:1553
#12 0x0805a61d in do_action (h=0xbffb2098, a=0x82eb090, msg=0x836a63c)
at action.c:1084
#13 0x080615b0 in run_actions (h=0xbffb2098, a=0x82eb090, msg=0x836a63c)
at action.c:1553
#14 0x0805caff in do_action (h=0xbffb2098, a=0x82eb134, msg=0x836a63c)
at action.c:1088
#15 0x080615b0 in run_actions (h=0xbffb2098, a=0x82eb134, msg=0x836a63c)
at action.c:1553
#16 0x0805caff in do_action (h=0xbffb2098, a=0x82eb1d8, msg=0x836a63c)
---Type <return> to continue, or q <return> to quit---
at action.c:1088
#17 0x080615b0 in run_actions (h=0xbffb2098, a=0x82e9124, msg=0x836a63c)
at action.c:1553
#18 0x0805a61d in do_action (h=0xbffb2098, a=0x82ebbb0, msg=0x836a63c)
at action.c:1084
#19 0x080615b0 in run_actions (h=0xbffb2098, a=0x82df70c, msg=0x836a63c)
at action.c:1553
#20 0x08061854 in run_top_route (a=0x82df70c, msg=0x836a63c, c=0x0)
at action.c:1626
#21 0x080d5866 in receive_msg (
buf=0x827e880 "REGISTER sip:sip.evaristesys.com SIP/2.0\r\nVia:
SIP/2.0/UDP
208.52.173.7:5060;branch=z9hG4bK39b78214;rport\r\nMax-Forwards:
32\r\nFrom: <sip:abalashov@sip.evaristesys.com>;tag=as4854d363\r\nTo:
<sip:abalasho"...,
len=678, rcv_info=0xbffb22dc) at receive.c:205
#22 0x0815b512 in udp_rcv_loop () at udp_server.c:532
#23 0x080a2917 in main_loop () at main.c:1554
#24 0x080a5142 in main (argc=13, argv=0xbffb2574) at main.c:2398
I have not tried with sip-router:master:HEAD yet.
8 a.m.
It crashes even if I use the new force_stateless_reply option (set to 1)
and remove t_lookup_request() and t_release(). The problem seems to be
a bug in www_challenge().
The registrant is ordinary Asterisk 1.6.2.13, nothing special. It
worked fine on the initial release. I wonder what broke.
On 10/15/2010 12:59 AM, Alex Balashov wrote:
It crashes with the current master HEAD too.
On 10/15/2010 12:17 AM, Alex Balashov wrote:
--
Alex Balashov - Principal
Evariste Systems LLC
1170 Peachtree Street
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
On 10/15/2010 12:14 AM, Alex Balashov wrote:
I had the following code as a register handler:
t_check_request();
I meant t_lookup_request().
if(!www_authorize("$td", "subscriber")) {
switch($rc) {
case -1:
xlog(something about authentication error);
break;
case -2:
xlog(something about invalid password);
send_reply("403", "Forbidden");
exit;
case -3:
xlog(something about invalid user);
send_reply("403", "Forbidden");
exit;
default:
xlog(something else)
}
www_challenge("$td", "1");
t_release();
exit;
}
It worked fine with the initial 3.1.0 tarball from last week. But it
crashes with the tarball that is on the website right now:
Core was generated by `/usr/local/sbin/kamailio -P
/var/run/kamailio/kamailio.pid -m 64 -u root -g roo'.
Program terminated with signal 11, Segmentation fault.
#0 atomic_and_int (id=2116215340, p=128 '\200')
at ../../atomic/atomic_x86.h:227
227 ../../atomic/atomic_x86.h: No such file or directory.
in ../../atomic/atomic_x86.h
(gdb) where
#0 atomic_and_int (id=2116215340, p=128 '\200')
at ../../atomic/atomic_x86.h:227
#1 otn_new (id=2116215340, p=128 '\200') at ot_nonce.c:196
#2 0xb6fe5bba in get_challenge_hf (msg=0x836a63c, stale=0,
realm=0xbffb0ad4,
nonce=0x0, algorithm=0x0, qop=0xb6fee9d0, hftype=13, ahf=0xbffb0acc)
at challenge.c:181
#3 0xb6fe3c4f in auth_challenge (msg=0x836a63c, p1=<value optimized
out>,
p2=0x835fd8c "`\022\060\b\001", hftype=13) at auth_mod.c:613
#4 0x08059de4 in do_action (h=0xbffb2098, a=0x830453c, msg=0x836a63c)
at action.c:1099
#5 0x080615b0 in run_actions (h=0xbffb2098, a=0x8304498, msg=0x836a63c)
at action.c:1553
#6 0x0805a530 in do_action (h=0xbffb2098, a=0x830720c, msg=0x836a63c)
at action.c:1259
#7 0x080615b0 in run_actions (h=0xbffb2098, a=0x830720c, msg=0x836a63c)
at action.c:1553
#8 0x0805a61d in do_action (h=0xbffb2098, a=0x830787c, msg=0x836a63c)
at action.c:1084
#9 0x080615b0 in run_actions (h=0xbffb2098, a=0x8304090, msg=0x836a63c)
at action.c:1553
#10 0x0805a26c in do_action (h=0xbffb2098, a=0x82ea7d8, msg=0x836a63c)
at action.c:711
#11 0x080615b0 in run_actions (h=0xbffb2098, a=0x82ea7d8, msg=0x836a63c)
at action.c:1553
#12 0x0805a61d in do_action (h=0xbffb2098, a=0x82eb090, msg=0x836a63c)
at action.c:1084
#13 0x080615b0 in run_actions (h=0xbffb2098, a=0x82eb090, msg=0x836a63c)
at action.c:1553
#14 0x0805caff in do_action (h=0xbffb2098, a=0x82eb134, msg=0x836a63c)
at action.c:1088
#15 0x080615b0 in run_actions (h=0xbffb2098, a=0x82eb134, msg=0x836a63c)
at action.c:1553
#16 0x0805caff in do_action (h=0xbffb2098, a=0x82eb1d8, msg=0x836a63c)
---Type <return> to continue, or q <return> to quit---
at action.c:1088
#17 0x080615b0 in run_actions (h=0xbffb2098, a=0x82e9124, msg=0x836a63c)
at action.c:1553
#18 0x0805a61d in do_action (h=0xbffb2098, a=0x82ebbb0, msg=0x836a63c)
at action.c:1084
#19 0x080615b0 in run_actions (h=0xbffb2098, a=0x82df70c, msg=0x836a63c)
at action.c:1553
#20 0x08061854 in run_top_route (a=0x82df70c, msg=0x836a63c, c=0x0)
at action.c:1626
#21 0x080d5866 in receive_msg (
buf=0x827e880 "REGISTER sip:sip.evaristesys.com SIP/2.0\r\nVia:
SIP/2.0/UDP
208.52.173.7:5060;branch=z9hG4bK39b78214;rport\r\nMax-Forwards:
32\r\nFrom: <sip:abalashov@sip.evaristesys.com>;tag=as4854d363\r\nTo:
<sip:abalasho"...,
len=678, rcv_info=0xbffb22dc) at receive.c:205
#22 0x0815b512 in udp_rcv_loop () at udp_server.c:532
#23 0x080a2917 in main_loop () at main.c:1554
#24 0x080a5142 in main (argc=13, argv=0xbffb2574) at main.c:2398
I have not tried with sip-router:master:HEAD yet.
9:08 a.m.
Well, that may be an incorrect statement. I believe I had the 'auth'
module from the wrong archive loaded.
So, it seems clear in master:HEAD so far. However, it is _definitely_
broken in the current public tarball.
On 10/15/2010 12:59 AM, Alex Balashov wrote:
It crashes with the current master HEAD too.
On 10/15/2010 12:17 AM, Alex Balashov wrote:
--
Alex Balashov - Principal
Evariste Systems LLC
1170 Peachtree Street
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
On 10/15/2010 12:14 AM, Alex Balashov wrote:
I had the following code as a register handler:
t_check_request();
I meant t_lookup_request().
if(!www_authorize("$td", "subscriber")) {
switch($rc) {
case -1:
xlog(something about authentication error);
break;
case -2:
xlog(something about invalid password);
send_reply("403", "Forbidden");
exit;
case -3:
xlog(something about invalid user);
send_reply("403", "Forbidden");
exit;
default:
xlog(something else)
}
www_challenge("$td", "1");
t_release();
exit;
}
It worked fine with the initial 3.1.0 tarball from last week. But it
crashes with the tarball that is on the website right now:
Core was generated by `/usr/local/sbin/kamailio -P
/var/run/kamailio/kamailio.pid -m 64 -u root -g roo'.
Program terminated with signal 11, Segmentation fault.
#0 atomic_and_int (id=2116215340, p=128 '\200')
at ../../atomic/atomic_x86.h:227
227 ../../atomic/atomic_x86.h: No such file or directory.
in ../../atomic/atomic_x86.h
(gdb) where
#0 atomic_and_int (id=2116215340, p=128 '\200')
at ../../atomic/atomic_x86.h:227
#1 otn_new (id=2116215340, p=128 '\200') at ot_nonce.c:196
#2 0xb6fe5bba in get_challenge_hf (msg=0x836a63c, stale=0,
realm=0xbffb0ad4,
nonce=0x0, algorithm=0x0, qop=0xb6fee9d0, hftype=13, ahf=0xbffb0acc)
at challenge.c:181
#3 0xb6fe3c4f in auth_challenge (msg=0x836a63c, p1=<value optimized
out>,
p2=0x835fd8c "`\022\060\b\001", hftype=13) at auth_mod.c:613
#4 0x08059de4 in do_action (h=0xbffb2098, a=0x830453c, msg=0x836a63c)
at action.c:1099
#5 0x080615b0 in run_actions (h=0xbffb2098, a=0x8304498, msg=0x836a63c)
at action.c:1553
#6 0x0805a530 in do_action (h=0xbffb2098, a=0x830720c, msg=0x836a63c)
at action.c:1259
#7 0x080615b0 in run_actions (h=0xbffb2098, a=0x830720c, msg=0x836a63c)
at action.c:1553
#8 0x0805a61d in do_action (h=0xbffb2098, a=0x830787c, msg=0x836a63c)
at action.c:1084
#9 0x080615b0 in run_actions (h=0xbffb2098, a=0x8304090, msg=0x836a63c)
at action.c:1553
#10 0x0805a26c in do_action (h=0xbffb2098, a=0x82ea7d8, msg=0x836a63c)
at action.c:711
#11 0x080615b0 in run_actions (h=0xbffb2098, a=0x82ea7d8, msg=0x836a63c)
at action.c:1553
#12 0x0805a61d in do_action (h=0xbffb2098, a=0x82eb090, msg=0x836a63c)
at action.c:1084
#13 0x080615b0 in run_actions (h=0xbffb2098, a=0x82eb090, msg=0x836a63c)
at action.c:1553
#14 0x0805caff in do_action (h=0xbffb2098, a=0x82eb134, msg=0x836a63c)
at action.c:1088
#15 0x080615b0 in run_actions (h=0xbffb2098, a=0x82eb134, msg=0x836a63c)
at action.c:1553
#16 0x0805caff in do_action (h=0xbffb2098, a=0x82eb1d8, msg=0x836a63c)
---Type <return> to continue, or q <return> to quit---
at action.c:1088
#17 0x080615b0 in run_actions (h=0xbffb2098, a=0x82e9124, msg=0x836a63c)
at action.c:1553
#18 0x0805a61d in do_action (h=0xbffb2098, a=0x82ebbb0, msg=0x836a63c)
at action.c:1084
#19 0x080615b0 in run_actions (h=0xbffb2098, a=0x82df70c, msg=0x836a63c)
at action.c:1553
#20 0x08061854 in run_top_route (a=0x82df70c, msg=0x836a63c, c=0x0)
at action.c:1626
#21 0x080d5866 in receive_msg (
buf=0x827e880 "REGISTER sip:sip.evaristesys.com SIP/2.0\r\nVia:
SIP/2.0/UDP
208.52.173.7:5060;branch=z9hG4bK39b78214;rport\r\nMax-Forwards:
32\r\nFrom: <sip:abalashov@sip.evaristesys.com>;tag=as4854d363\r\nTo:
<sip:abalasho"...,
len=678, rcv_info=0xbffb22dc) at receive.c:205
#22 0x0815b512 in udp_rcv_loop () at udp_server.c:532
#23 0x080a2917 in main_loop () at main.c:1554
#24 0x080a5142 in main (argc=13, argv=0xbffb2574) at main.c:2398
I have not tried with sip-router:master:HEAD yet.
9:38 a.m.
On Oct 15, 2010 at 00:14, Alex Balashov <abalashov(a)evaristesys.com> wrote:
[...]
It worked fine with the initial 3.1.0 tarball from last week. But
it crashes with the tarball that is on the website right now:
Core was generated by `/usr/local/sbin/kamailio -P
/var/run/kamailio/kamailio.pid -m 64 -u root -g roo'.
Program terminated with signal 11, Segmentation fault.
#0 atomic_and_int (id=2116215340, p=128 '\200')
at ../../atomic/atomic_x86.h:227
227 ../../atomic/atomic_x86.h: No such file or directory.
in ../../atomic/atomic_x86.h
(gdb) where
#0 atomic_and_int (id=2116215340, p=128 '\200')
at ../../atomic/atomic_x86.h:227
#1 otn_new (id=2116215340, p=128 '\200') at ot_nonce.c:196
p=128 is very strange (either a no-debugging artifact or an obviously
wrong value, since the maximum pool number is 63).
Do you have both nonce_count and one_time_nonce enabled in the same
time? If so could you try with nonce_count disabled and see if you still
get this problem?
Could you send me all the auth modparam lines that you have in your
config? (nid_pool_no, nc_*, otn_in*)
Thanks,
Andrei
9:47 a.m.
On 10/15/2010 02:38 AM, Andrei Pelinescu-Onciul wrote:
Do you have both nonce_count and one_time_nonce
enabled in the same
time? If so could you try with nonce_count disabled and see if you still
get this problem?
I do have them both enabled concomitantly, but the documentation did not
say I cannot.
No, the crash does not happen if I disable nonce_count. But, in that
situation, with the same code as in my initial report, responses are
challenged at infinitum without successful credential acceptance.
Presumably that is an artifact of nonce_count being 0.
Could you send me all the auth modparam lines that you
have in your
config? (nid_pool_no, nc_*, otn_in*)
Sure:
modparam("auth", "auth_checks_register", 15)
modparam("auth", "auth_checks_no_dlg", 15)
modparam("auth", "auth_checks_in_dlg", 7)
modparam("auth", "qop", "auth")
modparam("auth", "nonce_count", 1)
modparam("auth", "one_time_nonce", 1)
modparam("auth", "nid_pool_no", 4)
modparam("auth", "nc_array_size", 8388608) # 8 MB.
modparam("auth", "otn_in_flight_no", 8388608) # 8 MB
modparam("auth", "nonce_expire", 600) # 10 minutes.
modparam("auth", "nonce_auth_max_drift", 5) # 5 seconds
modparam("auth", "force_stateless_reply", 0)
--
Alex Balashov - Principal
Evariste Systems LLC
1170 Peachtree Street
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
11:18 a.m.
On Oct 15, 2010 at 02:47, Alex Balashov <abalashov(a)evaristesys.com> wrote:
Andrei
On 10/15/2010 02:38 AM, Andrei Pelinescu-Onciul
wrote:
Yes, it's a bug. It's just not something I've tested before, that's why
I've asked.
It should be fixed now.
Do you have both nonce_count and one_time_nonce
enabled in the same
time? If so could you try with nonce_count disabled and see if you still
get this problem?
I do have them both enabled concomitantly, but the documentation did
not say I cannot.
No, the crash does not happen if I disable nonce_count. But, in
that situation, with the same code as in my initial report,
responses are challenged at infinitum without successful credential
acceptance. Presumably that is an artifact of nonce_count being 0.
That's very strange. It should work.
Could you send me a packet capture with re-challenged requests?
Could you try with the auth_checks_* commented out?
Could you also try only nonce_count and disabled one_time_nonce?
Could you send me all the auth modparam lines that
you have in your
config? (nid_pool_no, nc_*, otn_in*)
Sure:
modparam("auth", "auth_checks_register", 15)
modparam("auth", "auth_checks_no_dlg", 15)
modparam("auth", "auth_checks_in_dlg", 7)
modparam("auth", "qop", "auth")
modparam("auth", "nonce_count", 1)
modparam("auth", "one_time_nonce", 1)
modparam("auth", "nid_pool_no", 4)
modparam("auth", "nc_array_size", 8388608) # 8 MB.
modparam("auth", "otn_in_flight_no", 8388608) # 8 MB
modparam("auth", "nonce_expire", 600) # 10 minutes.
modparam("auth", "nonce_auth_max_drift", 5) # 5 seconds
modparam("auth", "force_stateless_reply", 0)
11:31 a.m.
On 10/15/2010 04:18 AM, Andrei Pelinescu-Onciul wrote:
Yes, it's a bug. It's just not something
I've tested before,
that's why I've asked. It should be fixed now.
Understandable, and thanks for the commit!
That's very strange. It should work.
Could you send me a packet capture with re-challenged requests?
It has been sent to you privately.
Could you try with the auth_checks_* commented out?
It does indeed work, when I comment out:
#modparam("auth", "auth_checks_register", 15)
I wonder if not all of (1 | 2 | 4 | 8) that am trying to use there are
actually appropriate for REGISTER.
Could you also try only nonce_count and disabled
one_time_nonce?
That does not work unless I disable the auth_register_checks above.
That's clearly the issue.
--
Alex Balashov - Principal
Evariste Systems LLC
1170 Peachtree Street
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
11:34 a.m.
On 10/15/2010 04:31 AM, Alex Balashov wrote:
I wonder if not all of (1 | 2 | 4 | 8) that am trying
to use there are
actually appropriate for REGISTER.
Ah. The From tag (4) changes on every new re-send of REGISTER. Oops!
:-) I don't think this is a bug in sip-router.
--
Alex Balashov - Principal
Evariste Systems LLC
1170 Peachtree Street
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
11:52 a.m.
On Oct 15, 2010 at 04:31, Alex Balashov <abalashov(a)evaristesys.com> wrote:
Andrei
On 10/15/2010 04:18 AM, Andrei Pelinescu-Onciul
wrote:
Yes, that's the problem. You should not enable 4 (from_tag) for
REGISTER, since that can change for the challenged request (confirmed by
the dump you've sent me).
We probably should update the doc with some good examples and warnings.
I think the safest settings are:
# r-uri, call-id and src_ip
modparam("auth", "auth_checks_register", 11)
# r-uri, src_ip (call-id and from might change)
modparam("auth", "auth_checks_no_dlg", 9)
# everything for in-dialog (r-uri, call-id, from_tag, src_ip)
modparam("auth", "auth_checks_in_dlg", 15)
Yes, it's a bug. It's just not something
I've tested before,
that's why I've asked. It should be fixed now.
Understandable, and thanks for the commit!
That's very strange. It should work.
Could you send me a packet capture with re-challenged requests?
It has been sent to you privately.
Could you try with the auth_checks_* commented
out?
It does indeed work, when I comment out:
#modparam("auth", "auth_checks_register", 15)
I wonder if not all of (1 | 2 | 4 | 8) that am trying to use there
are actually appropriate for REGISTER. Could you also try only nonce_count and disabled
one_time_nonce?
That does not work unless I disable the auth_register_checks above.
That's clearly the issue.
5152
days inactive
5152
days old
10 comments
2 participants
participants (2)
-
Alex Balashov -
Andrei Pelinescu-Onciul