aboutsummaryrefslogtreecommitdiffstats
path: root/channels/chan_iax2.c
AgeCommit message (Collapse)AuthorFilesLines
2010-02-09fixes regression caused by randomized call numbers.dvossel1-2/+2
(closes issue 0015997) Reported by: exarv Patches: iax_fix.diff uploaded by dvossel (license 671) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@245874 f38db490-d61c-443f-a65b-d21fe96a405b
2009-11-10don't crash on log message in solarisdvossel1-1/+1
AST-2009-006 (closes issue 0016206) Reported by: bklang Tested by: bklang git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@229235 f38db490-d61c-443f-a65b-d21fe96a405b
2009-09-10IAX2 encryption regressiondvossel1-4/+26
The IAX2 Call Token security patch inadvertently broke the use of encryption due to the reorganization of code in the socket_process() function. When encryption is used, an incoming full frame must first be decrypted before the information elements can be parsed. The security release mistakenly moved IE parsing before decryption in order to process the new Call Token IE. To resolve this, decryption of full frames is once again done before looking into the frame. This involves searching for an existing callno, checking the pvt to see if encryption is turned on, and decrypting the packet before the internal fields of the full frame are accessed. associated with AST-2009-006 (closes issue #15834) Reported by: karesmakro Patches: iax2_encryption_fix_1.4.diff uploaded by dvossel (license 671) Tested by: dvossel, karesmakro Review: https://reviewboard.asterisk.org/r/355/ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@217887 f38db490-d61c-443f-a65b-d21fe96a405b
2009-09-03Merge code associated with AST-2009-006dvossel1-117/+1231
(closes issue #12912) Reported by: rathaus Tested by: tilghman, russell, dvossel, dbrooks git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@215958 f38db490-d61c-443f-a65b-d21fe96a405b
2009-08-10AST-2009-005tilghman1-5/+5
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@211526 f38db490-d61c-443f-a65b-d21fe96a405b
2009-07-14Ensure apathetic replies are sent out on the proper socket.russell1-3/+5
chan_iax2 supports multiple address bindings. The send_apathetic_reply() function did not attempt to send its response on the same socket that the incoming message came in on. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@206384 f38db490-d61c-443f-a65b-d21fe96a405b
2009-06-04Additional updates to AST-2009-001dvossel1-3/+19
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@199137 f38db490-d61c-443f-a65b-d21fe96a405b
2009-05-15IAX2 REGAUTH loopdvossel1-12/+18
IAX was not sending REGREJ to terminate invalid registrations. Instead it sent another REGAUTH if the authentication challenge failed. This caused a loop of REGREQ and REGAUTH frames. This patch also fixes some compile errors that occured using gcc v4.3.2. (Related to Security fix AST-2009-001) (closes issue #14386) Reported by: sabbathbh git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@194878 f38db490-d61c-443f-a65b-d21fe96a405b
2009-01-23Updates to AST-2009-001tilghman1-3/+6
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@170580 f38db490-d61c-443f-a65b-d21fe96a405b
2009-01-151.2 regression on security fix AST-2009-001tilghman1-13/+11
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@168632 f38db490-d61c-443f-a65b-d21fe96a405b
2009-01-06Security fix AST-2009-001.tilghman1-16/+28
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@167259 f38db490-d61c-443f-a65b-d21fe96a405b
2008-12-10Fix for AST-2008-012tilghman1-2/+2
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@162868 f38db490-d61c-443f-a65b-d21fe96a405b
2008-11-25Regression fix for last security fix. Set the iseqno correctly.tilghman1-2/+2
(closes issue #13918) Reported by: ffloimair Patches: 20081119__bug13918.diff.txt uploaded by Corydon76 (license 14) Tested by: ffloimair git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@159245 f38db490-d61c-443f-a65b-d21fe96a405b
2008-07-24This part was not correctly patched for AST-2008-010.tilghman1-2/+2
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@133360 f38db490-d61c-443f-a65b-d21fe96a405b
2008-07-22Fixes for AST-2008-010 and AST-2008-011tilghman1-1/+28
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@132711 f38db490-d61c-443f-a65b-d21fe96a405b
2008-05-30- Instead of only enforcing destination call number checking on an ACK, checkrussell1-11/+53
all full frames except for PING and LAGRQ, which may be sent by older versions too quickly to contain the destination call number. (As suggested by Tim Panton on the asterisk-dev list) - Merge changes from team/russell/iax2-frame-race, which prevents PING and LAGRQ from being sent before the destination call number is known. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@119237 f38db490-d61c-443f-a65b-d21fe96a405b
2008-05-29Merge changes from team/russell/iax2-another-fix-to-the-fixrussell1-7/+8
As described in the following post to the asterisk-dev mailing list, only enforce destination call numbers when processing an ACK. http://lists.digium.com/pipermail/asterisk-dev/2008-May/033217.html git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@119008 f38db490-d61c-443f-a65b-d21fe96a405b
2008-05-08Fix a race condition that bbryant just found while doing some IAX2 testing.russell1-1/+33
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
2008-05-07Remove remnants of dlinkedlists. I didn't actually use them in the final ↵russell1-3/+0
version of my IAX2 improvements. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@115511 f38db490-d61c-443f-a65b-d21fe96a405b
2008-05-05Merge changes from team/russell/iax2_find_callno_1.2russell1-134/+255
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
2008-04-22When we receive a full frame that is supposed to contain our call number,russell1-17/+34
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
2008-03-20Fix some very broken code that was introduced in 1.2.26 as a part of the ↵russell1-6/+6
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
2007-12-20Fix another potential seg fault ...russell1-2/+2
(closes issue #11606) Reported by: dimas git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@94255 f38db490-d61c-443f-a65b-d21fe96a405b
2007-12-20Fix a couple of places where it's possible to dereference a NULL pointer.russell1-2/+2
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@94214 f38db490-d61c-443f-a65b-d21fe96a405b
2007-12-18Oops, missed this one casetilghman1-1/+1
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@93675 f38db490-d61c-443f-a65b-d21fe96a405b
2007-12-18Fixing AST-2007-027 (Closes issue #11119)tilghman1-7/+65
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@93667 f38db490-d61c-443f-a65b-d21fe96a405b
2007-07-24Don't create the Asterisk channel until we are starting the PBX on it.qwell1-16/+14
(ASA-2007-018) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@76802 f38db490-d61c-443f-a65b-d21fe96a405b
2007-07-19When processing full frames, take sequence number wraparound into account whenrussell1-1/+3
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
2007-07-18When traversing the queue of frames for possible retransmission afterrussell1-1/+1
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
2007-07-17Ensure that when encoding the contents of an ast_frame into an iax_frame, thatrussell1-2/+5
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
2007-07-17After parsing information elements in IAX frames, set the data length to zero,russell1-0/+1
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
2007-07-11The function make_trunk() can fail and return -1 instead of a valid new callrussell1-3/+8
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
2007-06-29Backport changes that make chan_iax2 not start the PBX on an incoming channelrussell1-8/+34
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
2007-05-23if we are going to set variables on a newly created channel, it should be ↵kpfleming1-3/+5
done *before* we start the PBX on it git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@65676 f38db490-d61c-443f-a65b-d21fe96a405b
2007-05-10Fix an issue with trying to kill a thread before it gets created.qwell1-1/+2
Issue 9709, patch by nic_bellamy. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@63828 f38db490-d61c-443f-a65b-d21fe96a405b
2007-05-02Issue 9638 - if a text frame is sent with no terminating NULL through a bridgedtilghman1-0/+7
IAX connection, the remote end will receive garbage characters tacked onto the end. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@62691 f38db490-d61c-443f-a65b-d21fe96a405b
2007-04-26Revert previous fix for when the IAX2 channel goes funky (that's the ↵file1-2/+6
technical term). This is causing legit calls to be prematurely hung up. (issue #9600 reported by justdave) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@62037 f38db490-d61c-443f-a65b-d21fe96a405b
2007-04-25If the callerid= option is specified, but empty, clear any previous data.russell1-0/+8
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@61866 f38db490-d61c-443f-a65b-d21fe96a405b
2007-04-25Ensure that callerid settings are reset on a reload.russell1-6/+16
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@61862 f38db490-d61c-443f-a65b-d21fe96a405b
2007-03-29Backport the change to chan_iax2 to return NULL instead of a "null frame"russell1-3/+2
from its read callback. See revision 59341 to the 1.4 branch for more info. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@59355 f38db490-d61c-443f-a65b-d21fe96a405b
2007-03-27Fix the use of the "sourceaddress" option when "bindaddr" is set to 0.0.0.0russell1-3/+42
instead of having each interface explicitly listed. (issue #7874, patch by stevens) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@59258 f38db490-d61c-443f-a65b-d21fe96a405b
2007-03-07Fix a problem where the Asterisk channel name could be that of the wrong IAX2russell1-11/+19
user for a call. This is because the first step of choosing this name is to look for an IAX2 peer that happens to have the same IP/port number that this call is coming from and assuming that is it. However, this is not always correct. So, I have made it change this name after authentication happens since at that point, we have an exact match. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@58242 f38db490-d61c-443f-a65b-d21fe96a405b
2007-02-23Don't destroy mutexes before unregistering all of the entry points from the ↵russell1-4/+9
core. Also, fix a potential memory leak from not destroying the locks for all of the possible call numbers (about 32k of them). git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@56406 f38db490-d61c-443f-a65b-d21fe96a405b
2007-02-07Fix a few potential memory leaks with realtime users and peers. (issue #8999 ↵file1-11/+12
reported by bsmithurst) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@53357 f38db490-d61c-443f-a65b-d21fe96a405b
2007-01-31Fix a bunch of places where pthread_attr_init() was called, butrussell1-1/+5
pthread_attr_destroy() was not. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@53045 f38db490-d61c-443f-a65b-d21fe96a405b
2007-01-30Fix the extraction of the timestamp from video frames. It was using therussell1-2/+2
mapping for a mini-frame instead of a video-frame, which caused it to get invalid data. (issue #8795, mihai) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@52762 f38db490-d61c-443f-a65b-d21fe96a405b
2007-01-27Make the last context entry read in the dominant one. (issue #8918 reported ↵file1-4/+2
by pj) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@52360 f38db490-d61c-443f-a65b-d21fe96a405b
2007-01-08Ensure we use the default refresh value of 60 if the remote server does not ↵file1-1/+1
send one. (issue #8746 reported by maethor) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@49889 f38db490-d61c-443f-a65b-d21fe96a405b
2007-01-05ensure that threads which are supposed to be detached (because we aren't ↵kpfleming1-2/+12
going to wait on them) are created properly git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@49635 f38db490-d61c-443f-a65b-d21fe96a405b
2006-12-24Check for the proper return value on an error in a call to mmap().russell1-1/+1
This was reported by Andy Wang on the asterisk-dev list. Thanks! git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.2@48943 f38db490-d61c-443f-a65b-d21fe96a405b
generated by cgit v1.2.3 (git 2.25.1) at 2024-09-28 15:42:50 +0000