Howdy, I've had a few crashes on one of my instances running OpenSIPs 2.2.7 over the last couple of days. It appears to be an issue in the siptrace.c file when a message without a call-id gets traced. For example:
SIP/2.0 400 Bad Request Via: SIP/2.0/UDP 45.35.xx.xx:5060;branch=z9hG4bK8a78.32fc86e1.2 Via: SIP/2.0/UDP 199.242.xx.xx:5060;branch=z9hG4bK1sansay3360535464rdb10237 From: <sip:+1984#[email protected]>;tag=sansay3360535464rdb10237 To: <sip:[email protected]> CSeq: 1 INVITE Error-Info: <sip:[email protected]>;cause="[line 007] SIP syntax error" Content-Length: 0 Resulting in a core file and a gdb backtrace of: (gdb) bt #0 0x00007f11bea1ece1 in sip_trace (msg=0x7f1244250148, info=0x7ffc09a008f0) at siptrace.c:1563 #1 0x00007f11bea29084 in sip_trace_w (msg=0x7f1244250148, param1=<optimized out>, param2=<optimized out>, param3=<optimized out>) at siptrace.c:1506 #2 0x000000000044c518 in do_action (a=a@entry=0x7f124421f548, msg=msg@entry=0x7f1244250148) at action.c:1844 #3 0x0000000000453075 in run_action_list (msg=<optimized out>, a=<optimized out>) at action.c:172 #4 run_actions (msg=0x7f1244250148, a=<optimized out>) at action.c:137 #5 run_top_route (a=<optimized out>, msg=msg@entry=0x7f1244250148) at action.c:204 #6 0x00007f11c0e6703f in reply_received (p_msg=0x7f1244250148) at t_reply.c:1458 #7 0x000000000047be6c in forward_reply (msg=msg@entry=0x7f1244250148) at forward.c:495 #8 0x0000000000459b82 in receive_msg ( buf=0x8683e0 <buf.8308> "SIP/2.0 400 Bad Request\r\nVia: SIP/2.0/UDP 45.35.xx.xx:5060;branch=z9hG4bK8a78.32fc86e1.2\r\nVia: SIP/2.0/UDP 199.242.xx.xx:5060;branch=z9hG4bK1sansay3360535464rdb10237\r\nFrom: <sip:+1984#1916424xxxx@199."..., len=<optimized out>, rcv_info=rcv_info@entry=0x7ffc09a01250, existing_context=existing_context@entry=0x0) at receive.c:257 #9 0x00000000005bded6 in udp_read_req (si=<optimized out>, The code at line 1552 in siptrace.c that should handle this doesn't seem to be triggered: if(parse_headers(msg, HDR_CALLID_F, 0)!=0) { LM_ERR("cannot parse call-id\n"); goto error; } Resulting in a bad pointer dereference and segfault here at line 1563: db_vals[1].val.str_val.s = msg->callid->body.s; If I change line 1552 to match the code in that the pv_get_callid function use to check the call-id, siptrace seems to detect the missing call-id fine. Here's a diff on the 2.2.7 siptrace.c --- orig/opensips-2.2.7/modules/siptrace/siptrace.c 2018-05-24 16:33:57.000000000 +0000 +++ fixed/opensips-2.2.7/modules/siptrace/siptrace.c 2018-10-15 19:17:39.020664338 +0000 @@ -1549,7 +1549,9 @@ goto error; } - if(parse_headers(msg, HDR_CALLID_F, 0)!=0) + if(msg->callid==NULL && ((parse_headers(msg, HDR_CALLID_F, 0)==-1) || + (msg->callid==NULL)) ) + { LM_ERR("cannot parse call-id\n"); goto error; Again, its only an issue if sip tracing is enabled (in my case hep transported to Homer) with messages missing a call-id. As far as I can tell, this may still exist in the master branch, but I've only tested in the 2.2.x releases. - Jon Abrams
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
