Due to the recursion used when compiling AEL in gen_prios, all the stack space
was being consumed when parsing some AEL that contained nesting 13 levels deep.
Changing a few large buffers to be heap allocated fixed the crash, although I
did not test how many more levels can now be safely used.
(closes issue #16053)
Reported by: diLLec
Tested by: jpeeler
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@271399 65c4cc65-6c06-0410-ace0-fbb531ad65f3
(This is a backport of 269307, committed to trunk by rmudgett.)
Calling dahdi_indicate() when the channel private lock is already
held can cause a deadlock if the PRI lock is needed because
dahdi_indicate() will also get the channel private lock. The pri_grab()
function assumes that the channel private lock is held once to avoid
deadlock.
(closes issue #17261)
Reported by: aragon
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@271335 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There is code in chan_iax2.c that attempts to guarantee that only a single
active thread will handle a call number at a time. This code works once
the thread is added to an active_list of threads, but we are not currently
guaranteed that a newly activated thread will enter the active_list immediately
because it is left up to the thread to add itself after frames have been
queued to it. This means that if two frames come in for the same call number
at the same time, it is possible for them to grab two separate threads because
the first thread did not add itself to the active_list fast enough. This
causes some pretty complex problems.
This patch resolves this race condition by immediately adding an activated
thread to the active_list within the network thread and only depending on
the thread to remove itself once it is done processing the frames queued to
it. By doing this we are guaranteed that if another frame for the same call
number comes in at the same time, that this thread will immediately be found
in the active_list of threads.
Review: https://reviewboard.asterisk.org/r/720/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@270866 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r270658 | twilson | 2010-06-15 15:18:04 -0500 (Tue, 15 Jun 2010) | 20 lines
Make contactdeny apply to src ip when nat=yes
chan_sip's "contactdeny" feature screens the "to be registered contact".
In case of nat=yes it should not use the address information from the
Contact header (which is not used at all for routing), but the source
IP address of the request.
Thus, if nat=yes and a client sends a request from a denied IP address
(e.g. by spoofing the src-IP address) it can bypass the screening.
This commit makes contactdeny apply to the src ip when nat=yes instead.
(closes issue #17276)
Reported by: klaus3000
Patches:
patch-asterisk-trunk-contactdeny.txt uploaded by klaus3000 (license 65)
Tested by: klaus3000
Review: [full review board URL with trailing slash]
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@270724 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The issue here was that the frame created when adjusting for PLC had no offset
to its audio data. If this frame were translated to another format prior to
being sent out an RTP socket, all went well because the translation code would
put an appropriate offset into the frame. However, if the SLIN audio were not
translated before being sent out the RTP socket, bad things would happen.
Specifically, the ast_rtp_raw_write makes the assumption that the frame has
at least enough of an offset that it can accommodate an RTP header. This was
not the case. As such, data was being written prior to the allocation, likely
corrupting the data the memory allocator had written. Thus when the time came
to free the data, all hell broke loose. ....Well, Asterisk crashed at least.
The fix was just what one would expect. Offset the data in the frame by a reasonable
amount. The method I used is a bit odd since the data in the frame is 16 bit integers
and not bytes. I left a big ol' comment about it. This can be improved on if someone
is interested. I was more interested in getting the crash resolved.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@269821 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This eliminates the annoying <beep> on the console.
(closes issue #17477)
Reported by: jvandal
Patches:
20100610__issue17477.diff.txt uploaded by tilghman (license 14)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@269635 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When using the init script as-is currently, it could cause issues on Debian
such as high CPU usage. This fix has worked for several people so I'm
implementing the change. We now handle color displays properly.
(closes issue #16784)
Reported by: pabelanger
Patches:
20100530__issue16784__2.diff.txt uploaded by tilghman (license 14)
Tested by: pabelanger, tilghman
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@269334 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Since we are just checking for table existence, add a WHERE clause that will
return no rows but will raise an error if the table doesn't exist.
(closes issue #17380)
Reported by: kkwong
Patches:
issue17380-01.patch uploaded by seanbright (license 71)
Tested by: kkwong
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@269006 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Uses the VT100 method of clearing the line from the cursor position to the
end of the line: Esc-0K
(closes issue #17160)
Reported by: coolmig
Patches:
20100531__issue17160.diff.txt uploaded by tilghman (license 14)
Tested by: coolmig
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@266585 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a T.38 re-INVITE failed with an 488 or 606 answer, we should
fallback to audio fax by send a re-re-INVITE without T.38. The
function is backported from 1.6 asterisk.
(closes issue #16795)
Reported by: vrban
(closes issue #16692)
Reported by: vrban
Patches:
t38_fallback_to_audio_v3.patch uploaded by vrban (license 756)
Tested by: lmadsen, vrban, haggard
https://reviewboard.asterisk.org/r/514/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@266579 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If you call signal() in a Solaris signal handler, instead of just resetting
the signal handler, it causes the signal to refire, because the signal is not
marked as handled prior to the signal handler being called. This effectively
causes Solaris to immediately exceed the threadstack in recursive signal
handlers and crash.
(closes issue #17000)
Reported by: rmcgilvr
Patches:
20100526__issue17000.diff.txt uploaded by tilghman (license 14)
Tested by: rmcgilvr
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@266142 65c4cc65-6c06-0410-ace0-fbb531ad65f3
At times, the "Member" field was not specified during the event.
It's there now.
(closes issue #15638)
Reported by: elbriga
Patches:
patchAppQueueAgentComplete.diff uploaded by elbriga (license 482)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@266004 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r265320 | twilson | 2010-05-24 14:06:40 -0500 (Mon, 24 May 2010) | 14 lines
Add the FullyBooted AMI event
It is possible to connect to the manager interface before all Asterisk modules
are loaded. To ensure that an application does not send AMI actions that might
require a module that has not yet loaded, the application can listen for the
FullyBooted manager event. It will be sent upon connection if all modules have
been loaded, or as soon as loading is complete. The event:
Event: FullyBooted
Privilege: system,all
Status: Fully Booted
Review: https://reviewboard.asterisk.org/r/639/
........
r265467 | twilson | 2010-05-24 17:21:58 -0500 (Mon, 24 May 2010) | 1 line
Merge the rest of the FullyBooted patch
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@265570 65c4cc65-6c06-0410-ace0-fbb531ad65f3