Hello, 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.
Therefore next release in 4.4 series will have it as well. Cheers, Daniel On 28/03/2017 13:42, David Escartín Almudévar wrote: > hello Daniel > > thanks a lot. > 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 > > best regards > david > > > El mar, 28-03-2017 a las 13:37 +0200, Daniel-Constantin Mierla escribió: >> Hello, >> >> 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. >> >> Cheers, >> Daniel >> >> >> >> On 28/03/2017 12:15, David Escartín Almudévar wrote: >> >>> hello Daniel >>> >>> it happened only once as far as i know, i tried to duplicate by >>> myself but i couldnt create the sipp scenario >>> 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 >>> >>> in the meantime here you have the information >>> >>> (gdb) frame 6 >>> #6 0x00000000004696c4 in dns_srv_sip_resolvehost >>> (name=0x7f6906943188, port=0x7fff120795e2, proto=0x7fff120795e1 >>> "\001\330\023") at dns_cache.c:2679 >>> 2679 he=dns_get_he(name, dns_flags); >>> (gdb) p *name >>> $1 = {s = 0x0, len = 0} >>> (gdb) p *port >>> $2 = 5080 >>> >>> thanks a lot and regards >>> david >>> >>> >>> >>> El lun, 27-03-2017 a las 21:04 +0200, Daniel-Constantin Mierla escribió: >>>> Hello, >>>> >>>> did it happen only once, or it can be reproduced? >>>> >>>> Can you also get from gdb: >>>> >>>> frame 6 >>>> >>>> p *name >>>> >>>> p *port >>>> >>>> >>>> Cheers, >>>> Daniel >>>> >>>> >>>> >>>> On 27/03/2017 16:43, David Escartín Almudévar wrote: >>>> >>>>> hello Daniel >>>>> >>>>> here you have >>>>> >>>>> (gdb) frame 1 >>>>> #1 0x000000000045b472 in _dns_hash_find (name=0x7f6906943188, >>>>> type=1, h=0x7fff120793cc, err=0x7fff120793ac) at dns_cache.c:535 >>>>> 535 *h=dns_hash_no(name->s, name->len, type); >>>>> (gdb) info locals >>>>> e = 0x7f69069015b8 >>>>> tmp = 0x7f69069247e0 >>>>> ret = 0x0 >>>>> now = 689922868 >>>>> cname_chain = 0 >>>>> 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} >>>>> __FUNCTION__ = "_dns_hash_find" >>>>> (gdb) list >>>>> 530 cname_chain=0; >>>>> 531 ret=0; >>>>> 532 now=get_ticks_raw(); >>>>> 533 *err=0; >>>>> 534 again: >>>>> 535 *h=dns_hash_no(name->s, name->len, type); >>>>> 536 #ifdef DNS_CACHE_DEBUG >>>>> 537 LM_DBG("(%.*s(%d), %d), h=%d\n", name->len, name->s, >>>>> name->len, type, *h); >>>>> 538 #endif >>>>> 539 clist_foreach_safe(&dns_hash[*h], e, tmp, next){ >>>>> >>>>> >>>>> >>>>> thanks a lot and regards >>>>> david >>>>> >>>>> >>>>> >>>>> >>>>> El lun, 27-03-2017 a las 13:54 +0200, Daniel-Constantin Mierla >>>>> escribió: >>>>>> Hello, >>>>>> >>>>>> the backtrace is no longer matching the 4.4 branch code, as you >>>>>> run an older release in that series. >>>>>> >>>>>> Can you get with gdb from the core the output of the following >>>>>> commands: >>>>>> >>>>>> frame 1 >>>>>> >>>>>> info locals >>>>>> >>>>>> list >>>>>> >>>>>> >>>>>> and send them here on the mailing list. >>>>>> >>>>>> Cheers, >>>>>> Daniel >>>>>> >>>>>> On 24/03/2017 14:50, David Escartín Almudévar wrote: >>>>>> >>>>>>> hello all, Daniel >>>>>>> >>>>>>> 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. >>>>>>> checking the buf variable of the frame 11 which theorically >>>>>>> contains the sip msg to parse we have the string >>>>>>> >>>>>>> >>>>>>> SIP/2.0 487 Request Terminated\r\nFrom: >>>>>>> \"881237046977\"<sip:881237046977@79.170.68.185;user=phone>;tag=B7jgc8jQ4m5pB\r\nTo: >>>>>>> <sip:5926053324@79.170.68.186:5060>;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 >>>>>>> >>>>>>> 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 ¿? >>>>>>> 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 >>>>>>> >>>>>>> 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 >>>>>>> >>>>>>> >>>>>>> best regards >>>>>>> david >>>>>>> >>>>>>> >>>>>>> >>>>>>> El vie, 24-03-2017 a las 12:10 +0100, David Escartín Almudévar >>>>>>> escribió: >>>>>>>> hello all >>>>>>>> >>>>>>>> we have experienced a crash and tracing the logs and the core, >>>>>>>> seems it was because a sip response from an endpoint. >>>>>>>> a UDP receiver (26248) crashed and the last message we see on >>>>>>>> it is a 487 quite bad formed >>>>>>>> >>>>>>>> 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 >>>>>>>> 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 >>>>>>>> >>>>>>>> >>>>>>>> the backtrace of the core >>>>>>>> (gdb) backtrace >>>>>>>> #0 0x0000000000457ab9 in get_hash1_case_raw (s=0x0, len=0) at >>>>>>>> hashes.h:210 >>>>>>>> #1 0x000000000045b472 in _dns_hash_find (name=0x7f6906943188, >>>>>>>> type=1, h=0x7fff120793cc, err=0x7fff120793ac) at dns_cache.c:535 >>>>>>>> #2 0x0000000000461285 in dns_hash_get (name=0x7f6906943188, >>>>>>>> type=1, h=0x7fff120793cc, err=0x7fff120793ac) at dns_cache.c:762 >>>>>>>> #3 0x0000000000467194 in dns_get_entry (name=0x7f6906943188, >>>>>>>> type=1) at dns_cache.c:2102 >>>>>>>> #4 0x0000000000468a05 in dns_a_get_he (name=0x7f6906943188) at >>>>>>>> dns_cache.c:2432 >>>>>>>> #5 0x0000000000468bb9 in dns_get_he (name=0x7f6906943188, >>>>>>>> flags=1) at dns_cache.c:2505 >>>>>>>> #6 0x00000000004696c4 in dns_srv_sip_resolvehost >>>>>>>> (name=0x7f6906943188, port=0x7fff120795e2, proto=0x7fff120795e1 >>>>>>>> "\001\330\023") at dns_cache.c:2679 >>>>>>>> #7 0x000000000046aa37 in dns_sip_resolvehost >>>>>>>> (name=0x7f6906943188, port=0x7fff120795e2, proto=0x7fff120795e1 >>>>>>>> "\001\330\023") at dns_cache.c:2849 >>>>>>>> #8 0x000000000049519e in update_sock_struct_from_via >>>>>>>> (to=0x7fff12079708, msg=0x7f69069a1dd8, via=0x7f69068f82a8) at >>>>>>>> forward.c:704 >>>>>>>> #9 0x0000000000495ee5 in do_forward_reply (msg=0x7f69069a1dd8, >>>>>>>> mode=0) at forward.c:766 >>>>>>>> #10 0x00000000004970af in forward_reply (msg=0x7f69069a1dd8) at >>>>>>>> forward.c:849 >>>>>>>> #11 0x00000000005197ef in receive_msg ( >>>>>>>> buf=0xab0d80 "SIP/2.0 487 Request Terminated\r\nFrom: >>>>>>>> \"8888888888\"<sip:8888888888@7.7.7.7;user=phone> >>>>>>>> <sip:8888888888@7.7.7.7;user=phone>;tag=B7jgc8jQ4m5pB\r\nTo: >>>>>>>> <sip:555555555@8.8.8.8:5060> >>>>>>>> <sip:555555555@8.8.8.8:5060>;tag=e0d50be-13c4-58d47cba-a2ed9808-36fa\r\nl\337K\016"..., >>>>>>>> len=367, rcv_info=0x7fff12079a10) at receive.c:299 >>>>>>>> #12 0x0000000000627b43 in udp_rcv_loop () at udp_server.c:495 >>>>>>>> #13 0x00000000004b107a in main_loop () at main.c:1600 >>>>>>>> #14 0x00000000004b842f in main (argc=13, argv=0x7fff12079fb8) >>>>>>>> at main.c:2616 >>>>>>>> >>>>>>>> >>>>>>>> i have tried to duplicate the issue, but i dont know how to >>>>>>>> translate l\337K\016 to a xml notation >>>>>>>> i guess this is some weird that cannot be processed for kamailio >>>>>>>> >>>>>>>> could you please take a look and let me know if you know how to >>>>>>>> duplicate and fix this crash? >>>>>>>> >>>>>>>> thanks a lot and regards >>>>>>>> david >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list >>>>>>> sr-users@lists.sip-router.org <mailto:sr-users@lists.sip-router.org> >>>>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >>>>>> >>>>>> -- >>>>>> Daniel-Constantin Mierla >>>>>> www.twitter.com/miconda <http://www.twitter.com/miconda> -- >>>>>> www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda> >>>>>> Kamailio Advanced Training - Mar 6-8 (Europe) and Mar 20-22 (USA) - >>>>>> www.asipto.com <http://www.asipto.com> >>>>>> Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com >>>>>> <http://www.kamailioworld.com> >>>>>> _______________________________________________ >>>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list >>>>>> sr-users@lists.sip-router.org <mailto:sr-users@lists.sip-router.org> >>>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >>>>> >>>> >>>> -- >>>> Daniel-Constantin Mierla >>>> www.twitter.com/miconda <http://www.twitter.com/miconda> -- >>>> www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda> >>>> Kamailio Advanced Training - Mar 6-8 (Europe) and Mar 20-22 (USA) - >>>> www.asipto.com <http://www.asipto.com> >>>> Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com >>>> <http://www.kamailioworld.com> >>> >> >> -- >> Daniel-Constantin Mierla >> www.twitter.com/miconda <http://www.twitter.com/miconda> -- >> www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda> >> Kamailio Advanced Training - May 22-24 (USA) - www.asipto.com >> <http://www.asipto.com> >> Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com >> <http://www.kamailioworld.com> > -- Daniel-Constantin Mierla www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - May 22-24 (USA) - www.asipto.com Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users