[Home]

Summary:ASTERISK-15371: Segfault while setting up T.38 fax reception
Reporter:Ben Klang (bklang)Labels:
Date Opened:2009-12-26 16:00:32.000-0600Date Closed:2010-02-02 16:33:01.000-0600
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/T.38
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) maddison-console-bt.txt
Description:I have been experimenting with T.38 fax reception via SIP.  This results in an immediate crash.  While I am able to capture a coredump, for whatever reason GDB and MDB do not appear to be able to give me a usable backtrace.  However, Asterisk logs these message immediately before crashing:

[Dec 26 21:06:25]     -- Executing [fax@standard-fax:2] ReceiveFAX("SIP/broadriver-00000000", "/var/spool/fax/1261861580.0.fax,debug") in new stack
[Dec 26 21:06:25] NOTICE[23097]: channel.c:2933 __ast_read: Dropping incompatible voice frame on SIP/broadriver-00000000 of format slin since our native format has changed to 0x4 (ulaw)
grant*CLI> [Dec 26 21:06:25] WARNING[23097]: udptl.c:766 calculate_far_max_ifp: (no tag): Cannot calculate far_max_ifp before far_max_datagram has been set.
[Dec 26 21:06:25] WARNING[23097]: udptl.c:766 calculate_far_max_ifp: (no tag): Cannot calculate far_max_ifp before far_max_datagram has been set.

Next I tried forcing the max datagram in sip.conf like this:

[general]
t38pt_udptl=yes,maxdatagram=400

However, Asterisk still crashes with the same message.

Out of curiosity, I modified main/udptl.c at line 764 in the function calculate_far_max_ifp() to force the far_max_datagram to 400:

udptl->far_max_datagram = 400;

Doing this prevents Asterisk from segfaulting.

I wish I could share a backtrace, but so far I can't produce anything useful.  I am willing to post the entire core dump if that would be helpful.
Comments:By: Leif Madsen (lmadsen) 2010-01-04 11:40:46.000-0600

The core file is only useful on the machine it was run on. Perhaps you can provide the backtrace of what you have, and maybe a developer will find something useful in it?

Otherwise, it is possible this is a memory corruption issue, in which case valgrind output is what will be needed to move this forward.

I think seeing the sip trace and console output just prior to the crash may be useful as well.

By: Ben Klang (bklang) 2010-01-08 08:46:32.000-0600

