Re: [asterisk-dev] Asterisk Beacon Module Proposal

[Tzafrir Cohen]

On Tue, May 12, 2015 at 01:24:17PM -0500, Scott Griepentrog wrote:
> 
> On Tue, May 12, 2015 at 12:59 PM, Tzafrir Cohen 
> wrote:
> 
> > Quoting the spec:
> >
> > | Spoofing
> > |
> > | In order to limit spoofing, the server will return a token for all
> > | accepted requests to a server. Any subsequent requests to that resource
> > | must present the token in the request. If a subsequent request fails to
> > | provide the token, the request is rejected. Tokens expire after 48
> > | hours, at which point, a request does not have to provide a token. If a
> > | request does provide a token that is expired - and no token is required
> > | at that point - the request should be accepted and a new token granted.
> > | Once a request is made without a token (and no token is expected), a new
> > | token is issued for subsequent requests.
> > |
> > | So long as Asterisk's transmission of data occurs faster than once every
> > | 48 hours, a malicious entity will not be able to spoof a resource. If a
> > | system is down then a remote system can 'take over' a system, and the
> > | legitimate system's attempts will be rejected. If that occurs... oh
> > | well. It is anonymous data.
> >
> > I'm not sure I understand the need for the token. The Debian
> > popularity-contest (popcon, [1]) only identifies systems by a single
> > random token (MY_HOSTID in /etc/popularity-contest.conf). It supports
> > sending information by mail as well (thus: completely
> > non-interactively). I don't see what the extra temporary token buys
> > here.
> >
> > Just send a report that includes the (random) server ID. Nobody should
> > be able to copy those (as they are only sent encrypted over the
> > internet). And in any event, why would anybody want to spoof that (as
> > opposed to merely add records to skew the stats, which is possible
> > either way just as easily).
> >
> > What am I missing here?
> >
> > [1] https://packages.debian.org/sid/popularity-contest
>
> So as opposed to spoofing, there is also the case that someone having a
> copy of Asteirsk in a virtual machine clones it, and ends up with two
> instances reporting the same random ID.  With the spoofing detection
> mechanism (using tokens to get an ID from the server), the effect of this
> case is minimized as each one will end up getting a new ID after token
> timeout.

So let's assume I have to cloned servers, A and B. Both have the same
ID, but each gets a different (temporary) token.

I assume tokens don't live very long. So now you need to corelate a
number of temporary tokens with A and others with B. If they do live
long enough, they might get cloned. The corelation of temporary IDs to
different servers does not seem reliable enough for me.

-- 
   Tzafrir Cohen
icq#16849755  jabber:tzafrir.co...@xorcom.com
+972-50-7952406   mailto:tzafrir.co...@xorcom.com
http://www.xorcom.com

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] (unreported) uninitialized: struct ast_sockaddr

[Alexander Traud]

> What you're proposing is a change to the semantics of ast_sockaddr.

Not sure what you mean by semantics. Please, let us ignore ast_sockaddr for
a second and see :

Currently, when a struct with "automatic storage duration" is created in
Asterisk, it is initialized
A) (correct) with {0},
B) (questionable) via memset,
C) (questionable) at first use, or
D) (wrong) not at all.

Is case D important enough to get fixed, at a whole, or partially. If
partially, to which extend?

Example 1:
The *opaque* peercnt (channels/chan_iax2.c) contains ast_sockaddr and
therefore has to be initialized correctly in my case to avoid a wild
pointer. Actually, I am using chan_sip only, added a pointer to
ast_sockaddr, cleaned memory, and my Asterisk was segfaulting in a complete
different module (chan_iax2.c). [Offtopic: Yes, my modules.conf was wrong.]

Example 2:
The *private* sip_peer (channels/sip/include/sip.h) contains pointers and is
not initialized at all twice, at least (sip_peer tmp_peer). This creates
wild pointers which segfaulted the pointer in my ast_sockaddr.

Asked differently:
I have a diff/patch correcting just the struct-inits for 62 lines of code at
54 places in 5 files, which affects my downstream code. Am I allowed to
commit just that, although it does not address the issue at a whole (there
are many more struct inits which stay wrong)?

Or: Is my compiler configured incorrectly somehow, not setting pointers to
(void *)0 automatically in structs with automatic storage duration?



-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Fwd: Code Review request of func_redis module

[Sergio Medina Toledo]

Great, then there isn't any problem, for me is fantastic having a tester
that can report bugs.

2015-05-12 20:38 GMT+01:00 Ludovic Gasc :

