25 May
2009
25 May
'09
12:14 p.m.
On 05/25/2009 11:58 AM, Raúl Alexis Betancor Santana wrote:
On Monday 25 May 2009 08:46:51 you wrote:
could you
check that the password is ok in your phone? Try to auth using
other phone/tool (sipsak) ...
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com/
there were no radical changes to auth modules,
afaik, do not know about
postgres. Can you run in debug mode and see why second 401 is sent? Also
return code $rc will show some hints if you print it with xlog?
Here is a debug=6 output
[...]
May 25 09:47:59 [13194] DBG:auth:check_response: our result
= '60045096c392b92f8c7a451fbb09e530'
May 25 09:47:59 [13194] DBG:auth:check_response: authorization faile 
25 May
25 May
12:50 p.m.
New subject: [Kamailio-Users] Auth problems with 1.5.1
On Lunes, 25 de Mayo de 2009 10:14:22 Daniel-Constantin Mierla escribió:
On 05/25/2009 11:58 AM, Raúl Alexis Betancor Santana
wrote:
I know it's ok because this is what I done:
-openser-1.3.2 running ok
-stop openser 1.3.2
-psql voip3 < upgradeToKam151.sql (it does not touch auth tables, only
carrierroute and LCR)
-start kamailio 1.5.1 (same .cfg as openser 1.3.2, only the needed changes
comented on the upgrade-1.4.X-TO-1.5.X wiki doc)
Anything have been changed on the phones.
Any other debug i could do ?
--
Raúl Alexis Betancor Santana
Dimensión Virtual S.L.
On Monday 25 May 2009 08:46:51 you wrote:
could you check that the password is ok in your phone? Try to auth using
other phone/tool (sipsak) ... there were no radical changes to auth modules,
afaik, do not know about
postgres. Can you run in debug mode and see why second 401 is sent? Also
return code $rc will show some hints if you print it with xlog?
Here is a debug=6 output
[...]
May 25 09:47:59 [13194] DBG:auth:check_response: our result
= '60045096c392b92f8c7a451fbb09e530'
May 25 09:47:59 [13194] DBG:auth:check_response: authorization faile
26 May
26 May
1:52 a.m.
New subject: [Kamailio-Users] Auth problems with 1.5.1
Hi all,
I have retest and don't know what's happens, because it doesn't run.
That is what a I did, step by step:
- edit kamctlrc and set all DB related params
- kamdbctl create (all ok)
- kamctl add 185(a)192.168.2.130 kajun (all ok)
- start kamailio 1.5.1
- Force the Snom360 phone to REGISTER
ngrep trace:
#
U 2009/05/25 23:44:37.689150 192.168.2.119:2048 -> 192.168.2.130:5060
REGISTER sip:192.168.2.130 SIP/2.0
Via: SIP/2.0/UDP 192.168.2.119:2048;branch=z9hG4bK-8mrgci7gcjq9;rport
From: <sip:185@192.168.2.130>;tag=7l7xgqxf5f
To: <sip:185@192.168.2.130>
Call-ID: 3c282b0cc303-jlk76rjijtqs
CSeq: 546 REGISTER
Max-Forwards: 70
Contact: <sip:185@192.168.2.119:2048;line=b5fdc3kc>;flow-id=1;q=1.0;
+sip.instance="<urn:uuid:2748f855-1f70-45c6-9ffd-50e2b11628da>";audio;mobility="fixed";duplex="full";description="snom360";actor="principal";events="dialog";methods="INVITE,ACK,CANCEL,BYE,REFER,OPTIONS,NOTIFY,SUBSCRIBE,PRACK,MESSAGE,INFO"
User-Agent: snom360/7.1.30
Supported: gruu
Allow-Events: dialog
X-Real-IP: 192.168.2.119
Expires: 3600
Content-Length: 0
#
U 2009/05/25 23:44:37.689458 192.168.2.130:5060 -> 192.168.2.119:2048
SIP/2.0 100 Trying
Via: SIP/2.0/UDP
192.168.2.119:2048;branch=z9hG4bK-8mrgci7gcjq9;rport=2048;received=192.168.2.119
From: <sip:185@192.168.2.130>;tag=7l7xgqxf5f
To: <sip:185@192.168.2.130>
Call-ID: 3c282b0cc303-jlk76rjijtqs
CSeq: 546 REGISTER
Server: Kamailio (1.5.1-notls (i386/linux))
Content-Length: 0
#
U 2009/05/25 23:44:37.689687 192.168.2.130:5060 -> 192.168.2.119:2048
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP
192.168.2.119:2048;branch=z9hG4bK-8mrgci7gcjq9;rport=2048;received=192.168.2.119
From: <sip:185@192.168.2.130>;tag=7l7xgqxf5f
To: <sip:185@192.168.2.130>;tag=f8f2ab2c1295e90ed7dbb499b30f44b2.fb06
Call-ID: 3c282b0cc303-jlk76rjijtqs
CSeq: 546 REGISTER
WWW-Authenticate: Digest realm="192.168.2.130",
nonce="4a1b20810000000748f00008d2fae44c0a31cce41858b148"
Server: Kamailio (1.5.1-notls (i386/linux))
Content-Length: 0
#
U 2009/05/25 23:44:37.907937 192.168.2.119:2048 -> 192.168.2.130:5060
REGISTER sip:192.168.2.130 SIP/2.0
Via: SIP/2.0/UDP 192.168.2.119:2048;branch=z9hG4bK-untugk2mv3id;rport
From: <sip:185@192.168.2.130>;tag=7l7xgqxf5f
To: <sip:185@192.168.2.130>
Call-ID: 3c282b0cc303-jlk76rjijtqs
CSeq: 547 REGISTER
Max-Forwards: 70
Contact: <sip:185@192.168.2.119:2048;line=b5fdc3kc>;flow-id=1;q=1.0;
+sip.instance="<urn:uuid:2748f855-1f70-45c6-9ffd-50e2b11628da>";audio;mobility="fixed";duplex="full";description="snom360";actor="principal";events="dialog";methods="INVITE,ACK,CANCEL,BYE,REFER,OPTIONS,NOTIFY,SUBSCRIBE,PRACK,MESSAGE,INFO"
User-Agent: snom360/7.1.30
Supported: gruu
Allow-Events: dialog
X-Real-IP: 192.168.2.119
Authorization: Digest
username="185",realm="192.168.2.130",nonce="4a1b20810000000748f00008d2fae44c0a31cce41858b148",uri="sip:192.168.2.130",response="619143fed6a91de711026326d4bf0e67",algorithm=MD5
Expires: 3600
Content-Length: 0
#
U 2009/05/25 23:44:37.908456 192.168.2.130:5060 -> 192.168.2.119:2048
SIP/2.0 100 Trying
Via: SIP/2.0/UDP
192.168.2.119:2048;branch=z9hG4bK-untugk2mv3id;rport=2048;received=192.168.2.119
From: <sip:185@192.168.2.130>;tag=7l7xgqxf5f
To: <sip:185@192.168.2.130>
Call-ID: 3c282b0cc303-jlk76rjijtqs
CSeq: 547 REGISTER
Server: Kamailio (1.5.1-notls (i386/linux))
Content-Length: 0
#
U 2009/05/25 23:44:37.965604 192.168.2.130:5060 -> 192.168.2.119:2048
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP
192.168.2.119:2048;branch=z9hG4bK-untugk2mv3id;rport=2048;received=192.168.2.119
From: <sip:185@192.168.2.130>;tag=7l7xgqxf5f
To: <sip:185@192.168.2.130>;tag=f8f2ab2c1295e90ed7dbb499b30f44b2.f66d
Call-ID: 3c282b0cc303-jlk76rjijtqs
CSeq: 547 REGISTER
WWW-Authenticate: Digest realm="192.168.2.130",
nonce="4a1b208100000008470ae7a9af3aba2178f305584e6cf034"
Server: Kamailio (1.5.1-notls (i386/linux))
Content-Length: 0
############
Syslog output:
May 25 23:44:37 salma sbc01[21984]: New request BI:0 - M=REGISTER
RURI=sip:192.168.2.130 F=sip:185@192.168.2.130 T=sip:185@192.168.2.130
IP=192.168.2.119 ID=3c282b0cc303-jlk76rjijtqs
May 25 23:44:37 salma sbc01[21984]: Register authentication failed BI:0 -
M=REGISTER RURI=sip:192.168.2.130 F=sip:185@192.168.2.130
T=sip:185@192.168.2.130 IP=192.168.2.119 ID=3c282b0cc303-jlk76rjijtqs RC=-4
May 25 23:44:37 salma sbc01[21978]: New request BI:0 - M=REGISTER
RURI=sip:192.168.2.130 F=sip:185@192.168.2.130 T=sip:185@192.168.2.130
IP=192.168.2.119 ID=3c282b0cc303-jlk76rjijtqs
May 25 23:44:37 salma sbc01[21978]: Register authentication failed BI:0 -
M=REGISTER RURI=sip:192.168.2.130 F=sip:185@192.168.2.130
T=sip:185@192.168.2.130 IP=192.168.2.119 ID=3c282b0cc303-jlk76rjijtqs RC=-2
The first -4 rc it's ok, it correspond to the first REGISTER phone sends
without credentials, but second rc -2 could not be OK at all. I have recheck
the password on the phone, I also try with other phones and with sipsak with
the same result.
What I have on the .cfg file is:
[...]
loadmodule "auth.so"
modparam("auth", "nonce_expire", 300)
modparam("auth", "realm_prefix", "sip.")
modparam("auth", "rpid_suffix",
";party=calling;id-type=subscriber;screen=yes")
modparam("auth", "rpid_avp", "$avp(s:rpid)")
loadmodule "auth_db.so"
modparam("auth_db", "db_url",
"postgres://openser:XXXXXXX@localhost:5435/voip5")
modparam("auth_db", "user_column", "username")
modparam("auth_db", "domain_column", "domain")
modparam("auth_db", "password_column", "password")
modparam("auth_db", "password_column_2", "ha1b")
modparam("auth_db", "calculate_ha1", 0)
modparam("auth_db", "use_domain", 1)
modparam("auth_db", "load_credentials",
"$avp(s:caller_uuid)=uuid")
[...]
if(!www_authorize("", "subscriber"))
{
xlog("L_INFO", "Register authentication failed BI:
$T_branch_idx - M=$rm RURI=$ru F=$fu T=$tu IP=$si I
D=$ci RC=$rc\n");
www_challenge("", "0");
exit;
}
[...]
And I have no clue about what is happening, because if I do the same with
openser 1.3.2, all runs ok.
--
Raúl Alexis Betancor Santana
Dimensión Virtual
2:10 a.m.
New subject: [Kamailio-Users] Auth problems with 1.5.1
Also I have seen an extrange output on the debug = 6 level ..
If I change auth_db params to use pre-calculated ha1 values:
modparam("auth_db", "password_column", "ha1")
modparam("auth_db", "password_column_2", "ha1b")
modparam("auth_db", "calculate_ha1", 1)
And force the phone to register, that's what I get as debug output.
May 26 00:04:58 [22485] DBG:db_postgres:db_postgres_free_query:
PQclear(0x883fa18) result set
May 26 00:04:58 [22485] DBG:auth_db:get_ha1: HA1 string calculated:
eb3164915b1274d8e8844beaa0df26ea
May 26 00:04:58 [22485] DBG:auth:check_response: our result
= 'd248738cf8d82563edf4dcfd697ec26b'
May 26 00:04:58 [22485] DBG:auth:check_response: authorization failed
May 26 00:04:58 [22485] DBG:core:db_free_columns: freeing 2 columns
May 26 00:04:58 [22485] DBG:core:db_free_columns: freeing RES_NAMES[0] at
0x819a9d0
May 26 00:04:58 [22485] DBG:core:db_free_columns: freeing RES_NAMES[1] at
0x819a9f0
May 26 00:04:58 [22485] DBG:core:db_free_columns: freeing result names at
0x819a9c0
May 26 00:04:58 [22485] DBG:core:db_free_columns: freeing result types at
0x819a9e0
May 26 00:04:58 [22485] DBG:core:db_free_rows: freeing 1 rows
May 26 00:04:58 [22485] DBG:core:db_free_row: free
VAL_STRING[0] 'b8f7ba23b1521ace86fed28b23b081f5' at 0x819aa40
I have tryed 4/5 times and "HA1 string calculted" and "our result"
values are
allways diferent, and also they never are the same as the values stored on
the DB.
I'm lost here ..., does anyone have problems with 1.5.1 and auth_db ?
--
Raúl Alexis Betancor Santana
Dimensión Virtual
2:03 p.m.
New subject: [Kamailio-Users] Auth problems with 1.5.1
Hi Raúl,
I'm using 1.5.0 version here with no problem. I see you are using
'password' field to store the password and afaik there the passwords
are stored in plaintext. So maybe you can try this:
In kamctlrc file check that you STORE_PLAINTEXT_PW=0.
Use the ha1 field for the password:
modparam("auth_db", "calculate_ha1", 0)
modparam("auth_db", "password_column", "ha1")
Add a new user with kamctl so that the hash is generated.
Hope it helps :)
--
Saúl -- "Nunca subestimes el ancho de banda de un camión lleno de disketes."
----------------------------------------------------------------
http://www.saghul.net/
27 May
27 May
9:36 a.m.
New subject: [Kamailio-Users] Auth problems with 1.5.1
Hello,
On 05/26/2009 02:03 PM, Saúl Ibarra wrote:
Hi Raúl,
I'm using 1.5.0 version here with no problem. I see you are using
'password' field to store the password and afaik there the passwords
are stored in plaintext. So maybe you can try this:
In kamctlrc file check that you STORE_PLAINTEXT_PW=0.
Use the ha1 field for the password:
modparam("auth_db", "calculate_ha1", 0)
modparam("auth_db", "password_column", "ha1")
Add a new user with kamctl so that the hash is generated.
good spot! calculate_ha1 must be set when using plain text password,
Raul, is it working now?
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com/
10:21 a.m.
New subject: [Kamailio-Users] Auth problems with 1.5.1
On Wednesday 27 May 2009 07:36:44 Daniel-Constantin Mierla wrote:
Hello,
On 05/26/2009 02:03 PM, Saúl Ibarra wrote:
Yes it is working now, but I don't undestand why, because on 1.3.2 I have the
calculate_ha1 = 0 and password_colomn = password, and with plain text
passwords on the DB and with ha1 and hb1 = NULL, and it was working !!
Also, the doc say (or I usdestand in that way ...) ...
" If the parameter is set to 1 and the username parameter of credentials
contains also '@domain' (some user agents append the domain to the username
parameter), then the server will use the HA1 values from the column specified
in the 'password_column_2' parameter. If the username parameter doesn't
contain a domain, the server will use the HA1 values from the column given in
the 'password_column' parameter."
What I undestand from that text is that if I set calculate_ha1 to 1, if a
@domain is part of the auth, ha1 column will be used, if not hb1 will be
used. Those two columns are not plaintext passwords ... moreover the doc
say ...
"If the parameter is set to 0 then the HA1 value will be calculated from the
column specified in the 'password_column' parameter. "
And for me that mean that if I have password_column to "password" (plaintext
password), and calculate_ha1 = 0 ... it should works, and it works on 1.3.2
but not in 1.5.1.
Moreover, Saul told me to set password_column = ha1 and calculate_ha1 = 0 and
from what I unsdestand from the docs, that could not works but it works on
1.5.1 !!! ... as I said, it's working now but I don't undestand why.
Best regards
--
Raúl Alexis Betancor Santana
Dimensión Virtual
Hi Raúl,
I'm using 1.5.0 version here with no problem. I see you are using
'password' field to store the password and afaik there the passwords
are stored in plaintext. So maybe you can try this:
In kamctlrc file check that you STORE_PLAINTEXT_PW=0.
Use the ha1 field for the password:
modparam("auth_db", "calculate_ha1", 0)
modparam("auth_db", "password_column", "ha1")
Add a new user with kamctl so that the hash is generated.
good spot! calculate_ha1 must be set when using plain text password,
Raul, is it working now?
5659
days inactive
5661
days old
6 comments
3 participants
participants (3)
-
Daniel-Constantin Mierla -
Raúl Alexis Betancor Santana -
Saúl Ibarra