https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r109575 | mmichelson | 2008-03-18 12:58:11 -0500 (Tue, 18 Mar 2008) | 6 lines

Make sure an agent doesn't try to send dtmf to a NULL channel

closes issue #12242
Reported by Yourname


........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109576 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109545 65c4cc65-6c06-0410-ace0-fbb531ad65f3

fix up various warnings found via the addition of format string checking... some of these were really, really bad code


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109475 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109451 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Go through and fix a bunch of places where character strings were being interpreted as format strings. Most of these changes are solely to make compiling with -Wsecurity and -Wformat=2 happy, and were not
actual problems, per se.  I also added format attributes to any printf wrapper functions I found that didn't have them.  -Wsecurity and -Wmissing-format-attribute added to --enable-dev-mode.


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109447 65c4cc65-6c06-0410-ace0-fbb531ad65f3

(AST-2008-004)


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109396 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109394 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r109386 | file | 2008-03-18 11:58:39 -0300 (Tue, 18 Mar 2008) | 3 lines

Put a maximum limit on the number of payloads accepted, and also make sure a given payload does not exceed our maximum value.
(AST-2008-002)

........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109390 65c4cc65-6c06-0410-ace0-fbb531ad65f3

(AST-2008-003)


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109389 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r109309 | murf | 2008-03-18 00:37:15 -0600 (Tue, 18 Mar 2008) | 17 lines