> Don't worry, I understand it isn't production ready, I'll test that only
> on a dev instance.
> I don't know yet if I'll have skills to help you with pull requests, but
> at least, with tests and eventual bug reports.
>
> For now, it isn't really critical, because I've a daemon that plays as a
> Redis proxy for Asterisk, but I vote always for simplifications, if only I
> don't have efficiency impacts.
>
> --
> Ludovic Gasc (GMLudo)
> http://www.gmludo.eu/
>
> 2015-05-12 9:04 GMT+02:00 Sergio Medina Toledo :
>
>> The part of the internal API that I used haven't changed from 11 to 13 so
>> it should work without any problem. But I haven't tested the module
>> intensively and I'm not sure if it is thread safe, so I don't recommend use
>> it in production servers right now. Today I'm gonna install the module in
>> an asterisk 11 active-passive cluster of preproduction to test it better,
>> after that I will expose my conclusions here, if some one that have more
>> experience developing in asterisk can look at the code and confirm that it
>> is thread safe i will be very grateful.
>>
>> 2015-05-11 21:22 GMT+01:00 Ludovic Gasc :
>>
>>> Hi,
>>>
>>> Your library is very interesting, because we already use Redis as a
>>> cache for some stuffs.
>>> For now, I've made a FastAGI server to serve Redis data, but it should
>>> be faster to read Redis data directly.
>>>
>>> Do you think I could test your module on an Asterisk 13, or the Asterisk
>>> internal API is too different to be used with another version than 11 ?
>>>
>>> Regards.
>>>
>>> Ludovic Gasc (GMLudo)
>>> http://www.gmludo.eu/
>>> On 11 May 2015 09:14, "GESTION DE TELEFONIA IP" 
>>> wrote:
>>>
 Hi all, I have developed an asterisk module to interact with redis from
 the dialplan, the project is motivated by the need to share
 information between different asterisk in both active-active and
 active-passive scheme, in an easy way like AstDB. You can use an agi
 script or a system call to a script to use redis from the dialplan but the
 performance is low compared to a asterisk module and the integration is
 worst. I think that maybe this module can be interesting to the
 community,

 It's the first time that I develop a asterisk module so If some one can
 make a code review to the module to see if there are use of insecure
 functions or something that can crash asterisk, I will be very grateful,
 the module is under GPLv2 License in this repo
 https://github.com/tic-ull/func_redis. At the moment the module is
 shipped outside the asterisk project, as a Cmake project. You can see
 the instructions to install and to use it in the README.md of the repo.

 The english isn't my native language so sorry if there ara some writing
 mistakes.


 --
 _
 -- Bandwidth and Colocation Provided by http://www.api-digital.com --

 asterisk-dev mailing list
 To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev

>>>
>>> --
>>> _
>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>>
>>> asterisk-dev mailing list
>>> To UNSUBSCRIBE or update options visit:
>>>http://lists.digium.com/mailman/listinfo/asterisk-dev
>>>
>>
>>
>> --
>> _
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>
>> asterisk-dev mailing list
>> To UNSUBSCRIBE or update options visit:
>>http://lists.digium.com/mailman/listinfo/asterisk-dev
>>
>
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-dev
>
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] 13: RTP pass-through creates no-media situations

[Alexander Traud]

No, I do not want to start another thread about codec-negotiation in
chan_sip. However, while playing with the audio-codec Opus in Asterisk 12
and Asterisk 13, I was able to establish a call without audio:

sip.conf
directmedia=no
disallow=all
allow=opus,ulaw

leg 1: VoIP/SIP client is calling Asterisk 13
   Asterisk 13 offers opus,ulaw to leg 2
leg 2: VoIP/SIP client chooses ulaw because it does not have opus
   Asterisk establishes the call and
   tries to transcode between opus <-> ulaw

This fails because Opus is a pass-through codec and cannot be transcoded.
However, the call is established and stays up infinitely. I am not able to
prevent this situation via the dial plan or the user configuration because I
do not know which media codecs are supported/offered by those clients in
advance. Actually, this is exactly the same as ASTERISK-11782. However, back
then the call was not established at all.
Question 1: Is this new (?) behavior intended (establishment vs. dropping)?

While testing, I found another issue (tested with Asterisk 13.3.2):
1) sip.conf with
   disallow=all
   allow=ulaw
2) started Asterisk
3) changed sip.conf to
   allow=opus,ulaw
4) CLI: sip reload
5) called Asterisk from a VoIP/SIP client
6) other clients get ulaw,opus (order is the other way around)
7) CLI: core stop now
started over with step 2, now the expected order (opus,ulaw) is offered.
Question 2: Shall I open an issue for this, or is that intended?



-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] 13: RTP pass-through creates no-media situations

[Joshua Colp]

Alexander Traud wrote:

No, I do not want to start another thread about codec-negotiation in
chan_sip. However, while playing with the audio-codec Opus in Asterisk 12
and Asterisk 13, I was able to establish a call without audio:

sip.conf
directmedia=no
disallow=all
allow=opus,ulaw

leg 1: VoIP/SIP client is calling Asterisk 13
Asterisk 13 offers opus,ulaw to leg 2
leg 2: VoIP/SIP client chooses ulaw because it does not have opus
Asterisk establishes the call and
tries to transcode between opus<->  ulaw

This fails because Opus is a pass-through codec and cannot be transcoded.
However, the call is established and stays up infinitely. I am not able to
prevent this situation via the dial plan or the user configuration because I
do not know which media codecs are supported/offered by those clients in
advance. Actually, this is exactly the same as ASTERISK-11782. However, back
then the call was not established at all.
Question 1: Is this new (?) behavior intended (establishment vs. dropping)?


