Bug#482997: asterisk: Extremely choppy sound and high CPU usage

2008-06-27 Thread Ketil Vestby
Thursday 26 June 2008, Moritz Muehlenhoff wrote:
..
What's the status? Shall we push the fix in the upcoming r4 release?

Not unless you want to break the asterisk in the r4 release badly.

The status: The patch did not do its job, instead it did open up for a rather 
huge set of instability problems in addition to the original problem. I have 
really been unsure about where to repost these problems, so my report did 
only focus on the original problem.

I've tried it on two computers, one with a 1 GHz VIA CPU and another with a 3 
GHz dualcore P4. The result on both computers: It semeed as if the patches 
did open up for instability when it comes to SIP-IAX2 transmission.

The tests have been redone with clean Debians, and the patched Asterisk, same 
result.

-- 
Ketil Vestby
Damsgard IKT



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#482997: asterisk: Extremely choppy sound and high CPU usage

2008-06-27 Thread Faidon Liambotis

Ketil Vestby wrote:

Thursday 26 June 2008, Moritz Muehlenhoff wrote:
..

What's the status? Shall we push the fix in the upcoming r4 release?
The status: The patch did not do its job, instead it did open up for a rather 
huge set of instability problems in addition to the original problem. I have 
really been unsure about where to repost these problems, so my report did 
only focus on the original problem.
It's became apparent that this would need a *lot* of build/test cycles 
and _proper_ testing before we even consider pushing it to either r4 or 
security-master.


I must say that having such both a performance regression _and_ a 
vulnerability in stable doesn't make me very happy; unfortunately, there 
isn't much I can do at this point; I'm severely lacking free time at 
this point of the year (semester exam period) and noone else from the 
team seems interested to push this forward.


I expect to gradually resume my Debian activities starting from 8/7.
I'll attempt to properly fix this unless someone else steps up until then.

Thanks and sorry,
Faidon



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#482997: asterisk: Extremely choppy sound and high CPU usage

2008-06-26 Thread Moritz Muehlenhoff
On Tue, May 27, 2008 at 09:08:52PM +0300, Faidon Liambotis wrote:
 Florian Weimer wrote:
 * Faidon Liambotis:

 security team, what do you think?
 Should I prepare a new version with these changes and upload it to
 security-proposed-updates?

 Do you mean stable-proposed-updates?  That's up to the stable release
 managers.

 I don't like uploading such a change as a security update if we can
 avoid it.  If you can guarantee sufficient testing, we could release a
 DSA errata, but this looks more like stuff for a point release.
 That's what I wrote initially, hence the typo :)

 I'm not so sure myself, we (upstream actually) broke an important  
 functionally badly; 16 calls on a core2 duo 2.33GHz is a *very* *very*  
 low number.

 It's a regression from a fix made in a security release, perhaps it  
 should be fixed with a DSA?

 I'm not sure I could gurantee sufficient testing; I could test a channel  
 or two, but not sure about running a high number of calls.
 Perhaps one of our reporters could do that?

 I don't know, I'll leave it up to you.

What's the status? Shall we push the fix in the upcoming r4 release?

Cheers,
Moritz



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#482997: asterisk: Extremely choppy sound and high CPU usage

2008-05-27 Thread Faidon Liambotis

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 2, then every media
  frame would cause 2 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=revrevision=115296
2: http://svn.digium.com/view/asterisk?view=revrevision=115564



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#482997: asterisk: Extremely choppy sound and high CPU usage

2008-05-27 Thread Florian Weimer
* Faidon Liambotis:

 security team, what do you think?
 Should I prepare a new version with these changes and upload it to
 security-proposed-updates?

Do you mean stable-proposed-updates?  That's up to the stable release
managers.

I don't like uploading such a change as a security update if we can
avoid it.  If you can guarantee sufficient testing, we could release a
DSA errata, but this looks more like stuff for a point release.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#482997: asterisk: Extremely choppy sound and high CPU usage

2008-05-27 Thread Faidon Liambotis

Florian Weimer wrote:

* Faidon Liambotis:


security team, what do you think?
Should I prepare a new version with these changes and upload it to
security-proposed-updates?


Do you mean stable-proposed-updates?  That's up to the stable release
managers.

I don't like uploading such a change as a security update if we can
avoid it.  If you can guarantee sufficient testing, we could release a
DSA errata, but this looks more like stuff for a point release.

That's what I wrote initially, hence the typo :)

I'm not so sure myself, we (upstream actually) broke an important 
functionally badly; 16 calls on a core2 duo 2.33GHz is a *very* *very* 
low number.


It's a regression from a fix made in a security release, perhaps it 
should be fixed with a DSA?


I'm not sure I could gurantee sufficient testing; I could test a channel 
or two, but not sure about running a high number of calls.

Perhaps one of our reporters could do that?

I don't know, I'll leave it up to you.

Thanks,
Faidon



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]