<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p>Hello,</p>
    <p>it is already backported to branch 4.4 -- I said that you can use
      latest 4.4 branch from git -- backporting was only if you want to
      still use 4.4.1 snapshot + this patch.</p>
    <p>Therefore next release in 4.4 series will have it as well.<br>
    </p>
    <p>Cheers,<br>
      Daniel<br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 28/03/2017 13:42, David Escartín
      Almudévar wrote:<br>
    </div>
    <blockquote cite="mid:1490701343.2904.8.camel@bts.io" type="cite">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <meta name="GENERATOR" content="GtkHTML/4.8.4">
      hello Daniel<br>
      <br>
      thanks a lot.<br>
      we actually will start testing 5.0 to migrate to it, but in the
      meantime it's great if we can patch it on the 4.4<br>
      <br>
      best regards<br>
      david<br>
      <br>
      <br>
      El mar, 28-03-2017 a las 13:37 +0200, Daniel-Constantin Mierla
      escribió:<br>
      <blockquote type="CITE"> Hello,<br>
        <br>
        I pushed a safety checks to avoid crash in this situation. I
        will have to investigate deeper why it got to this state, but
        for now the fix should avoid this crash in a similar situation.
        You have to use the latest branch 4.4 or backport the patch
        e20b38e0084c1f89c43a921a8a2affbea060aaa5 to your version.<br>
        <br>
        Cheers,<br>
        Daniel<br>
        <br>
        <br>
        <br>
      </blockquote>
      <blockquote type="CITE"> On 28/03/2017 12:15, David Escartín
        Almudévar wrote:<br>
        <br>
      </blockquote>
      <blockquote type="CITE">
        <blockquote type="CITE"> hello Daniel<br>
          <br>
          it happened only once as far as i know, i tried to duplicate
          by myself but i couldnt create the sipp scenario<br>
          i will try to duplicate it setting the octal parameters in hex
          escaped by % in the SIP uris to see if i can, but i didnt have
          time yet<br>
          <br>
          in the meantime here you have the information <br>
          <br>
          (gdb) frame 6<br>
          #6  0x00000000004696c4 in dns_srv_sip_resolvehost
          (name=0x7f6906943188, port=0x7fff120795e2,
          proto=0x7fff120795e1 "\001\330\023") at dns_cache.c:2679<br>
          2679 he=dns_get_he(name, dns_flags);<br>
          (gdb) p *name<br>
          $1 = {s = 0x0, len = 0}<br>
          (gdb) p *port<br>
          $2 = 5080<br>
          <br>
          thanks a lot and regards<br>
          david<br>
          <br>
          <br>
          <br>
          El lun, 27-03-2017 a las 21:04 +0200, Daniel-Constantin Mierla
          escribió:<br>
          <blockquote type="CITE"> Hello,<br>
            <br>
            did it happen only once, or it can be reproduced?<br>
            <br>
            Can you also get from gdb:<br>
            <br>
            frame 6<br>
            <br>
            p *name<br>
            <br>
            p *port<br>
            <br>
            <br>
            Cheers,<br>
            Daniel<br>
            <br>
            <br>
            <br>
            On 27/03/2017 16:43, David Escartín Almudévar wrote:<br>
            <br>
            <blockquote type="CITE"> hello Daniel<br>
              <br>
              here you have<br>
              <br>
              (gdb) frame 1<br>
              #1  0x000000000045b472 in _dns_hash_find
              (name=0x7f6906943188, type=1, h=0x7fff120793cc,
              err=0x7fff120793ac) at dns_cache.c:535<br>
              535 *h=dns_hash_no(name->s, name->len, type);<br>
              (gdb) info locals<br>
              e = 0x7f69069015b8<br>
              tmp = 0x7f69069247e0<br>
              ret = 0x0<br>
              now = 689922868<br>
              cname_chain = 0<br>
              cname = {s = 0xab0e93 "Via: SIP/2.0/UDP
              \020?\337\v\234\262\264\016
              :5080;received=;rport=5080;branch=\020?\337\v\234\262\264\016
              \r\nContent-Length: 0\r\n\r\n", len = 11210375}<br>
              __FUNCTION__ = "_dns_hash_find"<br>
              (gdb) list<br>
              530 cname_chain=0;<br>
              531 ret=0;<br>
              532 now=get_ticks_raw();<br>
              533 *err=0;<br>
              534 again:<br>
              535 *h=dns_hash_no(name->s, name->len, type);<br>
              536 #ifdef DNS_CACHE_DEBUG<br>
              537 LM_DBG("(%.*s(%d), %d), h=%d\n", name->len,
              name->s, name->len, type, *h);<br>
              538 #endif<br>
              539 clist_foreach_safe(&dns_hash[*h], e, tmp, next){<br>
              <br>
              <br>
              <br>
              thanks a lot and regards<br>
              david<br>
              <br>
              <br>
              <br>
              <br>
              El lun, 27-03-2017 a las 13:54 +0200, Daniel-Constantin
              Mierla escribió:<br>
              <blockquote type="CITE"> Hello,<br>
                <br>
                the backtrace is no longer matching the 4.4 branch code,
                as you run an older release in that series.<br>
                <br>
                Can you get with gdb from the core the output of the
                following commands:<br>
                <br>
                frame 1<br>
                <br>
                info locals<br>
                <br>
                list<br>
                <br>
                <br>
                and send them here on the mailing list.<br>
                <br>
                Cheers,<br>
                Daniel<br>
                <br>
                On 24/03/2017 14:50, David Escartín Almudévar wrote:<br>
                <br>
                <blockquote type="CITE"> hello all, Daniel<br>
                  <br>
                  checking the core with the gdb, we have checked the
                  variables at the frames of the backtrace, to try to
                  get the full sip message seems it seemed truncated.<br>
                  checking the buf variable of the frame 11 which
                  theorically contains the sip msg to parse we have the
                  string<br>
                  <br>
                  <br>
                  SIP/2.0 487 Request Terminated\r\nFrom:
                  \"881237046977\"<<a moz-do-not-send="true"
                    href="sip:881237046977@79.170.68.185">sip:881237046977@79.170.68.185</a>;user=phone>;tag=B7jgc8jQ4m5pB\r\nTo:
                  <<a moz-do-not-send="true"
                    href="sip:5926053324@79.170.68.186:5060">sip:5926053324@79.170.68.186:5060</a>>;tag=e0d50be-13c4-58d47cba-a2ed9808-36fa\r\nl\337K\016\213\347:
                  \344\003\r\nCSeq: 104824272 INVITE\r\nVia: SIP/2.0/UDP
                  L\263\264\016\020?\337\v\234\262\264\016
                  ;branch=\327\f\340\r\nVia: SIP/2.0/UDP
                  \020?\337\v\234\262\264\016
                  :5080;received=;rport=5080;branch=\020?\337\v\234\262\264\016
                  \r\nContent-Length: 0\r\n\r\n<br>
                  <br>
                  this is i guess how gdb parses the message, so i guess
                  i cannot introduce this like that in a xml sipp
                  formal, since CRLF is represented as \r\n, so others
                  parts like l\337K\016\213\347: \344\003 i have no idea
                  what they are, because they also seem to be out of the
                  ASCII table ¿?<br>
                  anycase, seems the message is very bad formed, and the
                  kamailio tries to resolve the host of the Via and it
                  gets nothing, so the function get_hash1_case_raw is
                  fed by a nul value and seems that the reason it
                  crashes<br>
                  <br>
                  hope you can retrieve information from that message to
                  find out what kind of message it exactly is and see if
                  it's possible to avoid kamailio's crash in this
                  scenario<br>
                  <br>
                  <br>
                  best regards<br>
                  david<br>
                  <br>
                  <br>
                  <br>
                  El vie, 24-03-2017 a las 12:10 +0100, David Escartín
                  Almudévar escribió:<br>
                  <blockquote type="CITE"> hello all <br>
                    <br>
                    we have experienced a crash and tracing the logs and
                    the core, seems it was because a sip response from
                    an endpoint.<br>
                    a UDP receiver (26248) crashed and the last message
                    we see on it is a 487 quite bad formed<br>
                    <br>
                    Mar 24 01:58:02 mia-proxy-inout-1-stby
                    /usr/local/kamailio/sbin/kamailio[26248]: ERROR: tm
                    [t_lookup.c:1055]: t_check_msg(): ERROR: reply
                    doesn't have a via, cseq or call-id header<br>
                    Mar 24 01:58:17 mia-proxy-inout-1-stby
                    /usr/local/kamailio/sbin/kamailio[26230]: ALERT:
                    <core> [main.c:739]: handle_sigs(): child
                    process 26248 exited by a signal 11<br>
                    <br>
                    <br>
                    the backtrace of the core<br>
                    (gdb) backtrace<br>
                    #0  0x0000000000457ab9 in get_hash1_case_raw (s=0x0,
                    len=0) at hashes.h:210<br>
                    #1  0x000000000045b472 in _dns_hash_find
                    (name=0x7f6906943188, type=1, h=0x7fff120793cc,
                    err=0x7fff120793ac) at dns_cache.c:535<br>
                    #2  0x0000000000461285 in dns_hash_get
                    (name=0x7f6906943188, type=1, h=0x7fff120793cc,
                    err=0x7fff120793ac) at dns_cache.c:762<br>
                    #3  0x0000000000467194 in dns_get_entry
                    (name=0x7f6906943188, type=1) at dns_cache.c:2102<br>
                    #4  0x0000000000468a05 in dns_a_get_he
                    (name=0x7f6906943188) at dns_cache.c:2432<br>
                    #5  0x0000000000468bb9 in dns_get_he
                    (name=0x7f6906943188, flags=1) at dns_cache.c:2505<br>
                    #6  0x00000000004696c4 in dns_srv_sip_resolvehost
                    (name=0x7f6906943188, port=0x7fff120795e2,
                    proto=0x7fff120795e1 "\001\330\023") at
                    dns_cache.c:2679<br>
                    #7  0x000000000046aa37 in dns_sip_resolvehost
                    (name=0x7f6906943188, port=0x7fff120795e2,
                    proto=0x7fff120795e1 "\001\330\023") at
                    dns_cache.c:2849<br>
                    #8  0x000000000049519e in
                    update_sock_struct_from_via (to=0x7fff12079708,
                    msg=0x7f69069a1dd8, via=0x7f69068f82a8) at
                    forward.c:704<br>
                    #9  0x0000000000495ee5 in do_forward_reply
                    (msg=0x7f69069a1dd8, mode=0) at forward.c:766<br>
                    #10 0x00000000004970af in forward_reply
                    (msg=0x7f69069a1dd8) at forward.c:849<br>
                    #11 0x00000000005197ef in receive_msg (<br>
                        buf=0xab0d80 "SIP/2.0 487 Request
                    Terminated\r\nFrom: \"8888888888\"<a
                      moz-do-not-send="true"
                      href="sip:8888888888@7.7.7.7;user=phone"><sip:8888888888@7.7.7.7;user=phone></a>;tag=B7jgc8jQ4m5pB\r\nTo:
                    <a moz-do-not-send="true"
                      href="sip:555555555@8.8.8.8:5060"><sip:555555555@8.8.8.8:5060></a>;tag=e0d50be-13c4-58d47cba-a2ed9808-36fa\r\nl\337K\016"...,
                    len=367, rcv_info=0x7fff12079a10) at receive.c:299<br>
                    #12 0x0000000000627b43 in udp_rcv_loop () at
                    udp_server.c:495<br>
                    #13 0x00000000004b107a in main_loop () at
                    main.c:1600<br>
                    #14 0x00000000004b842f in main (argc=13,
                    argv=0x7fff12079fb8) at main.c:2616<br>
                    <br>
                    <br>
                    i have tried to duplicate the issue, but i dont know
                    how to translate l\337K\016 to a xml notation<br>
                    i guess this is some weird that cannot be processed
                    for kamailio<br>
                    <br>
                    could you please take a look and let me know if you
                    know how to duplicate and fix this crash?<br>
                    <br>
                    thanks a lot and regards<br>
                    david<br>
                  </blockquote>
                  <br>
                  <br>
                  <br>
                  <pre>_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
