[prev in list] [next in list] [prev in thread] [next in thread]
List: asterisk-dev
Subject: Re: [asterisk-dev] res_fax_spandsp segfaults during fax detection - FIXED?
From: Jaco Kroon <jaco () uls ! co ! za>
Date: 2014-02-06 11:07:09
Message-ID: 52F36CDD.5060608 () uls ! co ! za
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Hi All,
Could this backtrace possibly be related?
#0 process_rx_data (t=0x7fae54c698a8, user_data=0x2, data_type=1,
field_type=<optimized out>, buf=0x7fae11c58cda "cng", len=0) at
t38_terminal.c:314
#1 0x00007fae11c22c7d in t38_core_rx_ifp_packet (s=0x7fae54c698a8,
buf=0x7fae54c8475b "\002", len=1, seq_no=<optimized out>) at t38_core.c:459
#2 0x00007fae50ea96c5 in generic_fax_exec
(chan=chan@entry=0x7fadc4548c18, details=details@entry=0x7fad50602c28,
reserved=reserved@entry=0x7fad50155478, token=<optimized out>) at
res_fax.c:1498
#3 0x00007fae50eaea9e in receivefax_exec (chan=0x7fadc4548c18,
data=<optimized out>) at res_fax.c:1932
#4 0x0000000000530fdd in pbx_exec (c=c@entry=0x7fadc4548c18,
app=app@entry=0x2ddca60, data=data@entry=0x7fad838b6cd0
"/tmp/morpheus-1391681512.850.tiff") at pbx.c:1622
#5 0x000000000053656f in pbx_extension_helper
(c=c@entry=0x7fadc4548c18, context=<optimized out>,
exten=exten@entry=0x7fadc4549ab8 "0123489251",
priority=priority@entry=6, label=label@entry=0x0,
callerid=callerid@entry=0x7fadc44757b0 "0126413300",
action=action@entry=E_SPAWN, found=found@entry=0x7fad838bad60,
combined_find_spawn=combined_find_spawn@entry=1, con=0x0) at pbx.c:4922
#6 0x00000000005404a4 in ast_spawn_extension (found=0x7fad838bad60,
callerid=0x7fadc44757b0 "0126413300", priority=6, exten=0x7fadc4549ab8
"0123489251", context=<optimized out>, c=0x7fadc4548c18,
combined_find_spawn=<optimized out>) at pbx.c:6038
#7 __ast_pbx_run (c=c@entry=0x7fadc4548c18, args=args@entry=0x0) at
pbx.c:6513
#8 0x0000000000541c0b in pbx_thread (data=data@entry=0x7fadc4548c18) at
pbx.c:6843
#9 0x0000000000587c5a in dummy_start (data=<optimized out>) at utils.c:1162
#10 0x00007fae530f2f3a in start_thread (arg=0x7fad838bb700) at
pthread_create.c:308
#11 0x00007fae54754dad in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:113
Had about 11 of those this morning on asterisk 11.7.0. Codec's that's
allowed on SIP though is g729 and gsm only, so no ulaw/alaw allowed.
Actually, just double checked, ulaw/alaw is (was now) allowed, so
someone is possibly trying to run in bypass mode, resulting in the t38
gateway instead of t38 pass through. I downgraded to 11.6.0 and hadn't
had a crash since but I opted to disable ulaw+alaw in any case, just to
be on the safer side.
Kind Regards,
Jaco Kroon
On 01/02/2014 06:49, Michal Rybárik wrote:
> Hello Pavel,
>
> On 01/31/2014 07:59 AM, Pavel Troller wrote:
>>> This code will translate non-slinear frames to slinear, just before
>>> they
>>> are sent to libspandsp for v21detection. With this patch applied, v21
>>> detection is done also for RTP (SIP) alaw/ulaw frames, so maybe
>>> SIP/G711
>>> <-> SIP/T38 gateway will work too. I tested DAHDI<-> SIP/T38, gateway
>>> works both ways, voice calls too. Is it better now? :o)
>> I fully understand the code, but I'm not trained enough in the Asterisk
>> internals to respond to questions, which immediately appeared in my
>> head:
>> 1) In the original code, the result from fax_gateway_detect_v21() is
>> returned.
>> Now, you are returning the original frame. I quickly looked at the above
>> routine and it in turn calls fax_gateway_request_t38() and returns its
>> result (but not always), and in the fax_gateway_request_t38() function
>> they are also returning different things according to results of the
>> program flow. So, is it really safe to do this ? Are you sure, that the
>> real result is really unneccessary ?
>> 2) Are you sure, that ast_translate() will always allocate a new
>> buffer for
>> tmpframe ? Is it written somewhere ? Isn't it possible that it will just
>> reallocate the buffer for the original frame to increase its size and
>> return
>> its pointer, so by doing ast_frfree() you would just deallocate the same
>> buffer, thus making big troubles ? You would find it by checking that
>> tmpframe != f...
>> As you can see, I'm very careful, or maybe even a bit
>> conservative, with
>> patching things, unless I really DEEPLY understand, how they are
>> going...
>> So, I believe, that you really studied the code enough to be sure, that
>> you can really clear my doubts by your deep knowledge... I didn't
>> have time
>> to study the code to such extent...
>
> Answering these questions is not easy for me too, there are some parts
> of res_fax code which I don't fully understand. So I rather reworked
> the patch and moved it to another place, where functionality is easier
> to understand, and when it shouldn't harm anything. I uploaded diff to
> JIRA - https://issues.asterisk.org/jira/browse/ASTERISK-20149
>
> Regards,
> Michal Rybarik
>
[Attachment #5 (multipart/related)]
[Attachment #7 (text/html)]
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix"><font face="Helvetica, Arial,
sans-serif">Hi All,<br>
<br>
Could this backtrace possibly be related?<br>
<br>
#0 process_rx_data (t=0x7fae54c698a8, user_data=0x2,
data_type=1, field_type=<optimized out>,
buf=0x7fae11c58cda "cng", len=0) at t38_terminal.c:314<br>
#1 0x00007fae11c22c7d in t38_core_rx_ifp_packet
(s=0x7fae54c698a8, buf=0x7fae54c8475b "\002", len=1,
seq_no=<optimized out>) at t38_core.c:459<br>
#2 0x00007fae50ea96c5 in generic_fax_exec
(chan=chan@entry=0x7fadc4548c18,
details=details@entry=0x7fad50602c28,
reserved=reserved@entry=0x7fad50155478, token=<optimized
out>) at res_fax.c:1498<br>
#3 0x00007fae50eaea9e in receivefax_exec (chan=0x7fadc4548c18,
data=<optimized out>) at res_fax.c:1932<br>
#4 0x0000000000530fdd in pbx_exec (c=c@entry=0x7fadc4548c18,
app=app@entry=0x2ddca60, data=data@entry=0x7fad838b6cd0
"/tmp/morpheus-1391681512.850.tiff") at pbx.c:1622<br>
#5 0x000000000053656f in pbx_extension_helper
(c=c@entry=0x7fadc4548c18, context=<optimized out>,
exten=exten@entry=0x7fadc4549ab8 "0123489251",
priority=priority@entry=6, label=label@entry=0x0,
callerid=callerid@entry=0x7fadc44757b0 "0126413300",
action=action@entry=E_SPAWN, found=found@entry=0x7fad838bad60, <br>
combined_find_spawn=combined_find_spawn@entry=1, con=0x0) at
pbx.c:4922<br>
#6 0x00000000005404a4 in ast_spawn_extension
(found=0x7fad838bad60, callerid=0x7fadc44757b0 "0126413300",
priority=6, exten=0x7fadc4549ab8 "0123489251",
context=<optimized out>, c=0x7fadc4548c18,
combined_find_spawn=<optimized out>) at pbx.c:6038<br>
#7 __ast_pbx_run (c=c@entry=0x7fadc4548c18,
args=args@entry=0x0) at pbx.c:6513<br>
#8 0x0000000000541c0b in pbx_thread
(data=data@entry=0x7fadc4548c18) at pbx.c:6843<br>
#9 0x0000000000587c5a in dummy_start (data=<optimized
out>) at utils.c:1162<br>
#10 0x00007fae530f2f3a in start_thread (arg=0x7fad838bb700) at
pthread_create.c:308<br>
#11 0x00007fae54754dad in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:113<br>
<br>
Had about 11 of those this morning on asterisk 11.7.0. Codec's
that's allowed on SIP though is g729 and gsm only, so no
ulaw/alaw allowed. Actually, just double checked, ulaw/alaw is
(was now) allowed, so someone is possibly trying to run in
bypass mode, resulting in the t38 gateway instead of t38 pass
through. I downgraded to 11.6.0 and hadn't had a crash since
but I opted to disable ulaw+alaw in any case, just to be on the
safer side.<br>
<br>
</font>
<div class="moz-signature">Kind Regards,<br>
Jaco Kroon<br>
<img src="cid:part1.08050707.02040205@uls.co.za" usemap="#Map"
style="color:white" border="0" width="530" height="100">
<map name="Map" id="Map">
<area shape="rect" coords="441,19,460,36"
href="https://www.facebook.com/ultimatelinuxsolutions">
<area shape="rect" coords="441,39,458,57"
href="http://news.uls.co.za/">
<area shape="rect" coords="354,62,461,73"
href="http://www.uls.co.za/">
</map>
</div>
On 01/02/2014 06:49, Michal Rybárik wrote:<br>
</div>
<blockquote cite="mid:52EC7CE6.7000208@rybarik.sk" type="cite">Hello
Pavel,
<br>
<br>
On 01/31/2014 07:59 AM, Pavel Troller wrote:
<br>
<blockquote type="cite">
<blockquote type="cite">This code will translate non-slinear
frames to slinear, just before they
<br>
are sent to libspandsp for v21detection. With this patch
applied, v21
<br>
detection is done also for RTP (SIP) alaw/ulaw frames, so
maybe SIP/G711
<br>
<-> SIP/T38 gateway will work too. I tested
DAHDI<-> SIP/T38, gateway
<br>
works both ways, voice calls too. Is it better now? :o)
<br>
</blockquote>
I fully understand the code, but I'm not trained enough in the
Asterisk
<br>
internals to respond to questions, which immediately appeared in
my head:
<br>
1) In the original code, the result from
fax_gateway_detect_v21() is returned.
<br>
Now, you are returning the original frame. I quickly looked at
the above
<br>
routine and it in turn calls fax_gateway_request_t38() and
returns its
<br>
result (but not always), and in the fax_gateway_request_t38()
function
<br>
they are also returning different things according to results of
the
<br>
program flow. So, is it really safe to do this ? Are you sure,
that the
<br>
real result is really unneccessary ?
<br>
2) Are you sure, that ast_translate() will always allocate a new
buffer for
<br>
tmpframe ? Is it written somewhere ? Isn't it possible that it
will just
<br>
reallocate the buffer for the original frame to increase its
size and return
<br>
its pointer, so by doing ast_frfree() you would just deallocate
the same
<br>
buffer, thus making big troubles ? You would find it by checking
that
<br>
tmpframe != f...
<br>
As you can see, I'm very careful, or maybe even a bit
conservative, with
<br>
patching things, unless I really DEEPLY understand, how they are
going...
<br>
So, I believe, that you really studied the code enough to be
sure, that
<br>
you can really clear my doubts by your deep knowledge... I
didn't have time
<br>
to study the code to such extent...
<br>
</blockquote>
<br>
Answering these questions is not easy for me too, there are some
parts of res_fax code which I don't fully understand. So I rather
reworked the patch and moved it to another place, where
functionality is easier to understand, and when it shouldn't harm
anything. I uploaded diff to JIRA -
https://issues.asterisk.org/jira/browse/ASTERISK-20149
<br>
<br>
Regards,
<br>
Michal Rybarik
<br>
<br>
</blockquote>
<br>
</body>
</html>
[".eml_jaco.png" (image/png)]
["jaco.vcf" (text/x-vcard)]
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic