[SR-Users] kamailio 4.4.1 crash on bad sip response
Daniel-Constantin Mierla
miconda at gmail.com
Tue Mar 28 13:44:36 CEST 2017
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 at 79.170.68.185;user=phone>;tag=B7jgc8jQ4m5pB\r\nTo:
>>>>>>> <sip:5926053324 at 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 at 7.7.7.7;user=phone>
>>>>>>>> <sip:8888888888 at 7.7.7.7;user=phone>;tag=B7jgc8jQ4m5pB\r\nTo:
>>>>>>>> <sip:555555555 at 8.8.8.8:5060>
>>>>>>>> <sip:555555555 at 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 at lists.sip-router.org <mailto:sr-users at 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 at lists.sip-router.org <mailto:sr-users at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20170328/79bdc706/attachment.html>
More information about the sr-users
mailing list