At the next opportunity I will get a sip trace and console output.  The gdb backtrace is just thousands of lines of nulls (mdb won't even give a backtrace), so I don't think it's useful at all.  I'll include a paste from the next crash I generate just in case.

One other possible clue has shown up during debugging:  compiling with DONT_OPTIMIZE seems to prevent the crash.  So now there are two workaround: force the far_max_datagram or compile with DONT_OPTIMIZE.

By: Matt Addison (maddison) 2010-01-13 12:16:07.000-0600

1.6.2.0 w/ SpanDSP 0.0.5 seeing this also, sorry didn't grab a SIP trace but I do have console output and GDB backtrace (will attach).

Issue goes away after setting DONT_OPTIMIZE, but it could be related to an issue I'm still seeing on this setup (getting a 503 from my switch after the originating party sends a 488 in response to the switch trying to direct reINVITE us together).

Platform is x86 Debian 5.0.3



By: Grigoriy Puzankin (boroda) 2010-01-21 05:20:50.000-0600

I have the same issue.

Cisco 1751 <==SIP/T.38==> Asterisk-1.6.2.0 <==SIP/T.38==> Nortel IPLDK-60

gdb shows the same output

By: Ben Klang (bklang) 2010-01-21 18:56:22.000-0600

To the other commenters that have observed the same crash: do you have ignoresdpversion set on this peer?  I do and I wonder if it might be related.  I'm hoping to do some test late tonight with ignoresdpversion turned off, but I have other issues that prevent me from running with that configuration.

By: Matt Addison (maddison) 2010-01-21 21:37:22.000-0600

Not running ignoredspversion (unless it's the default, and it doesn't sound like a default).

By: Grigoriy Puzankin (boroda) 2010-01-25 01:51:41.000-0600

ignoredspversion is on for both sides. I don't remember what was wrong without it with Cisco and Nortel, but I had to turn it on.

By: David Vossel (dvossel) 2010-01-25 11:20:47.000-0600

Sorry I had to mark this private.  This is a security concern we are already aware of.  A patch has already been made to resolve this and a new security release is in the works.  We're hoping to get it out later this week.

By: Digium Subversion (svnbot) 2010-02-02 16:27:26.000-0600

Repository: asterisk
Revision: 244443

U   trunk/channels/chan_sip.c
U   trunk/include/asterisk/udptl.h
U   trunk/main/udptl.c

------------------------------------------------------------------------
r244443 | dvossel | 2010-02-02 16:27:24 -0600 (Tue, 02 Feb 2010) | 18 lines

fixes crash during T.38 negotiation caused by invalid or missing FaxMaxDatagram field

AST-2010-001

(closes issue ASTERISK-15457)
Reported by: krn

(closes issue ASTERISK-15538)
Reported by: barthpbx

(closes issue ASTERISK-15371)
Reported by: bklang

(closes issue ASTERISK-15343)
Reported by: elsto



------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=244443

By: Digium Subversion (svnbot) 2010-02-02 16:29:41.000-0600

Repository: asterisk
Revision: 244445

_U  branches/1.6.2/
U   branches/1.6.2/channels/chan_sip.c
U   branches/1.6.2/include/asterisk/udptl.h
U   branches/1.6.2/main/udptl.c

------------------------------------------------------------------------
r244445 | dvossel | 2010-02-02 16:29:38 -0600 (Tue, 02 Feb 2010) | 23 lines

Merged revisions 244443 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

........
 r244443 | dvossel | 2010-02-02 16:27:23 -0600 (Tue, 02 Feb 2010) | 18 lines
 
 fixes crash during T.38 negotiation caused by invalid or missing FaxMaxDatagram field
 
 AST-2010-001
 
 (closes issue ASTERISK-15457)
 Reported by: krn
 
 (closes issue ASTERISK-15538)
 Reported by: barthpbx
 
 (closes issue ASTERISK-15371)
 Reported by: bklang
 
 (closes issue ASTERISK-15343)
 Reported by: elsto
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=244445

By: Digium Subversion (svnbot) 2010-02-02 16:31:33.000-0600

Repository: asterisk
Revision: 244446

_U  branches/1.6.1/
U   branches/1.6.1/channels/chan_sip.c
U   branches/1.6.1/include/asterisk/udptl.h
U   branches/1.6.1/main/udptl.c

------------------------------------------------------------------------
r244446 | dvossel | 2010-02-02 16:31:30 -0600 (Tue, 02 Feb 2010) | 23 lines

Merged revisions 244443 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

........
 r244443 | dvossel | 2010-02-02 16:27:23 -0600 (Tue, 02 Feb 2010) | 18 lines
 
 fixes crash during T.38 negotiation caused by invalid or missing FaxMaxDatagram field
 
 AST-2010-001
 
 (closes issue ASTERISK-15457)
 Reported by: krn
 
 (closes issue ASTERISK-15538)
 Reported by: barthpbx
 
 (closes issue ASTERISK-15371)
 Reported by: bklang
 
 (closes issue ASTERISK-15343)
 Reported by: elsto
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=244446

By: Digium Subversion (svnbot) 2010-02-02 16:33:00.000-0600

Repository: asterisk
Revision: 244447

_U  branches/1.6.0/
U   branches/1.6.0/channels/chan_sip.c
U   branches/1.6.0/include/asterisk/udptl.h
U   branches/1.6.0/main/udptl.c

------------------------------------------------------------------------
r244447 | dvossel | 2010-02-02 16:32:56 -0600 (Tue, 02 Feb 2010) | 23 lines

Merged revisions 244443 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

........
 r244443 | dvossel | 2010-02-02 16:27:23 -0600 (Tue, 02 Feb 2010) | 18 lines
 
 fixes crash during T.38 negotiation caused by invalid or missing FaxMaxDatagram field
 
 AST-2010-001
 
 (closes issue ASTERISK-15457)
 Reported by: krn
 
 (closes issue ASTERISK-15538)
 Reported by: barthpbx
 
 (closes issue ASTERISK-15371)
 Reported by: bklang
 
 (closes issue ASTERISK-15343)
 Reported by: elsto
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=244447