Russell Bryant [Thu, 8 May 2008 19:14:04 +0000 (19:14 +0000)]
Fix a race condition that bbryant just found while doing some IAX2 testing.
He was running Asterisk trunk running IAX2 calls through a few Asterisk boxes,
however, the audio was extremely choppy. We looked at a packet trace and saw
a storm of INVAL and VNAK frames being sent from one box to another.
It turned out that what had happened was that one box tried to send a CONTROL
frame before the 3 way handshake had completed. So, that frame did not include
the destination call number, because it didn't have it yet. Part of our recent
work for security issues included an additional check to ensure that frames that
are supposed to include the destination call number have the correct one. This
caused the frame to be rejected with an INVAL. The frame would get retransmitted
for forever, rejected every time ...
This race condition exists in all versions that got the security changes,
in theory. However, it is really only likely that this would cause a problem in
Asterisk trunk. There was a control frame being sent (SRCUPDATE) at the _very_
beginning of the call, which does not exist in 1.2 or 1.4. However, I am fixing
all versions that could potentially be affected by the introduced race condition.
These changes are what bbryant and I came up with to fix the issue. Instead of
simply dropping control frames that get sent before the handshake is complete,
the code attempts to wait a little while, since in most cases, the handshake
will complete very quickly. If it doesn't complete after yielding for a little
while, then the frame gets dropped.
Russell Bryant [Mon, 5 May 2008 17:53:26 +0000 (17:53 +0000)]
Merge changes from team/russell/iax2_find_callno_1.2
These changes address a critical performance issue introduced in the latest
release. The fix for the latest security issue included a change that made
Asterisk randomly choose call numbers to make them more difficult to guess by
attackers. However, due to some inefficient (this is by far, an understatement)
code, when Asterisk chose high call numbers, chan_iax2 became unusable after
just a small number of calls. On a small embedded platform, it would not be
able to handle a single call. On my Intel Core 2 Duo @ 2.33 GHz, I couldn't
run more than about 16 IAX2 channels. Ouch.
These changes address some performance issues of the find_callno() function
that have bothered me for a very long time. On every incoming media frame,
it iterated through every possible call number trying to find a matching
active call. This involved a mutex lock and unlock for each call number
checked. So, if the random call number chosen was 20000, then every media
frame would cause 20000 locks and unlocks. Previously, this problem was
not as obvious since Asterisk always chose the lowest call number it could.
A second container for IAX2 pvt structs has been added. It is an astobj2
hash table. When we know the remote side's call number, the pvt goes into
the hash table with a hash value of the remote side's call number. Then,
lookups for incoming media frames are a very fast hash lookup instead of an
absolutely insane array traversal.
In a quick test, I was able to get more than 3600% more IAX2 channels
on my machine with these changes.
Kevin P. Fleming [Wed, 26 Mar 2008 15:53:46 +0000 (15:53 +0000)]
due to licensing restrictions, we cannot distribute the source code for iLBC encoding and decoding... so remove it, and add instructions on how the user can obtain it themselves
Russell Bryant [Thu, 20 Mar 2008 21:53:27 +0000 (21:53 +0000)]
Fix some very broken code that was introduced in 1.2.26 as a part of the security
fix. The dnsmgr is not appropriate here. The dnsmgr takes a pointer to an address
structure that a background thread continuously updates. However, in these cases,
a stack variable was passed. That means that the dnsmgr thread would be continuously
writing to bogus memory.
Steve Murphy [Thu, 2 Aug 2007 17:56:37 +0000 (17:56 +0000)]
This patch hopefully solves 10141; The user is running with it, and it doesn't appear to harm asterisk's operation, and may prevent a crash. I'll store it in 1.2, as we have shut down support on 1.2, but since I developed the patch before support finished, and it might affect 1.4 and trunk, I'm going ahead with it.
(closes issue #5866)
Reported by: tyler
Do not force channel format changes when a generator is present. The generator may have changed the formats itself and changing them back would cause issues.
Russell Bryant [Sat, 21 Jul 2007 02:01:46 +0000 (02:01 +0000)]
Backport a fix for a memory leak that was fixed in trunk in reivision 76221
by rizzo. The memory used for the localaddr list was not freed during a
configuration reload.
(closes issue #10247)
Reported by: fkasumovic
Patches:
chan_sip.patch uploaded by fkasumovic (license #101)
Drop any peer realm authentication entries when reloading so multiple entries do not get added to the peer.
Russell Bryant [Thu, 19 Jul 2007 15:49:42 +0000 (15:49 +0000)]
When processing full frames, take sequence number wraparound into account when
deciding whether or not we need to request retransmissions by sending a VNAK.
This code could cause VNAKs to be sent erroneously in some cases, and to not
be sent in other cases when it should have been.
(closes issue #10237, reported and patched by mihai)
Russell Bryant [Wed, 18 Jul 2007 21:09:13 +0000 (21:09 +0000)]
When traversing the queue of frames for possible retransmission after
receiving a VNAK, handle sequence number wraparound so that all frames that
should be retransmitted actually do get retransmitted.
(issue #10227, reported and patched by mihai)
Russell Bryant [Tue, 17 Jul 2007 20:45:27 +0000 (20:45 +0000)]
Ensure that when encoding the contents of an ast_frame into an iax_frame, that
the size of the destination buffer is known in the iax_frame so that code
won't write past the end of the allocated buffer when sending outgoing frames.
(ASA-2007-014)
Russell Bryant [Tue, 17 Jul 2007 20:41:41 +0000 (20:41 +0000)]
After parsing information elements in IAX frames, set the data length to zero,
so that code later on does not think it has data to copy.
(ASA-2007-015)
Mark Michelson [Fri, 13 Jul 2007 20:10:39 +0000 (20:10 +0000)]
Fixed an issue where chanspy flags were uninitialized if no options were passed.
What triggered this investigation was an IRC chat where some people's quiet flags were
set while others' weren't even though none of them had specified the q option.
Russell Bryant [Fri, 13 Jul 2007 20:07:21 +0000 (20:07 +0000)]
Ensure that adding a user to the list of users of a specific music on hold
class is not done at the same time as any of the other operations on this list
to prevent list corruption. Using the global moh_data lock for this is not
ideal, but it is what is used to protect these lists everywhere else in the
module, and I am only changing what is necessary to fix the bug.
When using a TDM400P (and probably other analog cards) there was a chance that
you could hang up and pick the phone back up where it has been long enough to
be not considered a flash hook, but too soon such that the device reports that
it is busy and the person on the phone will only hear silence. This patch
makes chan_zap more tolerant of this and gives the device a couple of seconds
to succeed so the person on the phone happily gets their dialtone.
Russell Bryant [Wed, 11 Jul 2007 22:53:26 +0000 (22:53 +0000)]
The function make_trunk() can fail and return -1 instead of a valid new call
number. Fix the uses of this function to handle this instead of treating it
as the new call number. This would cause a deadlock and memory corruption.
(possible cause of issue #9614 and others, patch by me)
Russell Bryant [Wed, 11 Jul 2007 18:33:23 +0000 (18:33 +0000)]
Make sure that the ESCAPE immediately follows the condition that uses LIKE.
This fixes realtime extensions with ODBC.
(closes issue #10175, reported by stuarth, patch by me)
Jason Parker [Tue, 10 Jul 2007 19:57:20 +0000 (19:57 +0000)]
Fix an issue where it was possible to have a service level of over 100%
Between the time recalc_holdtime and update_queue was called, it was possible that the call could have been hungup.
Move both additions to the same place, so this won't happen.
Issue 10158, initial patch by makoto, modified by me.
Russell Bryant [Mon, 9 Jul 2007 21:00:17 +0000 (21:00 +0000)]
When the specified class isn't found, properly fall back to the channel's music
class or the default.
(issue #10123, reported by blitzrage, patches from juggie, qwell, and me)
Jason Parker [Mon, 9 Jul 2007 20:18:15 +0000 (20:18 +0000)]
Several chan_zap options were not working on reload because they were arbitrarily
disallowed when reloading some/most PRI options (such as signalling) was disallowed.
Options such as polarityonanswerdelay and answeronpolarityswitch can safely be changed on a reload.
This corrects that behavior.
Russell Bryant [Fri, 6 Jul 2007 23:01:22 +0000 (23:01 +0000)]
If a sip_pvt struct has already registered an extension state callback,
remove the old one before adding a new one. If this isn't done, Asterisk
will crash. (issue #10120)
Copy language information to the dialog structure when calling a peer for situations where a PBX may be started on the dialed channel. (issue #10121 reported by clegall_proformatique)
Reset ServicelevelPerf variable back to 0 if we are unable to calculate it each time... otherwise we will get previous values. (issue #10117 reported by noriyuki)
Russell Bryant [Sun, 1 Jul 2007 23:51:34 +0000 (23:51 +0000)]
When appending lines to call files to keep track of retries, write a leading
newline just in case the original call file did not have a newline at the end.
This fix is in response to a problem I saw reported on the asterisk-users
mailing list.
Russell Bryant [Fri, 29 Jun 2007 16:30:56 +0000 (16:30 +0000)]
Backport changes that make chan_iax2 not start the PBX on an incoming channel
until the three-way call setup is completed. These changes are already in 1.4
and trunk.
check if the bchannel stack id is already used, if so don't use it a second time. Also added a release_chan lock, so that the same chan_list object cannot be freed twice. chan_misdn does not crash anymore on heavy load with these changes.
Brett Bryant [Wed, 27 Jun 2007 23:22:13 +0000 (23:22 +0000)]
Reinstating patch. This actually fixes the problem, however I was running a development branch without it and mistakenly thought it wasn't fixed.
Fixes issue #10010, and #9654: 100% CPU usage caused by an asterisk console losing it's controlling terminal.
Russell Bryant [Wed, 27 Jun 2007 21:06:45 +0000 (21:06 +0000)]
Fix a minor issue with parsing the priority number. You could have as much
whitespace as you want around a numeric priority, but you couldn't have any
whitespace around a special priority like "n" or "hint".
(issue #10039, reported by mitheloc, fixed by me)
Joshua Colp [Wed, 27 Jun 2007 20:23:24 +0000 (20:23 +0000)]
I may possibly get shot for doing this... but... defer CDR processing until after the channel has been dealt with. This should eliminate all of the issues with channels going funky (SIP/PRI) when you are posting CDRs to a database that is either slow or unavailable and do not want to enable batching.
simplified generation for dummy bchannels, also we mark them as dummies, so they are not used later as real-bchannels, optimized the RESTART mechanisms, we block a channel now on cause:44, and send out a RESTART automatically, then on reception of RESTART_ACKNOWLEDGE we unblock the channel again.
for inbound TE calls, we setup the bchannel when we get the CONNECT_ACKNOWLEDGE, to make sure mISDN has everything ready. removed some #if 0 areas which weren't used anymore.
Brett Bryant [Fri, 22 Jun 2007 14:39:34 +0000 (14:39 +0000)]
Fixed infinite loop when controlling terminal was lost
and return value of input function wasn't checked for
errors. This would cause 100% cpu to be taken up.
(closes issue #9654, issue #10010)
Reported by: mnicholson, and eserra
Steve Murphy [Thu, 21 Jun 2007 22:29:50 +0000 (22:29 +0000)]
This little fix is in response to bug 10016, but may not cure it. The code is wrong, clearly. In a situation where you set the CDR's amaflags, and then ForkCDR, and then set the new CDR's amaflags to some other value, you will see that all CDRs have had their amaflags changed. This is not good. So I fixed it.