[asterisk-bugs] [JIRA] (ASTERISK-20856) Segmentation fault in res_rtp_asterisk.so caused by NULL data pointer in frame from sig_analog

[Roberto Casas (JIRA)]

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

Roberto Casas commented on ASTERISK-20856:
------------------------------------------

The status right now:

*CLI> core show uptime 
System uptime: 1 week, 3 days, 21 hours, 17 minutes, 11 seconds 
Last reload: 1 week, 2 days, 23 hours, 26 minutes, 16 seconds 

It seems that the MTU change fixed it.

I'll try to explain the changes.

Asterisk server was connected to a network with a MTU of 1452 (value on the switches), and the network interface was configured to this value.

The client changed the telephony system to a new switch, configured with the default value of MTU, but Asterisk server was forced to 1452. SIP clients were configured to default MTU value.

So, the problem arrived when some packet from clients was fragmented, and the second packet produced a null frame. I think that it's not a problem related to DAHDI, because it was caused by network issues. My opinion is that it's a voice frame coming corrupted from a SIP channel.
                
> Segmentation fault in res_rtp_asterisk.so caused by NULL data pointer in frame from sig_analog
> ----------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-20856
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-20856
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_rtp_asterisk
>            Reporter: Roberto Casas
>            Assignee: Roberto Casas
>            Severity: Critical
>         Attachments: backtrace.txt, debug.log, messages.log
>
>
> I have this bug in Asterisk 1.8.3.1 but I've inspected trunk version and the code is almost the same.
> The bug is in the function:
> ast_rtp_raw_write
> When we have a remote_address, but frame->data.ptr should be 0 (because substracting hdrlen gives position 0xfffffffffffffff4 to the rtpheader variable)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira