[svn-commits] russell: branch 1.6.0 r115567 - in /branches/1.6.0: ./ channels/chan_iax2.c

[SVN commits to the Digium repositories]

Author: russell
Date: Thu May  8 14:18:10 2008
New Revision: 115567

URL: http://svn.digium.com/view/asterisk?view=rev&rev=115567
Log:
Merged revisions 115566 via svnmerge from 
https://origsvn.digium.com/svn/asterisk/trunk

................
r115566 | russell | 2008-05-08 14:17:04 -0500 (Thu, 08 May 2008) | 41 lines

Merged revisions 115565 via svnmerge from 
https://origsvn.digium.com/svn/asterisk/branches/1.4

................
r115565 | russell | 2008-05-08 14:15:25 -0500 (Thu, 08 May 2008) | 33 lines

Merged revisions 115564 via svnmerge from 
https://origsvn.digium.com/svn/asterisk/branches/1.2

........
r115564 | russell | 2008-05-08 14:14:04 -0500 (Thu, 08 May 2008) | 25 lines

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.

........

................

................

Modified:
    branches/1.6.0/   (props changed)
    branches/1.6.0/channels/chan_iax2.c

Propchange: branches/1.6.0/
------------------------------------------------------------------------------
Binary property 'trunk-merged' - no diff available.

Modified: branches/1.6.0/channels/chan_iax2.c
URL: http://svn.digium.com/view/asterisk/branches/1.6.0/channels/chan_iax2.c?view=diff&rev=115567&r1=115566&r2=115567
==============================================================================
--- branches/1.6.0/channels/chan_iax2.c (original)
+++ branches/1.6.0/channels/chan_iax2.c Thu May  8 14:18:10 2008
@@ -3919,6 +3919,24 @@
 
 	ast_mutex_lock(&iaxsl[callno]);
 	pvt = iaxs[callno];
+
+	if (!pvt->peercallno) {
+		/* We don't know the remote side's call number, yet.  :( */
+		int count = 10;
+		while (count-- && pvt && !pvt->peercallno) {
+			ast_mutex_unlock(&iaxsl[callno]);
+			usleep(1);
+			ast_mutex_lock(&iaxsl[callno]);
+			pvt = iaxs[callno];
+		}
+		if (pvt->peercallno) {
+			ast_log(LOG_NOTICE, "Yay, we didn't know the peercallno, but we were patient and got it.\n");
+		} else {
+			ast_log(LOG_NOTICE, "Damnit!  We waited around and never got the peercallno ...\n");
+			res = -1;
+			goto done;
+		}
+	}
 
 	switch (condition) {
 	case AST_CONTROL_HOLD: