tags 482997 + confirmed
thanks
Torgeir Skjøtskift wrote:
When making calls involving IAX2 channels, sound is extremely choppy
and CPU usage spikes.
Messages on the CLI indicate problems while channels are active:
WARNING[12301]: File chan_iax2.c, Line 4436 (socket_read): Received
mini frame before first full voice frame
IAX2 registry entries become unregistered
IAX2 peers become UNREACHABLE
This problem seems to be caused by the 2etch4 update, since it works
fine in 2etch3 (see http://www.debian.org/security/2008/dsa-1563).
To replicate:
Set asterisk console debug and verbose to 100
SIP phones on machine A
via IAX2 trunk to machine B
via IAX2 trunk back to meetme room on machine A
Creating 5-10 simultaneous calls should reveal the problem.
This is indeed a regression from the versions before the security fix.
upstream has fixed this with a commit[1] with the following description:
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.
There is another regression[2] thas has been similarly fixed in 1.2.28.1.
It is, unfortunately, a huge commit, since it backports various stuff
(astobj2) from 1.4.
But I don't see another option to be honest and neither did upstream --
and 1.2 is in their deep-freeze state, similar to our own (security
fixes and grave bugs only).
security team, what do you think?
Should I prepare a new version with these changes and upload it to
security-proposed-updates?
Regards,
Faidon
1: http://svn.digium.com/view/asterisk?view=rev&revision=115296
2: http://svn.digium.com/view/asterisk?view=rev&revision=115564
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
