[SR-Users] kamailio 4.4.1 crash on bad sip response
Daniel-Constantin Mierla
miconda at gmail.com
Mon Mar 27 21:04:07 CEST 2017
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 -- www.linkedin.com/in/miconda
Kamailio Advanced Training - Mar 6-8 (Europe) and Mar 20-22 (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/20170327/4c43a014/attachment.html>
More information about the sr-users
mailing list