[asterisk-dev] IAX channel name incorrect - Found in 1.2 still happens in 1.6

[Steve Davies]

On 20 February 2011 17:17, Steve Davies <davies147 at gmail.com> wrote:
> On 7 February 2011 16:45, Steve Davies <davies147 at gmail.com> wrote:
>> Hi,
>>
>> The following IAX config (slightly edited) causes an issue for me in
>> version 1.6.2.16.1, where my CDR data is unreliable.
>>
>> [user1]
>> type=friend
>> auth=md5
>> accountcode=user1
>> notransfer=yes
>> context=context1
>> host=10.0.0.250
>> username=user1
>> secret=secret1
>> disallow=all
>> allow=alaw
>>
>> [user2]
>> type=friend
>> auth=md5
>> accountcode=user2
>> notransfer=yes
>> context=context2
>> host=dynamic
>> deny=0.0.0.0/0.0.0.0
>> permit=10.0.0.0/24
>> username=user2
>> secret=
>> disallow=all
>> allow=alaw
>>
>> If a call comes in from 10.0.0.250, using username "user2" and with no
>> password, then it is correctly authenticated against the [user2]
>> section.
>>    Accountcode is set to user2
>>    Context is set to context2
>> and the call mostly proceeds correctly, BUT the source channel name is
>> set to IAX2/user1-nnnn, which is then seen both in the dialplan debug
>> output, and in the CDR. I would expect the channel name to reflect the
>> section name that was used to authenticate the call ie.
>> IAX2/user2-nnnn; I specifically put a password onto [user1] so there
>> is no possibility that the call is authenticating there.
>>
>> Am I missing something? Or is this a bug?
>>
> *Bump* No takers? Perhaps no-one else thinks this is a bug?
>

(Switching to -dev list)

Further to the above, I think I found the cause... In
channels/chan_iax.c (line 2720 in version 1.6.2) is the following
comment:

                 * [snipped] So,
                 * this is just checking for a peer that has that IP/port and
                 * assuming that we have a user of the same name.
This isn't always
                 * correct, but it will be changed if needed after
authentication. */

Sadly, as far as I can tell "it will be changed if needed after
authentication" is attempted, but only incompletely. The problem is
that it is updated during authenticate_verify(), and this is only
called if the user section has a password. If the access is anonymous,
or has no secret, then the original host "guess" is never updated.

I believe a valid fix to this will be to bring the update of the host
field forward into check_access(), where we decide on which user
section we are going to either allow the caller to use, or we decide
which user they must authenticate against.

Can someone sanity check that idea for me? Below is a possible patch
to reflect the above:

--- asterisk-1.6.2.18.orig/channels/chan_iax2.c 2011-03-08
16:38:00.000000000 +0000
+++ asterisk-1.6.2.18/channels/chan_iax2.c      2011-03-08
16:39:00.000000000 +0000
@@ -7436,6 +7436,7 @@
                } else
                        ast_string_field_set(iaxs[callno], secret,
user->secret);
                res = 0;
+               ast_string_field_set(p, host, user->name);
                user = user_unref(user);
        } else {
                 /* user was not found, but we should still fake an AUTHREQ.
@@ -7568,7 +7569,6 @@
                        ast_atomic_fetchadd_int(&user->curauthreq, -1);
                        ast_clear_flag(p, IAX_MAXAUTHREQ);
                }
-               ast_string_field_set(p, host, user->name);
                user = user_unref(user);
        }
        if (ast_test_flag(p, IAX_FORCE_ENCRYPT) && !p->encmethods) {


Thanks,
Steve