[OpenSER-Devel] [ openser-Bugs-1816765 ] openser crash on redirection

Mon Oct 22 17:33:27 CEST 2007

Bugs item #1816765, was opened at 2007-10-19 23:24
Message generated for change (Comment added) made by bogdan_iancu
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: Closed
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: Bogdan (bogdan_iancu)
Date: 2007-10-22 18:33

Message:
Logged In: YES 
user_id=1275325
Originator: NO

Hi Ovidiu,

Thanks - I made the backport.

Regards,
Bogdan

----------------------------------------------------------------------

Comment By: Ovidiu Sas (osas)
Date: 2007-10-22 16:59

Message:
Logged In: YES 
user_id=1395524
Originator: YES

Hi Bogdan,

I tested this ok.  Please backport the fix to 1.2 branch and then close
the bug.

Regards,
Ovidiu

----------------------------------------------------------------------

Comment By: Ovidiu Sas (osas)
Date: 2007-10-20 19: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 19: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 14: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