I'd expect it to fail. The new bridging work may have had a side effect 
of not making it fatal.




While testing, I found another issue (tested with Asterisk 13.3.2):
1) sip.conf with
disallow=all
allow=ulaw
2) started Asterisk
3) changed sip.conf to
allow=opus,ulaw
4) CLI: sip reload
5) called Asterisk from a VoIP/SIP client
6) other clients get ulaw,opus (order is the other way around)
7) CLI: core stop now
started over with step 2, now the expected order (opus,ulaw) is offered.
Question 2: Shall I open an issue for this, or is that intended?


If you reload it should have the new preference order. This would be a 
bug, likely in chan_sip itself.


--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] (unreported) uninitialized: struct ast_sockaddr

[Richard Mudgett]

On Wed, May 13, 2015 at 3:59 AM, Alexander Traud 
wrote:

> > What you're proposing is a change to the semantics of ast_sockaddr.
>
> Not sure what you mean by semantics. Please, let us ignore ast_sockaddr for
> a second and see :
>

Semantics just mean how something has to be used.  You are changing the
semantics of ast_sockaddr by adding something that must be explicitly
released.
Whereas, before there was nothing that needed to be explicitly released so
nothing would need to be explicitly called to destroy the ast_sockaddr
instance.


>
> Currently, when a struct with "automatic storage duration" is created in
> Asterisk, it is initialized
> A) (correct) with {0},
> B) (questionable) via memset,
> C) (questionable) at first use, or
> D) (wrong) not at all.
>
> Is case D important enough to get fixed, at a whole, or partially. If
> partially, to which extend?
>
> Example 1:
> The *opaque* peercnt (channels/chan_iax2.c) contains ast_sockaddr and
> therefore has to be initialized correctly in my case to avoid a wild
> pointer. Actually, I am using chan_sip only, added a pointer to
> ast_sockaddr, cleaned memory, and my Asterisk was segfaulting in a complete
> different module (chan_iax2.c). [Offtopic: Yes, my modules.conf was wrong.]
>

struct peercnt is not opaque as the struct definition is visible to the code
using the structure.  If it were opaque you would only be able to create
pointer
variables to the struct and not instances of the struct itself.  The
compiler
cannot let you create an instance of struct peercnt if it does not know the
size
of it.

struct peercnt *pointer_to_peercnt;
struct peercnt instance_of_peercnt;


>
> Example 2:
> The *private* sip_peer (channels/sip/include/sip.h) contains pointers and
> is
> not initialized at all twice, at least (sip_peer tmp_peer). This creates
> wild pointers which segfaulted the pointer in my ast_sockaddr.
>

These particular uses of peercnt in chan_iax2.c and sip_peer in chan_sip.c
are
dummy objects with just enough fields filled in to perform an ao2_find().
Those
dummy objects are never destroyed so the uninitialized pointers are
irrelevant.
The coding pattern that creates a dummy object with the container key fields
filled in pre-dates the introduction of OBJ_SEARCH_KEY and the older name
OBJ_KEY.


>
> Asked differently:
> I have a diff/patch correcting just the struct-inits for 62 lines of code
> at
> 54 places in 5 files, which affects my downstream code. Am I allowed to
> commit just that, although it does not address the issue at a whole (there
> are many more struct inits which stay wrong)?
>
> Or: Is my compiler configured incorrectly somehow, not setting pointers to
> (void *)0 automatically in structs with automatic storage duration?
>

I haven't seen a compiler that tracks uninitialized struct members.  You
should
make your addition as a char array rather than an allocated pointer to avoid
incompatibilities in unexpected places.  Otherwise, the semantic change
breaks code all over the place.

Richard
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk Beacon Module Proposal

[Moises Silva]

On Tue, May 12, 2015 at 1:47 PM, Tzafrir Cohen 
wrote:

> On Tue, May 12, 2015 at 11:15:40AM -0600, George Joseph wrote:
>
> > The only volatile stats to be reported were active/total calls and I'd be
> > willing to give that up to keep the process simple.   Even if we did keep
> > the calls, and it reported a few times a day I still don't see the need
> for
> >  the complexity.   I don't want to have to set up cron jobs and worry
> about
> > extra services or have to go through exposing new APIs.  In the time
> we've
> > been discussing this, a basic module that does what we needed could have
> > been written.
>
> The "API":
>
>   asterisk stats dump [noreset]
>
> By default the stats will be collected (unless disabled at build time) -
> the overhead for collecting them seems small enough (right?). However as
> long as they are not dumped, nothing is reported to the Big Brother.
>
> Dumps current stats (to standard output) and resets counters.
>
> Setting up a cron job is simple. And this removes complexity from the
> Asterisk process. It also removes unnecessary network connectivity from
> the Asterisk process, and simplifies settings of whatever network
> settings.
>

Yeah, I like this better
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev