At first sight (but the function is very large so i am not 100% sure)
the code seems correct, so maybe my compiler is just not smart
enough to figure that out at the optimization level it has.
Not worthwhile merging to 1.4 i believe.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@77156 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r76485 | russell | 2007-07-23 07:25:01 -0500 (Mon, 23 Jul 2007) | 6 lines
Use a signed integer for storing the number of bytes in the packet read from
the network. Using an unsigned value here made it impossible to handle an
error returned from recvfrom(). Furthermore, in the case that recvfrom()
did return an error, this would cause a crash due to a heap overflow.
(closes issue #10265, reported by and fix suggested by timrobbins)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@76486 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
................
r75928 | russell | 2007-07-19 10:53:15 -0500 (Thu, 19 Jul 2007) | 14 lines
Merged revisions 75927 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r75927 | russell | 2007-07-19 10:49:42 -0500 (Thu, 19 Jul 2007) | 6 lines
When processing full frames, take sequence number wraparound into account when
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: https://origsvn.digium.com/svn/asterisk/trunk@75929 65c4cc65-6c06-0410-ace0-fbb531ad65f3
list were not destroyed when the module is unloaded. However, after reading
the code related to the use of this list a lot today, I realized that it isn't
necessary. So, I have added a comment to explain why it isn't necessary.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@75806 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
................
r75759 | russell | 2007-07-18 16:09:46 -0500 (Wed, 18 Jul 2007) | 13 lines
Merged revisions 75757 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r75757 | russell | 2007-07-18 16:09:13 -0500 (Wed, 18 Jul 2007) | 5 lines
When traversing the queue of frames for possible retransmission after
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: https://origsvn.digium.com/svn/asterisk/trunk@75761 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
................
r75445 | russell | 2007-07-17 15:48:21 -0500 (Tue, 17 Jul 2007) | 13 lines
Merged revisions 75444 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r75444 | russell | 2007-07-17 15:45:27 -0500 (Tue, 17 Jul 2007) | 5 lines
Ensure that when encoding the contents of an ast_frame into an iax_frame, that
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: https://origsvn.digium.com/svn/asterisk/trunk@75446 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
................
r74767 | russell | 2007-07-11 17:57:07 -0500 (Wed, 11 Jul 2007) | 13 lines
Merged revisions 74766 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r74766 | russell | 2007-07-11 17:53:26 -0500 (Wed, 11 Jul 2007) | 5 lines
The function make_trunk() can fail and return -1 instead of a valid new call
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: https://origsvn.digium.com/svn/asterisk/trunk@74769 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r73551 | russell | 2007-07-05 17:31:31 -0500 (Thu, 05 Jul 2007) | 6 lines
* Store the call number that a thread is processing without the full frame bit
set to ease debugging
* When deferring a full frame for processing, stick it into the queue for the
thread that is processing frames for that call, not the one that read the
current frame and is about to go back into the idle list
(related to issue #9937)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@73552 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r70866 | russell | 2007-06-21 16:07:04 -0500 (Thu, 21 Jun 2007) | 5 lines
If a full frame is received while one of the iax2 threads is in the middle
of handling a full frame for the same call, queue it up for processing by that
same thread later instead of dropping it.
(issue #9937, patch by me)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@70877 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r68313 | kpfleming | 2007-06-07 17:14:35 -0500 (Thu, 07 Jun 2007) | 6 lines
some improvements to the IAX2 full frame dropping logic recently added:
- use inaddrcmp(), since we have it
- output the type of frame and subclass being dropped, and the type/subclass that is already being processed (which caused the drop)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@68321 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r67270 | kpfleming | 2007-06-05 09:35:52 -0500 (Tue, 05 Jun 2007) | 3 lines
ensure that a burst of full frames (AST_FRAME_DTMF being the prime example) will not be processed out of order... this is a brute force fix, but seems to be the safest fix for now (thanks to the Digium PQ department for finding this bug)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@67271 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r67158 | russell | 2007-06-04 18:31:40 -0500 (Mon, 04 Jun 2007) | 5 lines
Fix up a bunch of places where the iax2 pvt structure can disappear and the
code did not account for it and crashes.
(issues #9642, #9569, #9666, probably others ... based on the work by
stevedavies and mihai, with additional changes from me)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@67160 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r67119 | russell | 2007-06-04 17:28:55 -0500 (Mon, 04 Jun 2007) | 6 lines
Add comments for two functions that get called with the appropriate call locked,
but perform operations that could result in the pvt structure getting destroyed
before returning again, causing numerous seg faults all over the module.
(inspired by issues #9642, #9569, and #9666, and the work done by stevedavies
and mihai)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@67120 65c4cc65-6c06-0410-ace0-fbb531ad65f3
over from my attempt at putting pvt structs in a hash table. It can cause
seg faults, and has no reason to stay.
(issue #9642, pointed out by stevedavies)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@67070 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r67020 | russell | 2007-06-04 10:47:40 -0500 (Mon, 04 Jun 2007) | 7 lines
Resolve a deadlock in chan_iax2. When handling an implicit ACK to a frame that
was marked as the final transmission for a call, don't call iax2_destroy() for
that call while the global frame queue is still locked. There is a very nice
explanation of the deadlock in the report.
(issue #9663, thorough report and patch from stevedavies, additional positive
test reports from mihai and joff_oconnell)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@67022 65c4cc65-6c06-0410-ace0-fbb531ad65f3
places in the code where the same block of code for creating detached threads
was replicated. (patch from bbryant)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@65968 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r65679 | kpfleming | 2007-05-23 16:30:24 -0400 (Wed, 23 May 2007) | 2 lines
don't start a PBX on a new incoming IAX2 channel until we have some sort of response to our ACCEPT (ACK or anything else)
........
r65680 | kpfleming | 2007-05-23 16:35:50 -0400 (Wed, 23 May 2007) | 2 lines
clear the 'delay PBX' flag when we are ready to start the PBX
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@65681 65c4cc65-6c06-0410-ace0-fbb531ad65f3