asterisk users - Jul 2010 - IAX authentication oddity - Known issue? Fixed?

Hi,

I had the following odd behaviour in Asterisk 1.2 - We are migrating
to 1.6, and I will re-test ASAP, though it is quite hard to replicate,
but I am curious to know whether it is a known IAX issue in 1.2.

We had 2 users in iax.conf:

[user1]
username=user1
secret=secret1
context=context1
host=iax.hostname.com

[user2]
username=user2
secretcontext=context2
host=dynamic
deny=0.0.0.0/0.0.0.0
allow=1.2.3.0/255.255.255.0


A call came in with username=user2, the call was from the valid IP
range specified in [user2], and the IAX debug trace showed the call as
UNAUTHENTICATED. So far so good.

The issue is that once the call was "in", the channel-name was
allocated as IAX/user1-xxx (instead of IAX/user2-xxx) and the call
jumped to context1 instead of context2.

I believe that the source IP address for the call DOES fall into the
list of IP addresses that resolve using iax.hostname.com.

I am concerned!

Regards,
Steve

On Wednesday 28 July 2010 06:49:01 Steve Davies wrote:
> Hi,
>
> I had the following odd behaviour in Asterisk 1.2 - We are migrating
> to 1.6, and I will re-test ASAP, though it is quite hard to replicate,
> but I am curious to know whether it is a known IAX issue in 1.2.
>
> We had 2 users in iax.conf:
>
> [user1]
> username=user1
> secret=secret1
> context=context1
> host=iax.hostname.com
>
> [user2]
> username=user2
> secret> context=context2
> host=dynamic
> deny=0.0.0.0/0.0.0.0
> allow=1.2.3.0/255.255.255.0
>
>
> A call came in with username=user2, the call was from the valid IP
> range specified in [user2], and the IAX debug trace showed the call as
> UNAUTHENTICATED. So far so good.
>
> The issue is that once the call was "in", the channel-name was
> allocated as IAX/user1-xxx (instead of IAX/user2-xxx) and the call
> jumped to context1 instead of context2.
>
> I believe that the source IP address for the call DOES fall into the
> list of IP addresses that resolve using iax.hostname.com.
I don't see a 'type' argument to either of the above, so neither of
these
would at all be used.  That said, you're assuming that the deny and allow
determine who is allowed to be user2.  That's incorrect.  They permit what
packets will even reach user2, and a registration needs to occur for the host
address to become something other than 0.0.0.0 (which is the default, unless
you have a defaultip parameter).  Hence, user2 won't match anything at all
until a registration packet comes in that passes your deny/allow ACL.

-- 
Tilghman Lesher
Digium, Inc. | Senior Software Developer
twitter: Corydon76 | IRC: Corydon76-dig (Freenode)
Check us out at: www.digium.com & www.asterisk.org

On 07/28/2010 11:32 AM, Tilghman Lesher wrote:
> They permit what packets will even reach user2
It should also be pointed out that the config option is "permit", and
not "allow".