hello Daniel
yes yes i understood.
thanks a lot david
El mar, 28-03-2017 a las 13:44 +0200, Daniel-Constantin Mierla escribió:
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;tag=B7jgc8jQ4m5pB\r\nTo: 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 > > 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 > _______________________________________________ > 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
-- 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
-- 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
-- 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