<a moz-do-not-send="true" href="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</a>
<a moz-do-not-send="true" href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a>
</pre>
                </blockquote>
                <br>
                <pre>-- 
Daniel-Constantin Mierla
<a moz-do-not-send="true" href="http://www.twitter.com/miconda">www.twitter.com/miconda</a> -- <a moz-do-not-send="true" href="http://www.linkedin.com/in/miconda">www.linkedin.com/in/miconda</a>
Kamailio Advanced Training - Mar 6-8 (Europe) and Mar 20-22 (USA) - <a moz-do-not-send="true" href="http://www.asipto.com">www.asipto.com</a>
Kamailio World Conference - May 8-10, 2017 - <a moz-do-not-send="true" href="http://www.kamailioworld.com">www.kamailioworld.com</a>
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
<a moz-do-not-send="true" href="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</a>
<a moz-do-not-send="true" href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a>
</pre>
              </blockquote>
              <br>
            </blockquote>
            <br>
            <pre>-- 
Daniel-Constantin Mierla
<a moz-do-not-send="true" href="http://www.twitter.com/miconda">www.twitter.com/miconda</a> -- <a moz-do-not-send="true" href="http://www.linkedin.com/in/miconda">www.linkedin.com/in/miconda</a>
Kamailio Advanced Training - Mar 6-8 (Europe) and Mar 20-22 (USA) - <a moz-do-not-send="true" href="http://www.asipto.com">www.asipto.com</a>
Kamailio World Conference - May 8-10, 2017 - <a moz-do-not-send="true" href="http://www.kamailioworld.com">www.kamailioworld.com</a>
</pre>
          </blockquote>
          <br>
        </blockquote>
        <br>
        <pre>-- 
Daniel-Constantin Mierla
<a moz-do-not-send="true" href="http://www.twitter.com/miconda">www.twitter.com/miconda</a> -- <a moz-do-not-send="true" href="http://www.linkedin.com/in/miconda">www.linkedin.com/in/miconda</a>
Kamailio Advanced Training - May 22-24 (USA) - <a moz-do-not-send="true" href="http://www.asipto.com">www.asipto.com</a>
Kamailio World Conference - May 8-10, 2017 - <a moz-do-not-send="true" href="http://www.kamailioworld.com">www.kamailioworld.com</a>
</pre>
      </blockquote>
      <br>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Daniel-Constantin Mierla
<a class="moz-txt-link-abbreviated" href="http://www.twitter.com/miconda">www.twitter.com/miconda</a> -- <a class="moz-txt-link-abbreviated" href="http://www.linkedin.com/in/miconda">www.linkedin.com/in/miconda</a>
Kamailio Advanced Training - May 22-24 (USA) - <a class="moz-txt-link-abbreviated" href="http://www.asipto.com">www.asipto.com</a>
Kamailio World Conference - May 8-10, 2017 - <a class="moz-txt-link-abbreviated" href="http://www.kamailioworld.com">www.kamailioworld.com</a></pre>
  </body>
</html>