[asterisk-bugs] [JIRA] (ASTERISK-26738) frequent segfaults since activation of DNS SRV

Rusty Newton (JIRA) noreply at issues.asterisk.org
Mon Jan 23 08:50:10 CST 2017


    [ https://issues.asterisk.org/jira/browse/ASTERISK-26738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=234786#comment-234786 ] 

Rusty Newton edited comment on ASTERISK-26738 at 1/23/17 8:49 AM:
------------------------------------------------------------------

This backtrace now contains at the end the relevant debug output. Hope this helps (it's rather small but there wasn't any more at the relevant time). The machine was completely idle at the time of the crash. This is true for each provided trace here.

As usual, the REGISTER packet was sent out a second time for the same trunk after just 0.000731s. The unauthorized answer can be seen only in tcpdump 0.09s after the second REGISTER package - asterisk already crashed at the arrival time of the answer package or it wasn't written to file anymore. It is unauthorized because asterisk switched target address from 217.0.23.108 to 23.140. 
That's the answer package as seen by tcpdump:
{noformat}
SIP/2.0 401 Unauthorized 010350348
Via: SIP/2.0/UDP 46.91.112.37:5061;received=46.91.112.37;rport=5061;branch=z9hG4bKPj8258aae8-02a1-49a2-a356-a44706ed6eee
To: <sip:+4911112222222 at tel.t-online.de>;tag=h7g4Esbg_d2bfd3770a30b062f0c6cd3f8fb450c4
From: <sip:+4911112222222 at tel.t-online.de>;tag=2a385a16-37d3-4c03-89a9-0387642326ce
Call-ID: 41fb9b70-43f1-42c0-8588-605a4b2bff2e
CSeq: 59123 REGISTER
Service-Route: <sip:217.0.23.140:5060;transport=udp;lr>
WWW-Authenticate: Digest realm="tel.t-online.de",nonce="B9CC18C96B43535800000000614B2493",stale=true,algorithm=MD5,qop="auth"
Content-Length: 0
{noformat}
I could see a few OPTIONS packages sent to 23.140 long before and one more REGISTER to 23.140 since the last asterisk restart at 5:19 today. I don't think this is intended behavior. OPTIONS should always go to the same target as the REGISTER.

Error message in /var/log/messages was:
kernel: traps: asterisk[24916] general protection ip:7fdfdf93d4b2 sp:7fdf9052f5f0 error:0 in libasteriskpj.so.2[7fdfdf8a0000+16d000]

The machine is a multihomed machine (3 physical interfaces, 1 tap device, one bridge and one ppp0 device). ppp0 and eth0 both have IPv6 global addresses, too.



was (Author: micha):
This backtrace now contains at the end the relevant debug output. Hope this helps (it's rather small but there wasn't any more at the relevant time). The machine was completely idle at the time of the crash. This is true for each provided trace here.

As usual, the REGISTER packet was sent out a second time for the same trunk after just 0.000731s. The unauthorized answer can be seen only in tcpdump 0.09s after the second REGISTER package - asterisk already crashed at the arrival time of the answer package or it wasn't written to file anymore. It is unauthorized because asterisk switched target address from 217.0.23.108 to 23.140. 
That's the answer package as seen by tcpdump:

SIP/2.0 401 Unauthorized 010350348
Via: SIP/2.0/UDP 46.91.112.37:5061;received=46.91.112.37;rport=5061;branch=z9hG4bKPj8258aae8-02a1-49a2-a356-a44706ed6eee
To: <sip:+4911112222222 at tel.t-online.de>;tag=h7g4Esbg_d2bfd3770a30b062f0c6cd3f8fb450c4
From: <sip:+4911112222222 at tel.t-online.de>;tag=2a385a16-37d3-4c03-89a9-0387642326ce
Call-ID: 41fb9b70-43f1-42c0-8588-605a4b2bff2e
CSeq: 59123 REGISTER
Service-Route: <sip:217.0.23.140:5060;transport=udp;lr>
WWW-Authenticate: Digest realm="tel.t-online.de",nonce="B9CC18C96B43535800000000614B2493",stale=true,algorithm=MD5,qop="auth"
Content-Length: 0

I could see a few OPTIONS packages sent to 23.140 long before and one more REGISTER to 23.140 since the last asterisk restart at 5:19 today. I don't think this is intended behavior. OPTIONS should always go to the same target as the REGISTER.

Error message in /var/log/messages was:
kernel: traps: asterisk[24916] general protection ip:7fdfdf93d4b2 sp:7fdf9052f5f0 error:0 in libasteriskpj.so.2[7fdfdf8a0000+16d000]

The machine is a multihomed machine (3 physical interfaces, 1 tap device, one bridge and one ppp0 device). ppp0 and eth0 both have IPv6 global addresses, too.


> frequent segfaults since activation of DNS SRV
> ----------------------------------------------
>
>                 Key: ASTERISK-26738
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26738
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_pjsip
>    Affects Versions: 13.13.1
>         Environment: Centos 6 64bit
> FreePBX 13.0.190.7
> IPv4 and IPv6
> dual core processor
>            Reporter: Michael Maier
>            Assignee: Unassigned
>            Severity: Critical
>         Attachments: backtrace-2017-01-20T21.21.25.txt, backtrace-2017-01-20T23.21.00+0100.txt, backtrace-2017-01-21T05.19.00+0100.txt, backtrace-2017-01-21T12.43.36+0100.txt
>
>
> After switching to DNS SRV w/ 5 parallel trunks I'm getting frequent segfaults like the attached one. Backtrace is built on base of patched Schmooze RPM source package:
> - Patch to get libasteriskpj.so.2 symbols
> - Patch from ASTERISK-26675 (segfault has been seen already w/o this patch - but it doesn't obviously fix this problem)
> Parallel running tcpdump shows, that REGISTER is sent at the time of the crash.
> In detail:
> - The DNS SRV entry has two hostnames (see ASTERISK-26735). All the time before the crash, ipaddress 217.0.23.108 is used for REGISTER.
> - At the moment of the crash, 2(!!) REGISTERS are sent nearly at the same time (0.01s difference) for the same trunk! The first to 217.0.23.140(!), the second to the usual 217.0.23.108. The answer from 217.0.23.108 comes first (200 ok), the answer from 217.0.23.140 comes 0.09s later and is 401 unauthorized. That's the end. Now the crash appears.



--
This message was sent by Atlassian JIRA
(v6.2#6252)



More information about the asterisk-bugs mailing list