Simply establishing a TCP connection and never sending anything to the
configured HTTP port in http.conf will tie up a HTTP connection. Since
there is a maximum number of open HTTP sessions allowed at a time you can
block legitimate connections.
A similar problem exists if a HTTP request is started but never finished.
* Added http.conf session_inactivity timer option to close HTTP
connections that aren't doing anything. Defaults to 30000 ms.
* Removed the undocumented manager.conf block-sockets option. It
interferes with TCP/TLS inactivity timeouts.
* AMI and SIP TLS connections now have better authentication timeout
protection. Though I didn't remove the bizzare TLS timeout polling code
from chan_sip.
* chan_sip can now handle SSL certificate renegotiations in the middle of
a session. It couldn't do that before because the socket was non-blocking
and the SSL calls were not restarted as documented by the OpenSSL
documentation.
* Fixed an off nominal leak of the ssl struct in
handle_tcptls_connection() if the FILE stream failed to open and the SSL
certificate negotiations failed.
The patch creates a custom FILE stream handler to give the created FILE
streams inactivity timeout and timeout after a specific moment in time
capability. This approach eliminates the need for code using the FILE
stream to be redesigned to deal with the timeouts.
This patch indirectly fixes most of ASTERISK-18345 by fixing the usage of
the SSL_read/SSL_write operations.
ASTERISK-23673 #close
Reported by: Richard Mudgett
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@415841 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When overlap dialing is enabled, the lack of inband audio available
information in the SETUP_ACKNOWLEDGE events causes an interoperability
problem with SIP. sig_pri doesn't know if there is dialtone present when
a SETUP_ACKNOWLEDGE is received so it assumes it is there and posts an
AST_CONTROL_PROGRESS frame. The SIP channel driver then sends out a 183
Session Progress and blocks the desired 180 Ringing message when the
ALERTING message comes in.
* Made the configure script detect if the installed version of libpri
supports the SETUP_ACKNOWLEDGE enhancements.
* Using the new API, made generate an AST_CONTROL_PROGRESS frame on an
incoming SETUP_ACKNOWLEDGE message when the message indicates inband audio
is present instead of assuming that dialtone is present.
* Using the new API, made SETUP_ACKNOWLEDGE send out an inband audio
available indication only if dialtone is expected. The change also makes
the fallback behaviour of sending the PROGRESS message better by sending
it only if dialtone is expected.
* Changed receiving a PROCEEDING message to not generate an
AST_CONTROL_PROGRESS frame if the progress indication ie indicates
non-end-to-end-ISDN. This helps interoperability with SIP.
* Changed sending a PROCEEDING message in response to an
AST_CONTROL_PROCEEDING frame to not indicate inband audio available. It
was silly to do so anyway because the channel driver doesn't know if
inband audio is even available. This helps interoperability with SIP.
This patch and a corresponding change in libpri work together to allow
Asterisk to control the inband audio available progress indication ie on
the SETUP_ACKNOWLEDGE message when dialtone is present.
AST-1338 #close
Reported by: Tyler Stewart
Review: https://reviewboard.asterisk.org/r/3521/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@413714 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This resolves a large number of compiler warnings from GCC 4.10 which
cause the build to fail under dev mode. The vast majority are
signed/unsigned mismatches in printf-style format strings.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@413586 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch does the following:
(1) It makes REF_DEBUG a meneselect item. Enabling REF_DEBUG now enables
REF_DEBUG globally throughout Asterisk.
(2) The ref debug log file is now created in the AST_LOG_DIR directory.
Every run will now blow away the previous run (as large ref files
sometimes caused issues). We now also no longer open/close the file
on each write, instead relying on fflush to make sure data gets written
to the file (in case the ao2 call being performed is about to cause a
crash)
(3) It goes with a comma delineated format for the ref debug file. This
makes parsing much easier. This also now includes the thread ID of the
thread that caused ref change.
(4) A new python script instead for refcounting has been added in the
contrib/scripts folder.
Review: https://reviewboard.asterisk.org/r/3377/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@412114 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The masquerade supertest frequently fails because either the local channel
chain doesn't completely optimize out or the DTMF handshake doesn't
completely get accross. Local channel optimization requires frames
flowing to trigger when optimization can happen. When optimization
happens the media frame that triggered the optimization is dropped.
Sending DTMF requires frames to flow in the other direction for timing
purposes while sending nothing. If internal timing is not enabled when
MOH is playing, Asterisk switches to received timing when an audio frame
is received. With optimization dropping media frames and MOH not sending
frames unless it receives frames, occasionaly there are no more frames
being passed and the test fails.
* The asterisk command line -I option and the asterisk.conf
internal_timing option are removed. Asterisk now always uses internal
timing when needed if any timing module is loaded. The issue
ASTERISK-14861 did this quite awhile ago in v1.4 but effectively is broken
if other internal timing modules besides DAHDI are used. The
ast_read_generator_actions() now only does received timing if it has no
choice for frame generators like MOH, silence, and playback streaming.
* Cleaned up some code dealing with frame generators in
ast_deactivate_generator(), generator_write_format_change(),
ast_activate_generator(), and ast_channel_stop_silence_generator().
ASTERISK-22846 #close
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3414/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@411715 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes setting nullable integer columns to NULL instead of an empty
string, which fails for PostgreSQL, for example. The current code is supposed
to do so, but the check is broken. The patch also allows the first column in
the list to be a nullable integer.
This patch also adds a compatibility setting in res_odbc.conf,
allow_empty_string_in_nontext. It is enabled by default. It should be disabled
for database backends (such as PostgreSQL) that require NULL instead of an
empty string for Integer columns.
Review: https://reviewboard.asterisk.org/r/3375
(issue ASTERISK-23459)
Reported by: zvision
patches:
res_config_odbc.diff uploaded by zvision (License 5755)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@411399 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When nanosecond time resolution was added for identifying config file
changes, it didn't cover all of the myriad of ways that one might obtain
nanosecond time resolution off of struct stat.
Rather than complicate the #if even further figuring out one system from
the next, this patch directly tests for the three struct members I know
about today, and #ifdef's accordingly.
Review: https://reviewboard.asterisk.org/r/3273/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@409833 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When two RTP channels are in a remote bridge, the remote bridging loop in
rtp_engine will periodically check to see if the two channels can still be
bridged. One of the many things it checks is whether or not the codecs have
changed on the channel. If the codec has changed, it will break out of the
loop to re-determine which type of bridge is appropriate.
In order to perform this check, the ast_rtp_glue virtual table's get_codec
callback is called for each channel. The callback implementations assume
that the channel tech private is valid when called; as such, there has
always been some code in place to check whether or not the channel pvt is
NULL before calling. However, this check is insufficient.
The channels are unlocked during the remote bridging loop. It is possible
for a channel to get masqueraded between the check for the pvt being NULL and
the actual call to get_codec. When this occurs, the callback is called with a
ZOMBIE channel, which now has a NULL pvt. Crash.
While this has always been possible in Asterisk 1.8, it is much more likely to
occur in Asterisk 11 and later versions due to the timing changes that occur
when getting the codec from a channel. Note that this is much more likely to be
reproduced on slow, boggy hardware running Asterisk 11 - but fairly rarely
otherwise.
Also Note: This crash was also caught by the various SIP blind transfer tests,
in addition to the bug report Alec filed.
Review: https://reviewboard.asterisk.org/r/3247/
(closes issue ASTERISK-21737)
Reported by: Alec Davis
Tested by: Alec Davis
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@409001 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Establishing an IAX2 call between Asterisk v1.4 and v1.8 (or later)
results in an unexpected call disconnect. The problem happens because
newer values in the enum ast_control_frame_type are not consistent between
the branch versions of Asterisk.
For example:
1) v1.4 calls v1.8 (or later) using IAX2
2) v1.8 answers and sends a connected line update control frame. (on v1.8
AST_CONTROL_CONNECTED_LINE = 22)
3) v1.4 receives the control frame as an end-of-q (on v1.4
AST_CONTROL_END_OF_Q = 22)
4) v1.4 disconnects the call once the receive queue becomes empty.
Several things are done by this patch to fix the problem and attempt to
prevent it from happening again in the future:
* Added a warning at the definition of enum ast_control_frame_type about
how to add new control frame values.
* Made block sending and receiving control frames that have no reason to
go over the wire.
* Extended the connectedline iax.conf parameter to also include the
redirecting information updates.
* Updated the connectedline iax.conf parameter documentation to include a
notice that the parameter must be "no" when the peer is an Asterisk v1.4
instance.
(closes issue AST-1302)
Review: https://reviewboard.asterisk.org/r/3174/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@407678 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk's RADIUS module currently build against libradiusclient-ng, but this
project has been superseeded by libfreeradius-client. The API is 99% compatible
except that the header name has changed, the library name has changed, and
the configuration file location has changed.
(closes issue ASTERISK-22980)
Reported by: Jeremy Lainé
Patches:
freeradius-client.patch uploaded by sharky (license 6561)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@406801 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The ast_filestream object gets tacked on to a channel via
chan->timingdata. It's a reference counted object, but the reference
count isn't used when putting it on a channel. It's theoretically
possible for another thread to interfere with the channel while it's
unlocked and cause the filestream to get destroyed.
Use the astobj2 reference count to make sure that as long as this code
path is holding on the ast_filestream and passing it into the file.c
playback code, that it knows it's valid.
Bug reported by Leif Madsen.
Review: https://reviewboard.asterisk.org/r/3135/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@406566 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch allows individual dialplan functions to be marked as
'dangerous', to inhibit their execution from external sources.
A 'dangerous' function is one which results in a privilege escalation.
For example, if one were to read the channel variable SHELL(rm -rf /)
Bad Things(TM) could happen; even if the external source has only read
permissions.
Execution from external sources may be enabled by setting
'live_dangerously' to 'yes' in the [options] section of asterisk.conf.
Although doing so is not recommended.
(closes issue ASTERISK-22905)
Review: http://reviewboard.digium.internal/r/432/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@403913 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In function ast_rtp_instance_early _bridge_make_compatible the
use of instance 0/1 as arguments doesn't clearly communicate a
direction that the copying of payloads from the source channel
to the destination channel will occur, making it more probable
to have the arguments to ast_rtp_codecs_payloads_copy() put in
the reverse order. This patch renames the arguments with _dst
and _src suffixes and corrects the copy direction.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@402000 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This fixes a bug where a zero length callerid match adjacent to a no
match callerid extension entry would be deleted together, which then
resulted in hashtable references to free'd memory. A third state of
the matchcid value has been added to indicate match to any extension
which allows enforcing comparison of matchcid on/off without errors.
(closes issue AST-1235)
Reported by: Guenther Kelleter
Review: https://reviewboard.asterisk.org/r/2930/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@401959 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes some long-standing bugs in debug threads that were
exacerbated with recent Optional API work in Asterisk 12.
With debug threads enabled, on some systems, there's a lock ordering
problem between our mutex and glibc's mutex protecting its module list
(Ubuntu Lucid, glibc 2.11.1 in this instance). In one thread, the module
list will be locked before acquiring our mutex. In another thread, our
mutex will be locked before locking the module list (which happens in
the depths of calling backtrace()).
This patch fixes this issue by moving backtrace() calls outside of
critical sections that have the mutex acquired. The bigger change was to
reentrancy tracking for ast_cond_{timed,}wait, which wrongly assumed
that waiting on the mutex was equivalent to a single unlock (it actually
suspends all recursive locks on the mutex).
(closes issue ASTERISK-22455)
Review: https://reviewboard.asterisk.org/r/2824/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@398648 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Review https://reviewboard.asterisk.org/r/2580/ tried to fix the mismatch
in memory pools but had a math error determining the buffer size and
didn't address other similar memory pool mismatches.
* Effectively reverted the previous patch to go in the same direction as
trunk for the returned memory pool of ast_bt_get_symbols().
* Fixed memory leak in ast_bt_get_symbols() when BETTER_BACKTRACES is
defined.
* Fixed some formatting in ast_bt_get_symbols().
* Fixed sig_pri.c freeing memory allocated by libpri when MALLOC_DEBUG is
enabled.
* Fixed __dump_backtrace() freeing memory from ast_bt_get_symbols() when
MALLOC_DEBUG is enabled.
* Moved __dump_backtrace() because of compile issues with the utils
directory.
(closes issue ASTERISK-22221)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2778/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@397525 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If an endpoint fails to include the T38MaxBitRate attribute during negotiation,
Asterisk will negotiate a bit rate of 2400 instead of the ITU recommended
bit rate of 14400. This patch fixes this by making AST_T38_RATE_14400 the
'default' value of the enum by assigning it a value of 0, such that if an
endpoint fails to include the attribute, the default will be 14400.
Note that Walter Doekes included the nice comment in frame.h about why we are
purposefully assigning AST_T38_RATE_14400 a value of 0.
(closes issue ASTERISK-22275)
Reported by: Andreas Steinmetz
patches:
fax-fix.patch uploaded by anstein (License 6523)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@397256 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The SLA code within app_meetme was written before asotbj2 had been
merged into Asterisk. Worse, support for reloads did not exist at first
and was added later as a bolt-on feature. I knew at the time that
reloading was not safe at all while SLA was in use, so the reload would
be queued up to execute when the system was idle. Unfortunately, this
approach was still prone to errors beyond the fact that this was the
only place in Asterisk where configuration was not reloaded
instantly when requested.
This patch converts various SLA objects to be reference counted objects
using astobj2. This allows reloads to be processed while the system is
in use. The code ensures that the objects will not disappear while one
of the other threads is using them. However, they will be immediately
removed from the global trunk and station containers so no new calls
will use them if removed from configuration.
Review: https://reviewboard.asterisk.org/r/2581/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@393928 65c4cc65-6c06-0410-ace0-fbb531ad65f3
XML encoding in chan_sip is accomplished by naively building the XML
directly from strings. While this usually works, it fails to take into
account escaping the reserved characters in XML.
This patch adds an 'ast_xml_escape' function, which works similarly to
'ast_uri_encode'. This is used to properly escape the local_display
attribute in XML formatted NOTIFY messages.
Several things to note:
* The Right Thing(TM) to do would probably be to replace the
ast_build_string stuff with building an ast_xml_doc. That's a much
bigger change, and out of scope for the original ticket, so I
refrained myself.
* It is with great sadness that I wrote my own ast_xml_escape
function. There's one in libxml2, but it's knee-deep in
libxml2-ness, and not easily used to one-off escape a
string.
* I only escaped the string we know is causing problems
(local_display). At least some of the other strings are
URI-encoded, which should be XML safe. Rather than figuring out
what's safe and escaping what's not, it would be much cleaner to
simply build an ast_xml_doc for the messages and let the XML
library do the XML escaping. Like I said, that's out of scope.
(closes issue ABE-2902)
Reported by: Guenther Kelleter
Tested by: Guenther Kelleter
Review: http://reviewboard.digium.internal/r/365/
........
Merged revision 378919 from https://origsvn.digium.com/svn/asterisk/be/branches/C.3-bier
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@378933 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The AMI redirect action can fail to redirect two channels that are bridged
together. There is a race between the AMI thread redirecting the two
channels and the bridge thread noticing that a channel is hungup from the
redirects.
* Made the bridge wait for both channels to be redirected before exiting.
* Made the AMI redirect check that all required headers are present before
proceeding with the redirection.
* Made the AMI redirect require that any supplied ExtraChannel exist
before proceeding. Previously the code fell back to a single channel
redirect operation.
(closes issue ASTERISK-18975)
Reported by: Ben Klang
(closes issue ASTERISK-19948)
Reported by: Brent Dalgleish
Patches:
jira_asterisk_19948_v11.patch (license #5621) patch uploaded by rmudgett
Tested by: rmudgett, Thomas Sevestre, Deepak Lohani, Kayode
Review: https://reviewboard.asterisk.org/r/2243/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@378356 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk maintains an internal cache for devices in the event subsystem. The
device state cache holds the state of each device known to Asterisk, such that
consumers of device state information can query for the last known state for
a particular device, even if it is not part of an active call. The concept of
a device in Asterisk can include entities that do not have a physical
representation. One way that this occurred was when anonymous calls are allowed
in Asterisk. A device was automatically created and stored in the cache for
each anonymous call that occurred; this was possible in the SIP and IAX2
channel drivers and through channel drivers that utilized the
res_jabber/res_xmpp resource modules (Gtalk, Jingle, and Motif). These devices
are never removed from the system, allowing anonymous calls to potentially
exhaust a system's resources.
This patch changes the event cache subsystem and device state management to
no longer cache devices that are not associated with a physical entity.
(issue ASTERISK-20175)
Reported by: Russell Bryant, Leif Madsen, Joshua Colp
Tested by: kmoore
patches:
event-cachability-3.diff uploaded by jcolp (license 5000)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@378303 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The RTP engine public function that gets the available formats expects a
format_t to be returned; however when calling into an RTP instance's
callback to get the available formats, the callback returned an int.
This never was noticed in Asterisk because the two RTP engines included
do not provide an available_formats callback.
This introduces an API change, and the proposal for this change was brought
up on the Asterisk developers mailing list [1]. There was no public objection
to this change, so it is now being put in.
(closes AST-1054)
reported by Doug Bailey
[1] http://lists.digium.com/pipermail/asterisk-dev/2012-December/058058.html
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@378147 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Cleanup time zones on exit.
* Make exit clean/unclean report consistent for AMI and CLI in
really_quit().
(issue ASTERISK-20649)
Reported by: Corey Farrell
Patches:
core-cleanup-1_8-10.patch (license #5909) patch uploaded by Corey Farrell
core-cleanup-11-trunk.patch (license #5909) patch uploaded by Corey Farrell
Modified
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@377135 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Similar to the patch that moved the fork earlier in the startup sequence to
prevent mutex errors in the recursive mutex surrounding the read/write thread
registration lock, this patch re-initializes the logmsgs mutex. Part of the
start up sequence before forking the process into the background includes
reading asterisk.conf; this has to occur prior to the call to daemon in order
to read startup parameters. When reading in a conf file, log statements can
be generated. Since this can't be avoided, the mutex instead is
re-initialized to ensure a reset of any thread tracking information.
This patch also includes some additional debugging to catch errors when
locking or unlocking the recursive mutex that surrounds locks when the
DEBUG_THREADS build option is enabled. DO_CRASH or THREAD_CRASH will
cause an abort() if a mutex error is detected.
(issue ASTERISK-19463)
Reported by: mjordan
Tesetd by: mjordan
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@376586 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Both hashtest and hashtest2 are manual testing apps that thrash hash
tables (hashtab and ao2 containers, respectively), by spinning up
several threads that randomly insert, delete, lookup and iterate over
the hash table. If the app doesn't crash, the hash table probably passes
the test. Those utils are not a part of the typical Asterisk build, so
they do not usually get compiled. This all makes them less that useful.
This patch removes those manual test programs and replaces them with
Asterisk unit test modules (test_{hashtab,astobj2}_thrash.so). It also
attempts to make the tests more deterministic.
* Rather than spinning up some number of threads that operate on the
hash table randomly, spin up four threads that concurrenly add,
remove, lookup and iterate over the hash table.
* Each thread checks the state of the hash table both during and after
execution, and indicates a test failure if things are not as expected.
* Each thread times out after 60 seconds to prevent deadlocking the unit
test run.
(closes issue ASTERISK-20505)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2189/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@376306 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Makes malloc() behave like calloc(). It will return a memory block
filled with 0x55. A nonzero value.
* Makes free() fill the released memory block and boundary fence's with
0xdeaddead. Any pointer use after free is going to have a pointer
pointing to 0xdeaddead. The 0xdeaddead pointer is usually an invalid
memory address so a crash is expected.
* Puts the freed memory block into a circular array so it is not reused
immediately.
* When the circular array rotates out a memory block to the heap it checks
that the memory has not been altered from 0xdeaddead.
* Made the astmm_log message wording better.
* Made crash if the DO_CRASH menuselect option is enabled and something is
found.
* Fixed a potential alignment issue on 64 bit systems.
struct ast_region.data[] should now be aligned correctly for all
platforms.
* Extracted region_check_fences() from __ast_free_region() and
handle_memory_show().
* Updated handle_memory_show() CLI usage help.
Review: https://reviewboard.asterisk.org/r/2182/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@376029 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to this change, a common method for determining if a timeout
was reached was to call a function such as ast_waitfor_n() and inspect
the out parameter that told how many milliseconds were left, then use
that as the input to ast_waitfor_n() on the next go-around.
The problem with this is that in some cases, submillisecond timeouts
can occur, resulting in the out parameter not decreasing any. When this
happens thousands of times, the result is that the timeout takes much
longer than intended to be reached. As an example, I had a situation where
a 3 second timeout took multiple days to finally end since most wakeups
from ast_waitfor_n() were under a millisecond.
This patch seeks to fix this pattern throughout the code. Now we log the
time when an operation began and find the difference in wall clock time
between now and when the event started. This means that sub-millisecond timeouts
now cannot play havoc when trying to determine if something has timed out.
Part of this fix also includes changing the function ast_waitfor() so that it
is possible for it to return less than zero when a negative timeout is given
to it. This makes it actually possible to detect errors in ast_waitfor() when
there is no timeout.
(closes issue ASTERISK-20414)
reported by David M. Lee
Review: https://reviewboard.asterisk.org/r/2135/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@375993 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a bridge is broken by an AMI Redirect action or the ChannelRedirect
application, an in progress DTMF digit could be stuck sending forever.
* Made simulate a DTMF end event when a bridge is broken and a DTMF digit
was in progress.
(closes issue ASTERISK-20492)
Reported by: Jeremiah Gowdy
Patches:
bridge_end_dtmf-v3.patch.txt (license #6358) patch uploaded by Jeremiah Gowdy
Modified to jira_asterisk_20492_v1.8.patch
jira_asterisk_20492_v1.8.patch (license #5621) patch uploaded by rmudgett
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/2169/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@375964 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Currently, if an acknowledgement of a timer fails Asterisk will not realize
that a serious error occurred and will continue attempting to use the timer's
file descriptor. This can lead to situations where errors stream to the
CLI/log file. This consumes significant resources, masks the actual problem
that occurred (whatever caused the timer to fail in the first place), and
can leave channels in odd states.
This patch propagates the errors in the timing resource modules up through
the timer core, and makes users of these timers handle acknowledgement
failures. It also adds some defensive coding around the use of timers
to prevent using bad file descriptors in off nominal code paths.
Note that the patch created by the issue reporter was modified slightly for
this commit and backported to 1.8, as it was originally written for
Asterisk 10.
(issue ASTERISK-20032)
Reported by: Jeremiah Gowdy
patches:
jgowdy-timerfd-6-22-2012.diff uploaded by Jeremiah Gowdy (license 6358)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@375893 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Replace links to missing text files removed in the 1.6.x series with links to the wiki. Doxygen can handle URLs fine, don't atempt to quote them. Also update the wiki link in the Readme to get everyone on the same page.
(issue ASTERISK-20259)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@375698 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Passing an ast_str pointer by value that then calls
ast_str_set(), ast_str_set_va(), ast_str_append(), or
ast_str_append_va() can result in the pointer originally
passed by value being invalidated if the ast_str had
to be reallocated.
This fixes places in the code that do this. Only the
example in ccss.c could result in pointer invalidation
though since the other cases use a stack-allocated ast_str
and cannot be reallocated.
I've also updated the doxygen in strings.h to include
notes about potential misuse of the functions mentioned
previously.
Review: https://reviewboard.asterisk.org/r/2161
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@375025 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This is used to solve an issue where a poll on a file
descriptor does not necessarily correspond to the readiness
of a FILE handle to be read.
This change makes it so that for TCP connections, we do a
recv() on the file descriptor instead.
Because TCP does not guarantee that an entire message or even
just one single message will arrive during a read, a loop has
been introduced to ensure that we only attempt to handle a
single message at a time. The tcptls_session_instance structure
has also had an overflow buffer added to it so that if more
than one TCP message arrives in one go, there is a place to
throw the excess.
Huge thanks goes out to Walter Doekes for doing extensive review
on this change and finding edge cases where code could fail.
(closes issue ASTERISK-20212)
reported by Phil Ciccone
Review: https://reviewboard.asterisk.org/r/2123
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@374905 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Greenlight in #asterisk brought up that he was receiving an error message "Could
not create persistent member string, out of space" when running app_queue in
Asterisk 10. dump_queue_members() made an assumption that 8K would be enough to
store the generated string, but with queues that have large member lists this is
not always the case. This patch removes the limitation and uses ast_str instead
of a fixed sized buffer.
The complicating factor comes from the fact that ast_db_get requires a buffer
and buffer size argument, which doesn't let us pull back more than what we pass
in, so I introduced a new ast_db_get_allocated() which returns an ast_strdup()'d
copy of the value from astdb.
As an aside, I did some testing on the maximum size of data that we can store in
the BDB library we distribute and was able to store a 10MB string and retrieve
it with no problems, so I feel this is a safe patch.
Review: https://reviewboard.asterisk.org/r/2136/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@374108 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ast_waitfordigit_full would simply pass its timeout to ast_waitfor_nandfds,
expecting it to decrement the timeout by however many milliseconds were
waited. This is a problem if it consistently waits less than 1ms. The timeout
will never be decremented, and we wait... FOREVER!
This patch makes ast_waitfordigit_full manage the timeout itself. It maintains
the previously undocumented behavior that negative timeouts wait forever.
(closes issue ASTERISK-20375)
Reported by: Mark Michelson
Tested by: Mark Michelson
Review: https://reviewboard.asterisk.org/r/2109/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@373024 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When REF_DEBUG is enabled in certain files - most notably ccss.c - the 'tag'
parameter passed to __ao2_ref_debug will be a const char *. The function
currently expects that parameter to not be const. This causes a warning
when compiling, as the const qualifier is being discarded. With dev-mode
enabled, this prevents compiling Asterisk.
This patch makes __ao2_ref_debug's tag and file parameters const.
(closes issue ASTERISK-20408)
Reported by: mjordan
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@372959 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This replaces all calls to alloca() with ast_alloca() which calls gcc's
__builtin_alloca() to avoid BSD semantics and removes all NULL checks
on memory allocated via ast_alloca() and ast_strdupa().
(closes issue ASTERISK-20125)
Review: https://reviewboard.asterisk.org/r/2032/
Patch-by: Walter Doekes (wdoekes)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@370642 65c4cc65-6c06-0410-ace0-fbb531ad65f3
