[OpenSER-Devel] [ openser-Bugs-1816765 ] openser crash on
redirection
SourceForge.net
noreply at sourceforge.net
Sat Oct 20 18:39:22 CEST 2007
Bugs item #1816765, was opened at 2007-10-19 16:24
Message generated for change (Comment added) made by osas
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1816765&group_id=139143
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: ver devel
Status: Open
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Ovidiu Sas (osas)
Assigned to: Bogdan (bogdan_iancu)
Summary: openser crash on redirection
Initial Comment:
I was testing the redirect functionality of openser using the following simple config file:
# ----------- global configuration parameters ------------------------
debug=9
fork=yes
log_stderror=no
check_via=no # (cmd. line: -v)
dns=no # (cmd. line: -r)
rev_dns=no # (cmd. line: -R)
listen=eth0
children=1
disable_tcp=yes
disable_dns_blacklist=true
# ------------------ module loading ----------------------------------
mpath="/usr/local/lib/openser/modules"
loadmodule "mysql.so"
loadmodule "sl.so"
loadmodule "tm.so"
modparam("tm", "fr_inv_timer", 180)
modparam("tm", "fr_inv_timer_avp", "$avp(i:26)")
modparam("tm", "fr_timer", 10)
modparam("tm", "fr_timer_avp", "$avp(i:25)")
modparam("tm", "noisy_ctimer", 0)
modparam("tm", "onreply_avp_mode", 1)
loadmodule "rr.so"
loadmodule "uri.so"
loadmodule "maxfwd.so"
loadmodule "usrloc.so"
modparam("usrloc", "matching_mode", 1)
modparam("usrloc", "nat_bflag", 6)
modparam("usrloc", "db_mode", 1)
modparam("usrloc", "db_url", "mysql://openser:openserrw@127.0.0.1/openser")
loadmodule "registrar.so"
modparam("registrar", "received_avp", "$avp(s:rcv)")
loadmodule "textops.so"
loadmodule "xlog.so"
loadmodule "mi_fifo.so"
modparam("mi_fifo", "fifo_name", "/tmp/openser_fifo")
loadmodule "acc.so"
loadmodule "uac_redirect.so"
# ------------------------- request routing logic -------------------
# main routing logic
route{
# initial sanity checks -- messages with
# max_forwards==0, or excessively long requests
if (!mf_process_maxfwd_header("10")) {
sl_send_reply("483","Too Many Hops");
exit;
};
if (msg:len >= 2048 ) {
sl_send_reply("513", "Message too big");
exit;
};
# we record-route all messages -- to make sure that
# subsequent messages will go through our proxy; that's
# particularly good if upstream and downstream entities
# use different transport protocol
if (!method=="REGISTER")
record_route();
# subsequent messages withing a dialog should take the
# path determined by record-routing
if (loose_route()) {
# mark routing logic in request
append_hf("P-hint: rr-enforced\r\n");
route(1);
};
if (!uri==myself) {
# mark routing logic in request
append_hf("P-hint: outbound\r\n");
# if you have some interdomain connections via TLS
#if(uri=~"@tls_domain1.net") {
# t_relay("tls:domain1.net");
# exit;
#} else if(uri=~"@tls_domain2.net") {
# t_relay("tls:domain2.net");
# exit;
#}
route(1);
};
# if the request is for other domain use UsrLoc
# (in case, it does not work, use the following command
# with proper names and addresses in it)
if (uri==myself) {
if (method=="REGISTER") {
save("location");
exit;
};
# native SIP destinations are handled using our USRLOC DB
if (!lookup("location")) {
sl_send_reply("404", "Not Found");
exit;
};
t_on_failure("2");
append_hf("P-hint: usrloc applied\r\n");
};
route(1);
}
route[1] {
# send it out now; use stateful forwarding as it works reliably
# even for UDP2TCP
if (!t_relay()) {
sl_reply_error();
};
exit;
}
failure_route[2] {
if (t_check_status("3[0-9][0-9]")) {
get_redirects("1:1","Redirected");
t_relay();
};
}
Here's the backtrace of the crash:
(gdb) bt
#0 0x404c3dc6 in acc_log_request (rq=0x40459920) at acc.c:223
#1 0x404c5f82 in w_acc_log_request (rq=0x40459920, comment=0x8184060 "P:\030\b\n", foo=0x404e065c "acc") at acc_logic.c:167
#2 0x404ddc79 in get_redirect (msg=0x40459920, maxt=1, maxb=1, reason=0x8184060) at rd_funcs.c:273
#3 0x404df867 in w_get_redirect2 (msg=0x40459920, max_c=0x101 <Address 0x101 out of bounds>, reason=0x8184060 "P:\030\b\n") at redirect.c:345
#4 0x08052546 in do_action (a=0x8183ad8, msg=0x40459920) at action.c:816
#5 0x08054c5a in run_action_list (a=0x8183ad8, msg=0x40459920) at action.c:132
#6 0x08054298 in do_action (a=0x8183c10, msg=0x40459920) at action.c:689
#7 0x08054c5a in run_action_list (a=0x8183c10, msg=0x40459920) at action.c:132
#8 0x08054fd4 in run_top_route (a=0x8183c10, msg=0x40459920) at action.c:112
#9 0x4044a1d5 in t_should_relay_response (Trans=0x40693cf0, new_code=<value optimized out>, branch=0, should_store=0xbffff954, should_relay=0xbffff958,
cancel_bitmap=0xbffffa10, reply=0x81885c0) at t_reply.c:596
#10 0x4044ab0d in relay_reply (t=0x40693cf0, p_msg=0x81885c0, branch=0, msg_status=302, cancel_bitmap=0xbffffa10) at t_reply.c:1024
#11 0x4044c186 in reply_received (p_msg=0x81885c0) at t_reply.c:1369
#12 0x08063900 in forward_reply (msg=0x81885c0) at forward.c:499
#13 0x080919b4 in receive_msg (
buf=0x816b040 "SIP/2.0 302 Moved Temporarily\r\nVia: SIP/2.0/UDP 10.11.10.63;branch=z9hG4bK94bb.2a443512.0\r\nVia: SIP/2.0/UDP 10.11.128.111:5060;branch=z9hG4bKec8272b5221c8eeab7a06d81;rport=5060\r\nFrom: \"4165863566\" <si"..., len=551, rcv_info=0xbffffb54) at receive.c:194
#14 0x080cecca in udp_rcv_loop () at udp_server.c:440
#15 0x0806bc81 in main (argc=3, argv=0x0) at main.c:788
----------------------------------------------------------------------
>Comment By: Ovidiu Sas (osas)
Date: 2007-10-20 12:39
Message:
Logged In: YES
user_id=1395524
Originator: YES
Hi Bogdan,
I will validate the fix on Monday.
Thanks for the quick response,
Ovidiu
----------------------------------------------------------------------
Comment By: Bogdan (bogdan_iancu)
Date: 2007-10-20 12:30
Message:
Logged In: YES
user_id=1275325
Originator: NO
Hi Ovidiu,
I just made a fix on the devel version - please upload and let me know if
it works. If everything ok, I will do the backport to 1.2 also.
Thanks and regards,
Bogdan
----------------------------------------------------------------------
Comment By: Bogdan (bogdan_iancu)
Date: 2007-10-20 07:44
Message:
Logged In: YES
user_id=1275325
Originator: NO
Hi Ovidiu,
I suspect the crash is in uac_redirect when triggering the acc function -
the protoype of these function changed and there is a possibility that the
uac_redirect module was not also updated.
I will check on this.
regards,
bogdan
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1816765&group_id=139143
More information about the Devel
mailing list