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 -- 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
