Age | Commit message (Collapse) | Author | Files | Lines |
|
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.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@115564 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
version
of my IAX2 improvements.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@115511 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@115296 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
ensure that it has the correct one.
(closes issue #10078)
(AST-2008-006)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@114561 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@110335 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(AST-2008-003)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@109391 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@94661 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #11606)
Reported by: dimas
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@94255 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@94214 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@93675 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@93667 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #10360)
(closes issue #10364)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@78370 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
loadzone was not defined was confusing
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@76978 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(ASA-2007-018)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@76802 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@76653 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Reported by: homesick
Patches:
rpid_1.4_75840.patch uploaded by homesick (license 91)
Accept Remote Party ID on guest calls.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@76560 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
by rizzo. The memory used for the localaddr list was not freed during a
configuration reload.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@76226 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@76080 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@75927 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@75757 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(ASA-2007-016)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@75449 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@75444 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
so that code later on does not think it has data to copy.
(ASA-2007-015)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@75440 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Reported by: mmacvicar
Patches submitted by: bbryant, russell
Tested by: mmacvicar, marco, arcivanov, jmhunter, explidous
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.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@75052 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@74766 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #10178, reported and patched by makoto, with slight modification for 1.4 and trunk by me)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@74719 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
#10174 reported by francesco_r)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@74587 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Issue 10169, patch by makoto, with a minor mod by me to not re-break issue 9618
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@74376 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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.
Issue 9186, patch by tzafrir.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@74158 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
remove the old one before adding a new one. If this isn't done, Asterisk
will crash. (issue #10120)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@73768 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Reported by: makoto
Patches submitted by: makoto
This fixes a crash in chan_sip that happens when the bindaddr setting is not
valid on Asterisk startup, gets fixed, and then a reload gets issued.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@73678 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
jiddings, patched by moi)
closes issue #9618
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@73674 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
it for G.729
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@73547 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
situations where a PBX may be started on the dialed channel. (issue #10121 reported by clegall_proformatique)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@73466 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
instead of blindly assuming it was. (issue #10112 reported by makoto)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@73318 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
setuped on inbound calls too.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@73252 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
state wasn't changed..
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@73207 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
channels.. #9449
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@73004 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
until the three-way call setup is completed. These changes are already in 1.4
and trunk.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@72629 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@72585 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@72099 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
areas.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@72087 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@72041 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
CONNECT_ACKNOWLEDGE, to make sure mISDN has everything ready. removed some #if 0 areas which weren't used anymore.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@72040 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
#10041 reported by homesick)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@71414 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
connect the call.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@70672 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
#8565 reported by jsmith)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@70551 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
when a PRI disconnect is received depending on which cause code was received.
(issue #9588, original patch by softins, updated patch from jtexter3, and some
additional feedback from mhardeman)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@70396 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@70342 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
..bchannels weren't cleaned properly.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@70341 f38db490-d61c-443f-a65b-d21fe96a405b
|