<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Howdy,</div><div></div><div><br></div><div>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:<br></div><div><br></div><div>SIP/2.0 400 Bad Request<br>Via: SIP/2.0/UDP 45.35.xx.xx:5060;branch=z9hG4bK8a78.32fc86e1.2<br>Via: SIP/2.0/UDP 199.242.xx.xx:5060;branch=z9hG4bK1sansay3360535464rdb10237<br>From: <sip:+1984#1916424xxxx@199.242.xx.xx>;tag=sansay3360535464rdb10237<br>To: <sip:916424xxxx@206.147.xx.xx><br>CSeq: 1 INVITE<br>Error-Info: <sip:916424xxxx@206.147.xx.xx>;cause="[line 007] SIP syntax error"<br>Content-Length: 0</div><div><br></div><div>Resulting in a core file and a gdb backtrace of:</div><div><br></div><div>(gdb) bt<br>#0  0x00007f11bea1ece1 in sip_trace (msg=0x7f1244250148, info=0x7ffc09a008f0)<br>    at siptrace.c:1563<br>#1  0x00007f11bea29084 in sip_trace_w (msg=0x7f1244250148,<br>    param1=<optimized out>, param2=<optimized out>, param3=<optimized out>)<br>    at siptrace.c:1506<br>#2  0x000000000044c518 in do_action (a=a@entry=0x7f124421f548,<br>    msg=msg@entry=0x7f1244250148) at action.c:1844<br>#3  0x0000000000453075 in run_action_list (msg=<optimized out>,<br>    a=<optimized out>) at action.c:172<br>#4  run_actions (msg=0x7f1244250148, a=<optimized out>) at action.c:137<br>#5  run_top_route (a=<optimized out>, msg=msg@entry=0x7f1244250148)<br>    at action.c:204<br>#6  0x00007f11c0e6703f in reply_received (p_msg=0x7f1244250148)<br>    at t_reply.c:1458<br>#7  0x000000000047be6c in forward_reply (msg=msg@entry=0x7f1244250148)<br>    at forward.c:495<br>#8  0x0000000000459b82 in receive_msg (<br>    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,<br>    existing_context=existing_context@entry=0x0) at receive.c:257<br>#9  0x00000000005bded6 in udp_read_req (si=<optimized out>,<br></div><div><br></div><div><br></div><div>The code at line 1552 in siptrace.c that should handle this doesn't seem to be triggered:</div><div><br></div><div>        if(parse_headers(msg, HDR_CALLID_F, 0)!=0)<br>        {<br>                LM_ERR("cannot parse call-id\n");<br>                goto error;<br>        }</div><div><br></div><div>Resulting in a bad pointer dereference and segfault here at line 1563:</div><div>        db_vals[1].val.str_val.s = msg->callid->body.s;<br></div><div><br></div><div><br></div><div>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</div><div><br></div><div>--- orig/opensips-2.2.7/modules/siptrace/siptrace.c 2018-05-24 16:33:57.000000000 +0000<br>+++ fixed/opensips-2.2.7/modules/siptrace/siptrace.c    2018-10-15 19:17:39.020664338 +0000<br>@@ -1549,7 +1549,9 @@<br>                goto error;<br>        }<br><br>-       if(parse_headers(msg, HDR_CALLID_F, 0)!=0)<br>+       if(msg->callid==NULL && ((parse_headers(msg, HDR_CALLID_F, 0)==-1) ||<br>+                                (msg->callid==NULL)) )<br>+<br>        {<br>                LM_ERR("cannot parse call-id\n");<br>                goto error;</div><div><br></div><div>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.<br></div><div><br></div><div>- Jon Abrams<br></div><br></div></div></div></div></div></div></div></div>