On 05/25/2009 11:58 AM, Raúl Alexis Betancor Santana wrote:
On Monday 25 May 2009 08:46:51 you wrote:
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
could you check that the password is ok in your phone? Try to auth using other phone/tool (sipsak) ...
Cheers, Daniel
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:
On Monday 25 May 2009 08:46:51 you wrote:
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
could you check that the password is ok in your phone? Try to auth using other phone/tool (sipsak) ...
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 ?
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@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.
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 ?
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 :)
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
On Wednesday 27 May 2009 07:36:44 Daniel-Constantin Mierla wrote:
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?
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
-
Daniel-Constantin Mierla -
Raúl Alexis Betancor Santana -
Saúl Ibarra