(closes issue #11903)
Reported by: atis

Many thanks to atis for spotting this problem and reporting it.
The fix was to straighten out how items are placed on and removed
from the file stack. Regressions as well as the provided test case
helped to straighten out all code paths. valgrind was used to make
sure all memory allocated was freed.

Sorry for not solving this earlier. I got distracted.

Added the ntest23 regression test, which is mainly a copy of ntest22, 
but with a few juicy errors thrown in, to replicate the kind of 
error that atis spotted.



........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109357 65c4cc65-6c06-0410-ace0-fbb531ad65f3

(closes issue #11959)
Reported by: mostyn
Patches: 
      peerstatus3.patch uploaded by mostyn (license 398)


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109316 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109282 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Replace minimime with superior GMime library so that the entire contents of an http post are not read into memory.
This does introduce a dependency on the GMime library for handling HTTP POSTs, but it is available in most distros.

If the library is present, then the compile flag for ENABLE_UPLOADS is enabled by default in menuselect.


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109229 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r109226 | mmichelson | 2008-03-17 17:05:49 -0500 (Mon, 17 Mar 2008) | 12 lines

Fix a logic flaw in the code that stores lock info which is displayed
via the "core show locks" command. The idea behind this section of code was
to remove the previous lock from the list if it was a trylock that had failed.
Unfortunately, instead of checking the status of the previous lock, we were referencing
the index immediately following the previous lock in the lock_info->locks array. 
The result of this problem, under the right circumstances, was that the lock which 
we currently in the process of attempting to acquire could "overwrite" the previous lock 
which was acquired. While this does not in any way affect typical operation, it *could*
lead to misleading "core show locks" output.



........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109227 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109172 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Reported by: mvanbaak
Tested by: murf, mvanbaak

Due to a bug that occurred when merge_contexts_and_delete scanned the "old" or existing contexts, and found a context
that doesn't exist in the new set, yet owned by a different registrar. The context is created in the new set, with the
old registrar, and and all the priorities and extens that have a different registrar are copied into it. But, not the
includes, ignorepats, and switches. I added code to do this immediately after the context is created.

This still leaves a logical hole in the code. If you define a context in two places, (eg. in extensions.conf and also 
in extensions.ael), and they both have includes, but different in composition, no new context will be generated, and
therefore the 'old' includes, switches, and ignorepats will not be copied. I'd have added code to simply add any non-duplicates
into the 'new' context that had a different registrar, but there is one big complication: includes, and switches are definitely
order dependent. (ignorepats I'm not sure about). And we'll have to develop some sort of policy about how we 
merge order dependent lists, especially if the intersection of the two sets is empty. (in other words, they do not have any
elements in common). Do the new go first, or the old? I've elected to punt this issue until a user complains. Hopefully,
this is pretty rare thing.




git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109169 65c4cc65-6c06-0410-ace0-fbb531ad65f3

when dialing a channel that does not provide progress (analog ZAP lines)

The phone does handle the double update on calls to channels that do
provide progress and wont insert duplicate items

(closes issue #12239)
Reported by: DEA
Patches:
      chan_skinny-call-log.txt uploaded by DEA (license 3)


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109168 65c4cc65-6c06-0410-ace0-fbb531ad65f3

don't define Zaptel features as libraries, they aren't, and we don't want '--with-zaptel-<foo>' configure options for them
also some minor cleanups


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109166 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109113 65c4cc65-6c06-0410-ace0-fbb531ad65f3

aastra-check-cfg is the same as the other check-cfg entries,
 and aastra-xml is to load a pre-configured xml script.

(closes issue #12229)
Reported by: gowen72
Patches:
      aastra.patch uploaded by gowen72 (license 432)


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109111 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r109107 | file | 2008-03-17 13:24:29 -0300 (Mon, 17 Mar 2008) | 4 lines

200 OKs in response to a reinvite need to be sent reliably. If the remote side does not receive one the dialog will be torn down.
(closes issue #12208)
Reported by: atrash

........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109108 65c4cc65-6c06-0410-ace0-fbb531ad65f3

........
r109057 | qwell | 2008-03-17 10:15:56 -0500 (Mon, 17 Mar 2008) | 4 lines

Backport revision 106439 from trunk.  I didn't realize this was broken in 1.4 as well.

Closes issue #12222.

........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109058 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Make sure that the temporary sip_request structure is empty so that copy_request doesn't think it already has an ast_str.
(closes issue #12231)
Reported by: IgorG


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109054 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r109012 | mmichelson | 2008-03-17 09:18:26 -0500 (Mon, 17 Mar 2008) | 6 lines

Make sure that we release the lock on the spyee channel if the spyee or spy has hung up

(closes issue #12232)
Reported by: atis


........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@109024 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r108961 | mvanbaak | 2008-03-16 22:47:10 +0100 (Sun, 16 Mar 2008) | 7 lines

add missing break to case AST_CONTROL_SRCUPDATE

(closes issue #12228)
Reported by: andrew
Patches:
      SRC.patch uploaded by andrew (license 240)

........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@108962 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@108929 65c4cc65-6c06-0410-ace0-fbb531ad65f3

(closes issue #12223)
Reported by: DEA
Patches: 
      vm-polled-imap.txt uploaded by DEA (license 3)


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@108927 65c4cc65-6c06-0410-ace0-fbb531ad65f3

How did this ever work?

(closes issue #12219)
Reported by: ys
Patches: 
      pbx.c.diff uploaded by ys (license 281)


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@108894 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@108857 65c4cc65-6c06-0410-ace0-fbb531ad65f3

(closes issue #12197)
Reported by: juggie
Patches:
      12197.diff uploaded by juggie (license 24)



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@108799 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r108796 | russell | 2008-03-14 15:09:22 -0500 (Fri, 14 Mar 2008) | 5 lines

Fix a channel name issue.  chan_oss registers the "Console" channel type,
but it created channels with an "OSS" prefix.

(closes issue #12194, reported by davidw, patched by me)

........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@108797 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r108792 | russell | 2008-03-14 15:04:35 -0500 (Fri, 14 Mar 2008) | 4 lines

Update the SuSE init script to start networking before asterisk, as well.

(closes issue #12200, reported by and change suggested by reinerotto)

........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@108793 65c4cc65-6c06-0410-ace0-fbb531ad65f3

reported by the tool.

(closes issue #12067, reported by Juggie, patched by me)


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@108740 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r108737 | mmichelson | 2008-03-14 11:44:08 -0500 (Fri, 14 Mar 2008) | 33 lines

Fix a race condition in the SIP packet scheduler which could cause a crash.

chan_sip uses the scheduler API in order to schedule retransmission of reliable
packets (such as INVITES). If a retransmission of a packet is occurring, then the
packet is removed from the scheduler and retrans_pkt is called. Meanwhile, if
a response is received from the packet as previously transmitted, then when we 
ACK the response, we will remove the packet from the scheduler and free the packet.

The problem is that both the ACK function and retrans_pkt attempt to acquire the
same lock at the beginning of the function call. This means that if the ACK function
acquires the lock first, then it will free the packet which retrans_pkt is about to
read from and write to. The result is a crash.

The solution:

1. If the ACK function fails to remove the packet from the scheduler and the retransmit
   id of the packet is not -1 (meaning that we have not reached the maximum number of 
   retransmissions) then release the lock and yield so that retrans_pkt may acquire the
   lock and operate.

2. Make absolutely certain that the ACK function does not recursively lock the lock in
   question. If it does, then releasing the lock will do no good, since retrans_pkt will
   still be unable to acquire the lock.

(closes issue #12098)
Reported by: wegbert
(closes issue #12089)
Reported by: PTorres
Patches:
      12098-putnopvutv3.patch uploaded by putnopvut (license 60)
Tested by: jvandal


........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@108738 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r108682 | qwell | 2008-03-14 09:29:05 -0500 (Fri, 14 Mar 2008) | 4 lines

Fix a potential segfault if chan (or chan->music_state) is NULL.

Closes issue #12210, credit to edantie for pointing this out.

........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@108683 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@108639 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@108586 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r108583 | russell | 2008-03-13 16:38:16 -0500 (Thu, 13 Mar 2008) | 11 lines

Fix another issue that was causing crashes in chanspy.  This introduces a new
datastore callback, called chan_fixup().  The concept is exactly like the
fixup callback that is used in the channel technology interface.  This callback
gets called when the owning channel changes due to a masquerade.  Before this
was introduced, if a masquerade happened on a channel being spyed on, the
channel pointer in the datastore became invalid.

(closes issue #12187)
(reported by, and lots of testing from atis)
(props to file for the help with ideas)

........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@108584 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r108530 | russell | 2008-03-13 16:06:33 -0500 (Thu, 13 Mar 2008) | 10 lines

Make a tweak that gets the LEDs on polycom phones to blink when an extension that
has been subscribed to goes on hold.  Otherwise, they just stay on like it does
when an extension is in use.

(closes issue #11263)
Reported by: russell
Patches:
      notify_hold.rev1.txt uploaded by russell (license 2)
Tested by: russell

........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@108531 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Though this overflow is exploitable remotely, we are NOT issuing a security
advisory for this since in order to exploit the overflow, the attacker would
have to establish an authenticated manager session AND have the system privilege.
By gaining this privilege, the attacker already has more powerful weapons at his
disposal than overflowing a buffer with a malformed manager header, so the vulnerability
in this case really lies with the authentication method that allowed the attacker to 
gain the system privilege in the first place.



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@108529 65c4cc65-6c06-0410-ace0-fbb531ad65f3