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.
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.
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:
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.
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:
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.
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:
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.
On Oct 15, 2010 at 00:14, Alex Balashov abalashov@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
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)
On Oct 15, 2010 at 02:47, Alex Balashov abalashov@evaristesys.com wrote:
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.
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.
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)
Andrei
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.
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.
On Oct 15, 2010 at 04:31, Alex Balashov abalashov@evaristesys.com wrote:
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.
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)
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.
Andrei
-
Alex Balashov -
Andrei Pelinescu-Onciul