[asterisk-dev] res_fax_spandsp segfaults during fax detection

[Pavel Troller]

Hello Hans,

> On 2014-01-28 12:21, Pavel Troller wrote:
> snip
>>> Later on, an ast_frdup most likely pulled the frame off of the rtp
>>> engine and re-malloc'd it; however, this is code that happens all the
>>> time and wouldn't have perturbed the datalen. Your problem is most
>>> likely coming from whatever RTP packet was sent to Asterisk. You may
>>> want to look at a pcap of the message traffic that caused the problem
>>> to determine what about the packet is causing the issue.
>>>
>>> It may be necessary for something either in res_rtp_asterisk or
>>> res_fax_spandsp to verify that the number of samples in the RTP packet
>>> (or what the voice frame has in it before it gets handed off) matches
>>> what is expected.
>> Hi Matthew,
>>    thanks for another part of the mosaic, it seems to be more and more
>> complete and starts forming a picture :-).
>>    Would it be possible, that the peer causing the segfault uses 10ms
>> packetization time instead of 20ms, which is required for correct operation
>> by libspandsp ? What does Asterisk in cases, when the peer allows 10ms
>> packetization only, while we are using 20ms ? Will it do a conversion,
>> catching two packets and presenting them as one bigger, or will it just
>> forward the short packets to the application ? If the second answer is
>> correct (which I belive is true), I think we have a candidate case for the
>> crash - it's caused by someone who sends 10ms packets instead of 20ms ones.
>> But I don't know the details of the RTP engine, whether it will even allow
>> the connection in such a case, or whether it will be handled similarly as
>> failure to find a common codec. In such a case, I can imagine a scenario,
>> that the peer is offering 20ms packetization, but actually sends packets
>> in 10ms one, thus fooling the RTP engine and causing exactly this problem.
>>    So, yes, the pcap of such a failure would be really great! As I wrote,
>> I can't generate one, because in my environment, the crash is really VERY
>> rare and the pcap files would probably fill the whole disk and didn't catch
>> anything :-). Maybe Michal will have more luck with this ?
>>
>> With regards,
>>    Pavel
>
> Hello,
>
> I do have a pcap. Shall I attach it to:
>
> https://issues.asterisk.org/jira/browse/ASTERISK-20149
>
> although the title is a little bit misleading.
>
> I thought the issue was gone after applying the latest fixes for res_fax_spandsp and res_fax,
> but the impire stroke back ....
>
  I think that any information related to this crash may be useful. I looked
at some pcaps, which are already there, and I can't find an issue with data
length, all the RTP packets from the peer have the same length (180 bytes inc.
RTP hdr), but there's supicious, that the crash occurs immediately after
a packet with RTP Marker bit set, and also around answer (200 Ok -> ACK) being
signaled on the SIP channel. I can't find any visible relation of these two
events and the crahs, but the pcap looks so :-). So, let's look into another
one, maybe it will be more explaining.

Regards, Pavel

> regards
>
> Hans