Bug#482997: asterisk: Extremely choppy sound and high CPU usage
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
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
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
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
* 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
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]