Hi I do have 3 Kamailio servers, one for mobile phone registrations, one for softphone registrations and one for SIP device registrations. Each of those devices connects to it's perspective kamailio server
sip1.domain.com sip2.domain.com sip3.domain.com
All 3 Kamailio servers share the same database, and users can use their kamailio user/pwd on any of the devices, now I want to use encrypted passwords and remove clear text passwords from the database. I did test with one server and all is fine,however if a user want to register from the second kamailio server it does not work, basically because the db domain entry from which the hash is created is sip1.domain.com and stored in the db, while the user connects from to sip2.domain.com this eventually generates a different hash.
Is there anyway to overcome this ? Can I exclude Domain from Hash generation ? Any other option that allows me to do the above ?
Thanks
Hi After some research it seems to me that the only way to achieve this is to "try" and change how hashing is done in the source code, a little bit too ambitious for me, and it means I will have loads of problems each time an upgrade is released.
Or
Use pseudovariables to fix the value of the $fd value to something constant, while this worked for values like $var(y) I was not able to assign/strip $fd to remove the subdomain part.
Any input please ?
Regards
On Tue, Jan 3, 2012 at 2:06 PM, Ali Jawad ali.jawad@splendor.net wrote:
Hi I do have 3 Kamailio servers, one for mobile phone registrations, one for softphone registrations and one for SIP device registrations. Each of those devices connects to it's perspective kamailio server
sip1.domain.com sip2.domain.com sip3.domain.com
All 3 Kamailio servers share the same database, and users can use their kamailio user/pwd on any of the devices, now I want to use encrypted passwords and remove clear text passwords from the database. I did test with one server and all is fine,however if a user want to register from the second kamailio server it does not work, basically because the db domain entry from which the hash is created is sip1.domain.com and stored in the db, while the user connects from to sip2.domain.com this eventually generates a different hash.
Is there anyway to overcome this ? Can I exclude Domain from Hash generation ? Any other option that allows me to do the above ?
Thanks
Hello,
you can simply use 'domain.com' as realm parameter to authentication function instead of $fd. Also build ha1 and ha1b with domain.com and then you are safe no matter which sip server is used.
Of course you can build the realm by striping first token before '.' in $fd and pass it to authentication functions, but not sure if makes sense since it should be always domain.com
Cheers, Daniel
On 1/3/12 3:15 PM, Ali Jawad wrote:
Hi After some research it seems to me that the only way to achieve this is to "try" and change how hashing is done in the source code, a little bit too ambitious for me, and it means I will have loads of problems each time an upgrade is released.
Or
Use pseudovariables to fix the value of the $fd value to something constant, while this worked for values like $var(y) I was not able to assign/strip $fd to remove the subdomain part.
Any input please ?
Regards
On Tue, Jan 3, 2012 at 2:06 PM, Ali Jawadali.jawad@splendor.net wrote:
Hi I do have 3 Kamailio servers, one for mobile phone registrations, one for softphone registrations and one for SIP device registrations. Each of those devices connects to it's perspective kamailio server
sip1.domain.com sip2.domain.com sip3.domain.com
All 3 Kamailio servers share the same database, and users can use their kamailio user/pwd on any of the devices, now I want to use encrypted passwords and remove clear text passwords from the database. I did test with one server and all is fine,however if a user want to register from the second kamailio server it does not work, basically because the db domain entry from which the hash is created is sip1.domain.com and stored in the db, while the user connects from to sip2.domain.com this eventually generates a different hash.
Is there anyway to overcome this ? Can I exclude Domain from Hash generation ? Any other option that allows me to do the above ?
Thanks
Hi Daniel This certainly makes sense, I will try it in a few mins, but what I observed at Debug Level 3 is that Hash is calculated before www_authenticate is executed and it shows HA comparison failed, if I do use domain.com instead of $fd and use $domain.com in db domain field and build HA1 filed based on that, wont Kamailio still try to build the HA1 hash which it will compare form user:domain:pwd where domain is fed in to the hash function from the header of the SIP packet ? Regards
On Tue, Jan 3, 2012 at 5:07 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
you can simply use 'domain.com' as realm parameter to authentication function instead of $fd. Also build ha1 and ha1b with domain.com and then you are safe no matter which sip server is used.
Of course you can build the realm by striping first token before '.' in $fd and pass it to authentication functions, but not sure if makes sense since it should be always domain.com
Cheers, Daniel
On 1/3/12 3:15 PM, Ali Jawad wrote:
Hi After some research it seems to me that the only way to achieve this is to "try" and change how hashing is done in the source code, a little bit too ambitious for me, and it means I will have loads of problems each time an upgrade is released.
Or
Use pseudovariables to fix the value of the $fd value to something constant, while this worked for values like $var(y) I was not able to assign/strip $fd to remove the subdomain part.
Any input please ?
Regards
On Tue, Jan 3, 2012 at 2:06 PM, Ali Jawadali.jawad@splendor.net wrote:
Hi I do have 3 Kamailio servers, one for mobile phone registrations, one for softphone registrations and one for SIP device registrations. Each of those devices connects to it's perspective kamailio server
sip1.domain.com sip2.domain.com sip3.domain.com
All 3 Kamailio servers share the same database, and users can use their kamailio user/pwd on any of the devices, now I want to use encrypted passwords and remove clear text passwords from the database. I did test with one server and all is fine,however if a user want to register from the second kamailio server it does not work, basically because the db domain entry from which the hash is created is sip1.domain.com and stored in the db, while the user connects from to sip2.domain.com this eventually generates a different hash.
Is there anyway to overcome this ? Can I exclude Domain from Hash generation ? Any other option that allows me to do the above ?
Thanks
-- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda
Hello,
On 1/3/12 4:12 PM, Ali Jawad wrote:
Hi Daniel This certainly makes sense, I will try it in a few mins, but what I observed at Debug Level 3 is that Hash is calculated before www_authenticate is executed and it shows HA comparison failed, if I do use domain.com instead of $fd and use $domain.com in db domain field and build HA1 filed based on that, wont Kamailio still try to build the HA1 hash which it will compare form user:domain:pwd where domain is fed in to the hash function from the header of the SIP packet ?
the ha1 is actually hash over 'user:realm:pwd' -- it is just common practice to use the domain as realm, since realm should be a unique token to identify the service, but it can be any random string. realm is given as parameter to auth functions in kamailio.cfg
Cheers, Daniel
Regards
On Tue, Jan 3, 2012 at 5:07 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
you can simply use 'domain.com' as realm parameter to authentication function instead of $fd. Also build ha1 and ha1b with domain.com and then you are safe no matter which sip server is used.
Of course you can build the realm by striping first token before '.' in $fd and pass it to authentication functions, but not sure if makes sense since it should be always domain.com
Cheers, Daniel
On 1/3/12 3:15 PM, Ali Jawad wrote:
Hi After some research it seems to me that the only way to achieve this is to "try" and change how hashing is done in the source code, a little bit too ambitious for me, and it means I will have loads of problems each time an upgrade is released.
Or
Use pseudovariables to fix the value of the $fd value to something constant, while this worked for values like $var(y) I was not able to assign/strip $fd to remove the subdomain part.
Any input please ?
Regards
On Tue, Jan 3, 2012 at 2:06 PM, Ali Jawadali.jawad@splendor.net wrote:
Hi I do have 3 Kamailio servers, one for mobile phone registrations, one for softphone registrations and one for SIP device registrations. Each of those devices connects to it's perspective kamailio server
sip1.domain.com sip2.domain.com sip3.domain.com
All 3 Kamailio servers share the same database, and users can use their kamailio user/pwd on any of the devices, now I want to use encrypted passwords and remove clear text passwords from the database. I did test with one server and all is fine,however if a user want to register from the second kamailio server it does not work, basically because the db domain entry from which the hash is created is sip1.domain.com and stored in the db, while the user connects from to sip2.domain.com this eventually generates a different hash.
Is there anyway to overcome this ? Can I exclude Domain from Hash generation ? Any other option that allows me to do the above ?
Thanks
-- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda
-- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda
Hi Daniel
Please see
5(18649) DEBUG: <core> [db_res.c:184]: allocate 8 bytes for rows at 0xb7b78d74 5(18649) DEBUG: <core> [db_row.c:119]: allocate 20 bytes for row values at 0xb7b78dac 5(18649) DEBUG: <core> [db_val.c:117]: converting STRING [6f966cd9c628f14cdc20172f96a4d065] 5(18649) DEBUG: auth [api.c:210]: check_response: Our result = '6f95e6235edca0b7765042ef119fd83b' 5(18649) DEBUG: auth [api.c:220]: check_response: Authorization failed 5(18649) DEBUG: <core> [db_res.c:81]: freeing 1 columns 5(18649) DEBUG: <core> [db_res.c:85]: freeing RES_NAMES[0] at 0xb7b78d3c 5(18649) DEBUG: <core> [db_res.c:94]: freeing result names at 0xb7b78bfc 5(18649) DEBUG: <core> [db_res.c:99]: freeing result types at 0xb7b78c64 5(18649) DEBUG: <core> [db_res.c:54]: freeing 1 rows 5(18649) DEBUG: <core> [db_row.c:97]: freeing row values at 0xb7b78dac 5(18649) DEBUG: <core> [db_res.c:62]: freeing rows at 0xb7b78d74 5(18649) DEBUG: <core> [db_res.c:136]: freeing result set at 0xb7b78bb0 5(18649) DEBUG: auth [challenge.c:102]: build_challenge_hf: realm='nymgo.com' 5(18649) DEBUG: auth [challenge.c:244]: auth: 'WWW-Authenticate: Digest realm="domain.com", nonce="TwMcuk8DG47SLxatlNdZfyfR8p3OiyAE" '
I rebuilt the hashes against domain.com and then tried to connect to sip1.domain.com and sip2.domain.com and sip3.domain.com with all of the having
# ----- auth_db params ----- #!ifdef WITH_AUTH modparam("auth_db", "db_url", DBURL) modparam("auth_db", "calculate_ha1", 0 ) modparam("auth_db", "password_column", "ha1") modparam("auth_db", "load_credentials", "") modparam("auth_db", "use_domain", MULTIDOMAIN)
And in the routing process :
if (!www_authorize("domain.com", "subscriber")) {
www_challenge("domain.com", "0"); exit; }
+++++++++++++
My point is that the hashes are caculated from user:doman:pwd which are extracted from the SIP packet and in this case the domains are sip1,sip2,sip3 while the hashes stored in the database are generated against domain.com
If " ha1 is actually hash over 'user:realm:pwd' " shouldn't I have to set the domain/realm in the config file ?
I might be wrong....thanks for the help so far.
Regards
On Tue, Jan 3, 2012 at 5:15 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
On 1/3/12 4:12 PM, Ali Jawad wrote:
Hi Daniel This certainly makes sense, I will try it in a few mins, but what I observed at Debug Level 3 is that Hash is calculated before www_authenticate is executed and it shows HA comparison failed, if I do use domain.com instead of $fd and use $domain.com in db domain field and build HA1 filed based on that, wont Kamailio still try to build the HA1 hash which it will compare form user:domain:pwd where domain is fed in to the hash function from the header of the SIP packet ?
the ha1 is actually hash over 'user:realm:pwd' -- it is just common practice to use the domain as realm, since realm should be a unique token to identify the service, but it can be any random string. realm is given as parameter to auth functions in kamailio.cfg
Cheers, Daniel
Regards
On Tue, Jan 3, 2012 at 5:07 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
you can simply use 'domain.com' as realm parameter to authentication function instead of $fd. Also build ha1 and ha1b with domain.com and then you are safe no matter which sip server is used.
Of course you can build the realm by striping first token before '.' in $fd and pass it to authentication functions, but not sure if makes sense since it should be always domain.com
Cheers, Daniel
On 1/3/12 3:15 PM, Ali Jawad wrote:
Hi After some research it seems to me that the only way to achieve this is to "try" and change how hashing is done in the source code, a little bit too ambitious for me, and it means I will have loads of problems each time an upgrade is released.
Or
Use pseudovariables to fix the value of the $fd value to something constant, while this worked for values like $var(y) I was not able to assign/strip $fd to remove the subdomain part.
Any input please ?
Regards
On Tue, Jan 3, 2012 at 2:06 PM, Ali Jawadali.jawad@splendor.net wrote:
Hi I do have 3 Kamailio servers, one for mobile phone registrations, one for softphone registrations and one for SIP device registrations. Each of those devices connects to it's perspective kamailio server
sip1.domain.com sip2.domain.com sip3.domain.com
All 3 Kamailio servers share the same database, and users can use their kamailio user/pwd on any of the devices, now I want to use encrypted passwords and remove clear text passwords from the database. I did test with one server and all is fine,however if a user want to register from the second kamailio server it does not work, basically because the db domain entry from which the hash is created is sip1.domain.com and stored in the db, while the user connects from to sip2.domain.com this eventually generates a different hash.
Is there anyway to overcome this ? Can I exclude Domain from Hash generation ? Any other option that allows me to do the above ?
Thanks
-- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda
-- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda
I.e. I get
5(18649) DEBUG: <core> [db_val.c:117]: converting STRING [6f966cd9c628f14cdc20172f96a4d065] 5(18649) DEBUG: auth [api.c:210]: check_response: Our result = '6f95e6235edca0b7765042ef119fd83b' 5(18649) DEBUG: auth [api.c:220]: check_response: Authorization failed
Before I get to the part below.
5(18649) DEBUG: auth [challenge.c:102]: build_challenge_hf: realm='domain.com' 5(18649) DEBUG: auth [challenge.c:244]: auth: 'WWW-Authenticate: Digest realm="domain.com", nonce="TwMcuk8DG47SLxatlNdZfyfR8p3OiyAE"
On Tue, Jan 3, 2012 at 5:48 PM, Ali Jawad ali.jawad@splendor.net wrote:
Hi Daniel
Please see
5(18649) DEBUG: <core> [db_res.c:184]: allocate 8 bytes for rows at 0xb7b78d74 5(18649) DEBUG: <core> [db_row.c:119]: allocate 20 bytes for row values at 0xb7b78dac 5(18649) DEBUG: <core> [db_val.c:117]: converting STRING [6f966cd9c628f14cdc20172f96a4d065] 5(18649) DEBUG: auth [api.c:210]: check_response: Our result = '6f95e6235edca0b7765042ef119fd83b' 5(18649) DEBUG: auth [api.c:220]: check_response: Authorization failed 5(18649) DEBUG: <core> [db_res.c:81]: freeing 1 columns 5(18649) DEBUG: <core> [db_res.c:85]: freeing RES_NAMES[0] at 0xb7b78d3c 5(18649) DEBUG: <core> [db_res.c:94]: freeing result names at 0xb7b78bfc 5(18649) DEBUG: <core> [db_res.c:99]: freeing result types at 0xb7b78c64 5(18649) DEBUG: <core> [db_res.c:54]: freeing 1 rows 5(18649) DEBUG: <core> [db_row.c:97]: freeing row values at 0xb7b78dac 5(18649) DEBUG: <core> [db_res.c:62]: freeing rows at 0xb7b78d74 5(18649) DEBUG: <core> [db_res.c:136]: freeing result set at 0xb7b78bb0 5(18649) DEBUG: auth [challenge.c:102]: build_challenge_hf: realm='nymgo.com' 5(18649) DEBUG: auth [challenge.c:244]: auth: 'WWW-Authenticate: Digest realm="domain.com", nonce="TwMcuk8DG47SLxatlNdZfyfR8p3OiyAE" '
I rebuilt the hashes against domain.com and then tried to connect to sip1.domain.com and sip2.domain.com and sip3.domain.com with all of the having
# ----- auth_db params ----- #!ifdef WITH_AUTH modparam("auth_db", "db_url", DBURL) modparam("auth_db", "calculate_ha1", 0 ) modparam("auth_db", "password_column", "ha1") modparam("auth_db", "load_credentials", "") modparam("auth_db", "use_domain", MULTIDOMAIN)
And in the routing process :
if (!www_authorize("domain.com", "subscriber")) {
www_challenge("domain.com", "0"); exit; }
+++++++++++++
My point is that the hashes are caculated from user:doman:pwd which are extracted from the SIP packet and in this case the domains are sip1,sip2,sip3 while the hashes stored in the database are generated against domain.com
If " ha1 is actually hash over 'user:realm:pwd' " shouldn't I have to set the domain/realm in the config file ?
I might be wrong....thanks for the help so far.
Regards
On Tue, Jan 3, 2012 at 5:15 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
On 1/3/12 4:12 PM, Ali Jawad wrote:
Hi Daniel This certainly makes sense, I will try it in a few mins, but what I observed at Debug Level 3 is that Hash is calculated before www_authenticate is executed and it shows HA comparison failed, if I do use domain.com instead of $fd and use $domain.com in db domain field and build HA1 filed based on that, wont Kamailio still try to build the HA1 hash which it will compare form user:domain:pwd where domain is fed in to the hash function from the header of the SIP packet ?
the ha1 is actually hash over 'user:realm:pwd' -- it is just common practice to use the domain as realm, since realm should be a unique token to identify the service, but it can be any random string. realm is given as parameter to auth functions in kamailio.cfg
Cheers, Daniel
Regards
On Tue, Jan 3, 2012 at 5:07 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
you can simply use 'domain.com' as realm parameter to authentication function instead of $fd. Also build ha1 and ha1b with domain.com and then you are safe no matter which sip server is used.
Of course you can build the realm by striping first token before '.' in $fd and pass it to authentication functions, but not sure if makes sense since it should be always domain.com
Cheers, Daniel
On 1/3/12 3:15 PM, Ali Jawad wrote:
Hi After some research it seems to me that the only way to achieve this is to "try" and change how hashing is done in the source code, a little bit too ambitious for me, and it means I will have loads of problems each time an upgrade is released.
Or
Use pseudovariables to fix the value of the $fd value to something constant, while this worked for values like $var(y) I was not able to assign/strip $fd to remove the subdomain part.
Any input please ?
Regards
On Tue, Jan 3, 2012 at 2:06 PM, Ali Jawadali.jawad@splendor.net wrote:
Hi I do have 3 Kamailio servers, one for mobile phone registrations, one for softphone registrations and one for SIP device registrations. Each of those devices connects to it's perspective kamailio server
sip1.domain.com sip2.domain.com sip3.domain.com
All 3 Kamailio servers share the same database, and users can use their kamailio user/pwd on any of the devices, now I want to use encrypted passwords and remove clear text passwords from the database. I did test with one server and all is fine,however if a user want to register from the second kamailio server it does not work, basically because the db domain entry from which the hash is created is sip1.domain.com and stored in the db, while the user connects from to sip2.domain.com this eventually generates a different hash.
Is there anyway to overcome this ? Can I exclude Domain from Hash generation ? Any other option that allows me to do the above ?
Thanks
-- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda
-- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda
-- Ali Jawad Information Systems Manager Splendor Telecom (www.splendor.net) Beirut, Lebanon Phone: +9611373725/ext 116 FAX: +9611375554
Hello,
On 1/3/12 4:48 PM, Ali Jawad wrote:
Hi Daniel
Please see
5(18649) DEBUG:<core> [db_res.c:184]: allocate 8 bytes for rows at 0xb7b78d74 5(18649) DEBUG:<core> [db_row.c:119]: allocate 20 bytes for row values at 0xb7b78dac 5(18649) DEBUG:<core> [db_val.c:117]: converting STRING [6f966cd9c628f14cdc20172f96a4d065] 5(18649) DEBUG: auth [api.c:210]: check_response: Our result = '6f95e6235edca0b7765042ef119fd83b' 5(18649) DEBUG: auth [api.c:220]: check_response: Authorization failed 5(18649) DEBUG:<core> [db_res.c:81]: freeing 1 columns 5(18649) DEBUG:<core> [db_res.c:85]: freeing RES_NAMES[0] at 0xb7b78d3c 5(18649) DEBUG:<core> [db_res.c:94]: freeing result names at 0xb7b78bfc 5(18649) DEBUG:<core> [db_res.c:99]: freeing result types at 0xb7b78c64 5(18649) DEBUG:<core> [db_res.c:54]: freeing 1 rows 5(18649) DEBUG:<core> [db_row.c:97]: freeing row values at 0xb7b78dac 5(18649) DEBUG:<core> [db_res.c:62]: freeing rows at 0xb7b78d74 5(18649) DEBUG:<core> [db_res.c:136]: freeing result set at 0xb7b78bb0 5(18649) DEBUG: auth [challenge.c:102]: build_challenge_hf: realm='nymgo.com' 5(18649) DEBUG: auth [challenge.c:244]: auth: 'WWW-Authenticate: Digest realm="domain.com", nonce="TwMcuk8DG47SLxatlNdZfyfR8p3OiyAE" '
I rebuilt the hashes against domain.com and then tried to connect to sip1.domain.com and sip2.domain.com and sip3.domain.com with all of the having
# ----- auth_db params ----- #!ifdef WITH_AUTH modparam("auth_db", "db_url", DBURL) modparam("auth_db", "calculate_ha1", 0 ) modparam("auth_db", "password_column", "ha1") modparam("auth_db", "load_credentials", "") modparam("auth_db", "use_domain", MULTIDOMAIN)
And in the routing process :
if (!www_authorize("domain.com", "subscriber")) { www_challenge("domain.com", "0"); exit; }+++++++++++++
My point is that the hashes are caculated from user:doman:pwd which are extracted from the SIP packet and in this case the domains are sip1,sip2,sip3 while the hashes stored in the database are generated against domain.com
If " ha1 is actually hash over 'user:realm:pwd' " shouldn't I have to set the domain/realm in the config file ?
the first parameter in www_authorize and www_challenge functions is the realm and it is used to build the digest response.
Is your phone putting user@domain in authorization header? Can you paste here the ngrep of registration?
Cheers, Daniel
I might be wrong....thanks for the help so far.
Regards
On Tue, Jan 3, 2012 at 5:15 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
On 1/3/12 4:12 PM, Ali Jawad wrote:
Hi Daniel This certainly makes sense, I will try it in a few mins, but what I observed at Debug Level 3 is that Hash is calculated before www_authenticate is executed and it shows HA comparison failed, if I do use domain.com instead of $fd and use $domain.com in db domain field and build HA1 filed based on that, wont Kamailio still try to build the HA1 hash which it will compare form user:domain:pwd where domain is fed in to the hash function from the header of the SIP packet ?
the ha1 is actually hash over 'user:realm:pwd' -- it is just common practice to use the domain as realm, since realm should be a unique token to identify the service, but it can be any random string. realm is given as parameter to auth functions in kamailio.cfg
Cheers, Daniel
Regards
On Tue, Jan 3, 2012 at 5:07 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
you can simply use 'domain.com' as realm parameter to authentication function instead of $fd. Also build ha1 and ha1b with domain.com and then you are safe no matter which sip server is used.
Of course you can build the realm by striping first token before '.' in $fd and pass it to authentication functions, but not sure if makes sense since it should be always domain.com
Cheers, Daniel
On 1/3/12 3:15 PM, Ali Jawad wrote:
Hi After some research it seems to me that the only way to achieve this is to "try" and change how hashing is done in the source code, a little bit too ambitious for me, and it means I will have loads of problems each time an upgrade is released.
Or
Use pseudovariables to fix the value of the $fd value to something constant, while this worked for values like $var(y) I was not able to assign/strip $fd to remove the subdomain part.
Any input please ?
Regards
On Tue, Jan 3, 2012 at 2:06 PM, Ali Jawadali.jawad@splendor.net wrote:
Hi I do have 3 Kamailio servers, one for mobile phone registrations, one for softphone registrations and one for SIP device registrations. Each of those devices connects to it's perspective kamailio server
sip1.domain.com sip2.domain.com sip3.domain.com
All 3 Kamailio servers share the same database, and users can use their kamailio user/pwd on any of the devices, now I want to use encrypted passwords and remove clear text passwords from the database. I did test with one server and all is fine,however if a user want to register from the second kamailio server it does not work, basically because the db domain entry from which the hash is created is sip1.domain.com and stored in the db, while the user connects from to sip2.domain.com this eventually generates a different hash.
Is there anyway to overcome this ? Can I exclude Domain from Hash generation ? Any other option that allows me to do the above ?
Thanks
-- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda
-- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda
Hi Please see the ngrep below, please note that if I use in the db register.domain.com and generate a hash against it for HA1 it works,but then the user cant logon to register2.domain.com
U +10.630576 xx.yy.yy.yy:20020 -> xx.xx.xx.xx:5060 REGISTER sip:register.domain SIP/2.0. Via: SIP/2.0/UDP 192.168.0.191:20020;branch=z9hG4bK-d8754z-af65a442980c375f-1---d8754z-;rport. Max-Forwards: 70. Contact: sip:support1@192.168.0.191:20020;rinstance=4009190a4e109ac6;transport=udp. To: "Test Ast"sip:support1@register.domain. From: "Test Ast"sip:support1@register.domain;tag=976bb004. Call-ID: MDFmZDU2ZTI2YjJjMGNlMGFmOTIzMWFmZGQ1ZTNjMDE.. CSeq: 1 REGISTER. Expires: 3600. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. User-Agent: eyeBeam release 1102q stamp 51814. Content-Length: 0.
On Tue, Jan 3, 2012 at 5:58 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
On 1/3/12 4:48 PM, Ali Jawad wrote:
Hi Daniel
Please see
5(18649) DEBUG:<core> [db_res.c:184]: allocate 8 bytes for rows at 0xb7b78d74 5(18649) DEBUG:<core> [db_row.c:119]: allocate 20 bytes for row values at 0xb7b78dac 5(18649) DEBUG:<core> [db_val.c:117]: converting STRING [6f966cd9c628f14cdc20172f96a4d065] 5(18649) DEBUG: auth [api.c:210]: check_response: Our result = '6f95e6235edca0b7765042ef119fd83b' 5(18649) DEBUG: auth [api.c:220]: check_response: Authorization failed 5(18649) DEBUG:<core> [db_res.c:81]: freeing 1 columns 5(18649) DEBUG:<core> [db_res.c:85]: freeing RES_NAMES[0] at 0xb7b78d3c 5(18649) DEBUG:<core> [db_res.c:94]: freeing result names at 0xb7b78bfc 5(18649) DEBUG:<core> [db_res.c:99]: freeing result types at 0xb7b78c64 5(18649) DEBUG:<core> [db_res.c:54]: freeing 1 rows 5(18649) DEBUG:<core> [db_row.c:97]: freeing row values at 0xb7b78dac 5(18649) DEBUG:<core> [db_res.c:62]: freeing rows at 0xb7b78d74 5(18649) DEBUG:<core> [db_res.c:136]: freeing result set at 0xb7b78bb0 5(18649) DEBUG: auth [challenge.c:102]: build_challenge_hf: realm='nymgo.com' 5(18649) DEBUG: auth [challenge.c:244]: auth: 'WWW-Authenticate: Digest realm="domain.com", nonce="TwMcuk8DG47SLxatlNdZfyfR8p3OiyAE" '
I rebuilt the hashes against domain.com and then tried to connect to sip1.domain.com and sip2.domain.com and sip3.domain.com with all of the having
# ----- auth_db params ----- #!ifdef WITH_AUTH modparam("auth_db", "db_url", DBURL) modparam("auth_db", "calculate_ha1", 0 ) modparam("auth_db", "password_column", "ha1") modparam("auth_db", "load_credentials", "") modparam("auth_db", "use_domain", MULTIDOMAIN)
And in the routing process :
if (!www_authorize("domain.com", "subscriber")) {
www_challenge("domain.com", "0"); exit; }
+++++++++++++
My point is that the hashes are caculated from user:doman:pwd which are extracted from the SIP packet and in this case the domains are sip1,sip2,sip3 while the hashes stored in the database are generated against domain.com
If " ha1 is actually hash over 'user:realm:pwd' " shouldn't I have to set the domain/realm in the config file ?
the first parameter in www_authorize and www_challenge functions is the realm and it is used to build the digest response.
Is your phone putting user@domain in authorization header? Can you paste here the ngrep of registration?
Cheers, Daniel
I might be wrong....thanks for the help so far.
Regards
On Tue, Jan 3, 2012 at 5:15 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
On 1/3/12 4:12 PM, Ali Jawad wrote:
Hi Daniel This certainly makes sense, I will try it in a few mins, but what I observed at Debug Level 3 is that Hash is calculated before www_authenticate is executed and it shows HA comparison failed, if I do use domain.com instead of $fd and use $domain.com in db domain field and build HA1 filed based on that, wont Kamailio still try to build the HA1 hash which it will compare form user:domain:pwd where domain is fed in to the hash function from the header of the SIP packet ?
the ha1 is actually hash over 'user:realm:pwd' -- it is just common practice to use the domain as realm, since realm should be a unique token to identify the service, but it can be any random string. realm is given as parameter to auth functions in kamailio.cfg
Cheers, Daniel
Regards
On Tue, Jan 3, 2012 at 5:07 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
you can simply use 'domain.com' as realm parameter to authentication function instead of $fd. Also build ha1 and ha1b with domain.com and then you are safe no matter which sip server is used.
Of course you can build the realm by striping first token before '.' in $fd and pass it to authentication functions, but not sure if makes sense since it should be always domain.com
Cheers, Daniel
On 1/3/12 3:15 PM, Ali Jawad wrote:
Hi After some research it seems to me that the only way to achieve this is to "try" and change how hashing is done in the source code, a little bit too ambitious for me, and it means I will have loads of problems each time an upgrade is released.
Or
Use pseudovariables to fix the value of the $fd value to something constant, while this worked for values like $var(y) I was not able to assign/strip $fd to remove the subdomain part.
Any input please ?
Regards
On Tue, Jan 3, 2012 at 2:06 PM, Ali Jawadali.jawad@splendor.net wrote: > > Hi > I do have 3 Kamailio servers, one for mobile phone registrations, one > for softphone registrations and one for SIP device registrations. > Each > of those devices connects to it's perspective kamailio server > > sip1.domain.com > sip2.domain.com > sip3.domain.com > > All 3 Kamailio servers share the same database, and users can use > their kamailio user/pwd on any of the devices, now I want to use > encrypted passwords and remove clear text passwords from the > database. > I did test with one server and all is fine,however if a user want to > register from the second kamailio server it does not work, basically > because the db domain entry from which the hash is created is > sip1.domain.com and stored in the db, while the user connects from to > sip2.domain.com this eventually generates a different hash. > > Is there anyway to overcome this ? Can I exclude Domain from Hash > generation ? Any other option that allows me to do the above ? > > Thanks
-- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda
-- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda
-- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda
Hello,
I need the entire flow for registration, including the 401 reply and the following REGISTER request.
Cheers, Daniel
On 1/3/12 5:02 PM, Ali Jawad wrote:
Hi Please see the ngrep below, please note that if I use in the db register.domain.com and generate a hash against it for HA1 it works,but then the user cant logon to register2.domain.com
U +10.630576 xx.yy.yy.yy:20020 -> xx.xx.xx.xx:5060 REGISTER sip:register.domain SIP/2.0. Via: SIP/2.0/UDP 192.168.0.191:20020;branch=z9hG4bK-d8754z-af65a442980c375f-1---d8754z-;rport. Max-Forwards: 70. Contact:sip:support1@192.168.0.191:20020;rinstance=4009190a4e109ac6;transport=udp. To: "Test Ast"sip:support1@register.domain. From: "Test Ast"sip:support1@register.domain;tag=976bb004. Call-ID: MDFmZDU2ZTI2YjJjMGNlMGFmOTIzMWFmZGQ1ZTNjMDE.. CSeq: 1 REGISTER. Expires: 3600. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. User-Agent: eyeBeam release 1102q stamp 51814. Content-Length: 0.
On Tue, Jan 3, 2012 at 5:58 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
On 1/3/12 4:48 PM, Ali Jawad wrote:
Hi Daniel
Please see
5(18649) DEBUG:<core> [db_res.c:184]: allocate 8 bytes for rows at 0xb7b78d74 5(18649) DEBUG:<core> [db_row.c:119]: allocate 20 bytes for row values at 0xb7b78dac 5(18649) DEBUG:<core> [db_val.c:117]: converting STRING [6f966cd9c628f14cdc20172f96a4d065] 5(18649) DEBUG: auth [api.c:210]: check_response: Our result = '6f95e6235edca0b7765042ef119fd83b' 5(18649) DEBUG: auth [api.c:220]: check_response: Authorization failed 5(18649) DEBUG:<core> [db_res.c:81]: freeing 1 columns 5(18649) DEBUG:<core> [db_res.c:85]: freeing RES_NAMES[0] at 0xb7b78d3c 5(18649) DEBUG:<core> [db_res.c:94]: freeing result names at 0xb7b78bfc 5(18649) DEBUG:<core> [db_res.c:99]: freeing result types at 0xb7b78c64 5(18649) DEBUG:<core> [db_res.c:54]: freeing 1 rows 5(18649) DEBUG:<core> [db_row.c:97]: freeing row values at 0xb7b78dac 5(18649) DEBUG:<core> [db_res.c:62]: freeing rows at 0xb7b78d74 5(18649) DEBUG:<core> [db_res.c:136]: freeing result set at 0xb7b78bb0 5(18649) DEBUG: auth [challenge.c:102]: build_challenge_hf: realm='nymgo.com' 5(18649) DEBUG: auth [challenge.c:244]: auth: 'WWW-Authenticate: Digest realm="domain.com", nonce="TwMcuk8DG47SLxatlNdZfyfR8p3OiyAE" '
I rebuilt the hashes against domain.com and then tried to connect to sip1.domain.com and sip2.domain.com and sip3.domain.com with all of the having
# ----- auth_db params ----- #!ifdef WITH_AUTH modparam("auth_db", "db_url", DBURL) modparam("auth_db", "calculate_ha1", 0 ) modparam("auth_db", "password_column", "ha1") modparam("auth_db", "load_credentials", "") modparam("auth_db", "use_domain", MULTIDOMAIN)
And in the routing process :
if (!www_authorize("domain.com", "subscriber")) { www_challenge("domain.com", "0"); exit; }+++++++++++++
My point is that the hashes are caculated from user:doman:pwd which are extracted from the SIP packet and in this case the domains are sip1,sip2,sip3 while the hashes stored in the database are generated against domain.com
If " ha1 is actually hash over 'user:realm:pwd' " shouldn't I have to set the domain/realm in the config file ?
the first parameter in www_authorize and www_challenge functions is the realm and it is used to build the digest response.
Is your phone putting user@domain in authorization header? Can you paste here the ngrep of registration?
Cheers, Daniel
I might be wrong....thanks for the help so far.
Regards
On Tue, Jan 3, 2012 at 5:15 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
On 1/3/12 4:12 PM, Ali Jawad wrote:
Hi Daniel This certainly makes sense, I will try it in a few mins, but what I observed at Debug Level 3 is that Hash is calculated before www_authenticate is executed and it shows HA comparison failed, if I do use domain.com instead of $fd and use $domain.com in db domain field and build HA1 filed based on that, wont Kamailio still try to build the HA1 hash which it will compare form user:domain:pwd where domain is fed in to the hash function from the header of the SIP packet ?
the ha1 is actually hash over 'user:realm:pwd' -- it is just common practice to use the domain as realm, since realm should be a unique token to identify the service, but it can be any random string. realm is given as parameter to auth functions in kamailio.cfg
Cheers, Daniel
Regards
On Tue, Jan 3, 2012 at 5:07 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
you can simply use 'domain.com' as realm parameter to authentication function instead of $fd. Also build ha1 and ha1b with domain.com and then you are safe no matter which sip server is used.
Of course you can build the realm by striping first token before '.' in $fd and pass it to authentication functions, but not sure if makes sense since it should be always domain.com
Cheers, Daniel
On 1/3/12 3:15 PM, Ali Jawad wrote: > Hi > After some research it seems to me that the only way to achieve this > is to "try" and change how hashing is done in the source code, a > little bit too ambitious for me, and it means I will have loads of > problems each time an upgrade is released. > > Or > > Use pseudovariables to fix the value of the $fd value to something > constant, while this worked for values like $var(y) I was not able to > assign/strip $fd to remove the subdomain part. > > Any input please ? > > Regards > > On Tue, Jan 3, 2012 at 2:06 PM, Ali Jawadali.jawad@splendor.net > wrote: >> Hi >> I do have 3 Kamailio servers, one for mobile phone registrations, one >> for softphone registrations and one for SIP device registrations. >> Each >> of those devices connects to it's perspective kamailio server >> >> sip1.domain.com >> sip2.domain.com >> sip3.domain.com >> >> All 3 Kamailio servers share the same database, and users can use >> their kamailio user/pwd on any of the devices, now I want to use >> encrypted passwords and remove clear text passwords from the >> database. >> I did test with one server and all is fine,however if a user want to >> register from the second kamailio server it does not work, basically >> because the db domain entry from which the hash is created is >> sip1.domain.com and stored in the db, while the user connects from to >> sip2.domain.com this eventually generates a different hash. >> >> Is there anyway to overcome this ? Can I exclude Domain from Hash >> generation ? Any other option that allows me to do the above ? >> >> Thanks >
>
Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda
-- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda
-- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda
Hi Please see the below, thanks !
interface: eth1 (xx.xx.xx.0/255.255.255.0) match: support1
U +6.698682 yy.yy.yy.146:18832 -> xx.xx.xx.51:5060 REGISTER sip:register.domain.com SIP/2.0. Via: SIP/2.0/UDP 192.168.0.191:18832;branch=z9hG4bK-d8754z-05164a466600837d-1---d8754z-;rport. Max-Forwards: 70. Contact: sip:support1@192.168.0.191:18832;rinstance=f8e37e314657e0d7;transport=udp. To: "Test Ast"sip:support1@register.domain.com. From: "Test Ast"sip:support1@register.domain.com;tag=f710b930. Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY.. CSeq: 1 REGISTER. Expires: 3600. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. User-Agent: eyeBeam release 1102q stamp 51814. Content-Length: 0. .
U +0.005245 xx.xx.xx.51:5060 -> yy.yy.yy.146:18832 SIP/2.0 401 Unauthorized. Via: SIP/2.0/UDP 192.168.0.191:18832;branch=z9hG4bK-d8754z-05164a466600837d-1---d8754z-;rport=18832;received=yy.yy.yy.146. To: "Test Ast"sip:support1@register.domain.com;tag=e597ca73bdb255490f0cefa03b2fda82.3053. From: "Test Ast"sip:support1@register.domain.com;tag=f710b930. Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY.. CSeq: 1 REGISTER. WWW-Authenticate: Digest realm="domain.com", nonce="TwMpUE8DKCSt/IP7jcNRMbCT4TnbqlHl". Server: kamailio (3.2.1 (i386/linux)). Content-Length: 0. .
U +0.428042 yy.yy.yy.146:18832 -> xx.xx.xx.51:5060 REGISTER sip:register.domain.com SIP/2.0. Via: SIP/2.0/UDP 192.168.0.191:18832;branch=z9hG4bK-d8754z-fc633b21627dca6d-1---d8754z-;rport. Max-Forwards: 70. Contact: sip:support1@192.168.0.191:18832;rinstance=f8e37e314657e0d7;transport=udp. To: "Test Ast"sip:support1@register.domain.com. From: "Test Ast"sip:support1@register.domain.com;tag=f710b930. Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY.. CSeq: 2 REGISTER. Expires: 3600. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. User-Agent: eyeBeam release 1102q stamp 51814. Authorization: Digest username="support1",realm="domain.com",nonce="TwMpUE8DKCSt/IP7jcNRMbCT4TnbqlHl",uri="sip:register.domain.com",response="6122245b77e2df0b90179304464341e7",algorithm=MD5. Content-Length: 0. .
U +0.005146 xx.xx.xx.51:5060 -> yy.yy.yy.146:18832 SIP/2.0 401 Unauthorized. Via: SIP/2.0/UDP 192.168.0.191:18832;branch=z9hG4bK-d8754z-fc633b21627dca6d-1---d8754z-;rport=18832;received=yy.yy.yy.146. To: "Test Ast"sip:support1@register.domain.com;tag=e597ca73bdb255490f0cefa03b2fda82.fce3. From: "Test Ast"sip:support1@register.domain.com;tag=f710b930. Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY.. CSeq: 2 REGISTER. WWW-Authenticate: Digest realm="domain.com", nonce="TwMpUE8DKCSt/IP7jcNRMbCT4TnbqlHl". Server: kamailio (3.2.1 (i386/linux)). Content-Length: 0. .
[root@kam-rtp-100-51 mysql]# mail alijawad1@gmail.com < output.txt [root@kam-rtp-100-51 mysql]# ngrep -W byline -T support1 -q -d eth1 interface: eth1 (xx.xx.xx.0/255.255.255.0) match: support1
U +5.321505 yy.yy.yy.146:63610 -> xx.xx.xx.51:5060 REGISTER sip:register.domain.com SIP/2.0. Via: SIP/2.0/UDP 192.168.0.191:63610;branch=z9hG4bK-d8754z-fb28723daa3f772d-1---d8754z-;rport. Max-Forwards: 70. Contact: sip:support1@192.168.0.191:63610;rinstance=782b19a2fccc665f;transport=udp. To: "Test Ast"sip:support1@register.domain.com. From: "Test Ast"sip:support1@register.domain.com;tag=ba705453. Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI.. CSeq: 1 REGISTER. Expires: 3600. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. User-Agent: eyeBeam release 1102q stamp 51814. Content-Length: 0. .
U +0.004782 xx.xx.xx.51:5060 -> yy.yy.yy.146:63610 SIP/2.0 401 Unauthorized. Via: SIP/2.0/UDP 192.168.0.191:63610;branch=z9hG4bK-d8754z-fb28723daa3f772d-1---d8754z-;rport=63610;received=yy.yy.yy.146. To: "Test Ast"sip:support1@register.domain.com;tag=e597ca73bdb255490f0cefa03b2fda82.6b98. From: "Test Ast"sip:support1@register.domain.com;tag=ba705453. Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI.. CSeq: 1 REGISTER. WWW-Authenticate: Digest realm="domain.com", nonce="TwMpsU8DKIX4lvWDwPsV4iUhCl+iOAdk". Server: kamailio (3.2.1 (i386/linux)). Content-Length: 0. .
U +0.400706 yy.yy.yy.146:63610 -> xx.xx.xx.51:5060 REGISTER sip:register.domain.com SIP/2.0. Via: SIP/2.0/UDP 192.168.0.191:63610;branch=z9hG4bK-d8754z-81517d296225234f-1---d8754z-;rport. Max-Forwards: 70. Contact: sip:support1@192.168.0.191:63610;rinstance=782b19a2fccc665f;transport=udp. To: "Test Ast"sip:support1@register.domain.com. From: "Test Ast"sip:support1@register.domain.com;tag=ba705453. Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI.. CSeq: 2 REGISTER. Expires: 3600. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. User-Agent: eyeBeam release 1102q stamp 51814. Authorization: Digest username="support1",realm="domain.com",nonce="TwMpsU8DKIX4lvWDwPsV4iUhCl+iOAdk",uri="sip:register.domain.com",response="4bfd80b0b836c20b748ee19a1c886284",algorithm=MD5. Content-Length: 0. .
U +0.005302 xx.xx.xx.51:5060 -> yy.yy.yy.146:63610 SIP/2.0 401 Unauthorized. Via: SIP/2.0/UDP 192.168.0.191:63610;branch=z9hG4bK-d8754z-81517d296225234f-1---d8754z-;rport=63610;received=yy.yy.yy.146. To: "Test Ast"sip:support1@register.domain.com;tag=e597ca73bdb255490f0cefa03b2fda82.2f76. From: "Test Ast"sip:support1@register.domain.com;tag=ba705453. Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI.. CSeq: 2 REGISTER. WWW-Authenticate: Digest realm="domain.com", nonce="TwMpsU8DKIX4lvWDwPsV4iUhCl+iOAdk". Server: kamailio (3.2.1 (i386/linux)). Content-Length: 0. .
On Tue, Jan 3, 2012 at 6:08 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
I need the entire flow for registration, including the 401 reply and the following REGISTER request.
Cheers, Daniel
On 1/3/12 5:02 PM, Ali Jawad wrote:
Hi Please see the ngrep below, please note that if I use in the db register.domain.com and generate a hash against it for HA1 it works,but then the user cant logon to register2.domain.com
U +10.630576 xx.yy.yy.yy:20020 -> xx.xx.xx.xx:5060 REGISTER sip:register.domain SIP/2.0. Via: SIP/2.0/UDP
192.168.0.191:20020;branch=z9hG4bK-d8754z-af65a442980c375f-1---d8754z-;rport. Max-Forwards: 70.
Contact:sip:support1@192.168.0.191:20020;rinstance=4009190a4e109ac6;transport=udp. To: "Test Ast"sip:support1@register.domain. From: "Test Ast"sip:support1@register.domain;tag=976bb004. Call-ID: MDFmZDU2ZTI2YjJjMGNlMGFmOTIzMWFmZGQ1ZTNjMDE.. CSeq: 1 REGISTER. Expires: 3600. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. User-Agent: eyeBeam release 1102q stamp 51814. Content-Length: 0.
On Tue, Jan 3, 2012 at 5:58 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
On 1/3/12 4:48 PM, Ali Jawad wrote:
Hi Daniel
Please see
5(18649) DEBUG:<core> [db_res.c:184]: allocate 8 bytes for rows at 0xb7b78d74 5(18649) DEBUG:<core> [db_row.c:119]: allocate 20 bytes for row values at 0xb7b78dac 5(18649) DEBUG:<core> [db_val.c:117]: converting STRING [6f966cd9c628f14cdc20172f96a4d065] 5(18649) DEBUG: auth [api.c:210]: check_response: Our result = '6f95e6235edca0b7765042ef119fd83b' 5(18649) DEBUG: auth [api.c:220]: check_response: Authorization failed 5(18649) DEBUG:<core> [db_res.c:81]: freeing 1 columns 5(18649) DEBUG:<core> [db_res.c:85]: freeing RES_NAMES[0] at 0xb7b78d3c 5(18649) DEBUG:<core> [db_res.c:94]: freeing result names at 0xb7b78bfc 5(18649) DEBUG:<core> [db_res.c:99]: freeing result types at 0xb7b78c64 5(18649) DEBUG:<core> [db_res.c:54]: freeing 1 rows 5(18649) DEBUG:<core> [db_row.c:97]: freeing row values at 0xb7b78dac 5(18649) DEBUG:<core> [db_res.c:62]: freeing rows at 0xb7b78d74 5(18649) DEBUG:<core> [db_res.c:136]: freeing result set at 0xb7b78bb0 5(18649) DEBUG: auth [challenge.c:102]: build_challenge_hf: realm='nymgo.com' 5(18649) DEBUG: auth [challenge.c:244]: auth: 'WWW-Authenticate: Digest realm="domain.com", nonce="TwMcuk8DG47SLxatlNdZfyfR8p3OiyAE" '
I rebuilt the hashes against domain.com and then tried to connect to sip1.domain.com and sip2.domain.com and sip3.domain.com with all of the having
# ----- auth_db params ----- #!ifdef WITH_AUTH modparam("auth_db", "db_url", DBURL) modparam("auth_db", "calculate_ha1", 0 ) modparam("auth_db", "password_column", "ha1") modparam("auth_db", "load_credentials", "") modparam("auth_db", "use_domain", MULTIDOMAIN)
And in the routing process :
if (!www_authorize("domain.com", "subscriber")) {
www_challenge("domain.com", "0"); exit; }
+++++++++++++
My point is that the hashes are caculated from user:doman:pwd which are extracted from the SIP packet and in this case the domains are sip1,sip2,sip3 while the hashes stored in the database are generated against domain.com
If " ha1 is actually hash over 'user:realm:pwd' " shouldn't I have to set the domain/realm in the config file ?
the first parameter in www_authorize and www_challenge functions is the realm and it is used to build the digest response.
Is your phone putting user@domain in authorization header? Can you paste here the ngrep of registration?
Cheers, Daniel
I might be wrong....thanks for the help so far.
Regards
On Tue, Jan 3, 2012 at 5:15 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
On 1/3/12 4:12 PM, Ali Jawad wrote:
Hi Daniel This certainly makes sense, I will try it in a few mins, but what I observed at Debug Level 3 is that Hash is calculated before www_authenticate is executed and it shows HA comparison failed, if I do use domain.com instead of $fd and use $domain.com in db domain field and build HA1 filed based on that, wont Kamailio still try to build the HA1 hash which it will compare form user:domain:pwd where domain is fed in to the hash function from the header of the SIP packet ?
the ha1 is actually hash over 'user:realm:pwd' -- it is just common practice to use the domain as realm, since realm should be a unique token to identify the service, but it can be any random string. realm is given as parameter to auth functions in kamailio.cfg
Cheers, Daniel
Regards
On Tue, Jan 3, 2012 at 5:07 PM, Daniel-Constantin Mierla miconda@gmail.com wrote: > > Hello, > > you can simply use 'domain.com' as realm parameter to authentication > function instead of $fd. Also build ha1 and ha1b with domain.com and > then > you are safe no matter which sip server is used. > > Of course you can build the realm by striping first token before '.' > in > $fd > and pass it to authentication functions, but not sure if makes sense > since > it should be always domain.com > > Cheers, > Daniel > > > On 1/3/12 3:15 PM, Ali Jawad wrote: >> >> Hi >> After some research it seems to me that the only way to achieve this >> is to "try" and change how hashing is done in the source code, a >> little bit too ambitious for me, and it means I will have loads of >> problems each time an upgrade is released. >> >> Or >> >> Use pseudovariables to fix the value of the $fd value to something >> constant, while this worked for values like $var(y) I was not able >> to >> assign/strip $fd to remove the subdomain part. >> >> Any input please ? >> >> Regards >> >> On Tue, Jan 3, 2012 at 2:06 PM, Ali Jawadali.jawad@splendor.net >> wrote: >>> >>> Hi >>> I do have 3 Kamailio servers, one for mobile phone registrations, >>> one >>> for softphone registrations and one for SIP device registrations. >>> Each >>> of those devices connects to it's perspective kamailio server >>> >>> sip1.domain.com >>> sip2.domain.com >>> sip3.domain.com >>> >>> All 3 Kamailio servers share the same database, and users can use >>> their kamailio user/pwd on any of the devices, now I want to use >>> encrypted passwords and remove clear text passwords from the >>> database. >>> I did test with one server and all is fine,however if a user want >>> to >>> register from the second kamailio server it does not work, >>> basically >>> because the db domain entry from which the hash is created is >>> sip1.domain.com and stored in the db, while the user connects from >>> to >>> sip2.domain.com this eventually generates a different hash. >>> >>> Is there anyway to overcome this ? Can I exclude Domain from Hash >>> generation ? Any other option that allows me to do the above ? >>> >>> Thanks >> >> >> > -- > Daniel-Constantin Mierla -- http://www.asipto.com > http://linkedin.com/in/miconda -- http://twitter.com/miconda >
-- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda
-- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda
-- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda
Hello,
why are you using register.domain.com as domain for registration? Isn't domain.com the right one?
Can you enable the sql query log for mysql server and double check if the right value (column) is selected from the database table?
Cheers, Daniel
On 1/3/12 5:13 PM, Ali Jawad wrote:
Hi Please see the below, thanks !
interface: eth1 (xx.xx.xx.0/255.255.255.0) match: support1
U +6.698682 yy.yy.yy.146:18832 -> xx.xx.xx.51:5060 REGISTER sip:register.domain.com SIP/2.0. Via: SIP/2.0/UDP 192.168.0.191:18832;branch=z9hG4bK-d8754z-05164a466600837d-1---d8754z-;rport. Max-Forwards: 70. Contact:sip:support1@192.168.0.191:18832;rinstance=f8e37e314657e0d7;transport=udp. To: "Test Ast"sip:support1@register.domain.com. From: "Test Ast"sip:support1@register.domain.com;tag=f710b930. Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY.. CSeq: 1 REGISTER. Expires: 3600. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. User-Agent: eyeBeam release 1102q stamp 51814. Content-Length: 0. .
U +0.005245 xx.xx.xx.51:5060 -> yy.yy.yy.146:18832 SIP/2.0 401 Unauthorized. Via: SIP/2.0/UDP 192.168.0.191:18832;branch=z9hG4bK-d8754z-05164a466600837d-1---d8754z-;rport=18832;received=yy.yy.yy.146. To: "Test Ast"sip:support1@register.domain.com;tag=e597ca73bdb255490f0cefa03b2fda82.3053. From: "Test Ast"sip:support1@register.domain.com;tag=f710b930. Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY.. CSeq: 1 REGISTER. WWW-Authenticate: Digest realm="domain.com", nonce="TwMpUE8DKCSt/IP7jcNRMbCT4TnbqlHl". Server: kamailio (3.2.1 (i386/linux)). Content-Length: 0. .
U +0.428042 yy.yy.yy.146:18832 -> xx.xx.xx.51:5060 REGISTER sip:register.domain.com SIP/2.0. Via: SIP/2.0/UDP 192.168.0.191:18832;branch=z9hG4bK-d8754z-fc633b21627dca6d-1---d8754z-;rport. Max-Forwards: 70. Contact:sip:support1@192.168.0.191:18832;rinstance=f8e37e314657e0d7;transport=udp. To: "Test Ast"sip:support1@register.domain.com. From: "Test Ast"sip:support1@register.domain.com;tag=f710b930. Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY.. CSeq: 2 REGISTER. Expires: 3600. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. User-Agent: eyeBeam release 1102q stamp 51814. Authorization: Digest username="support1",realm="domain.com",nonce="TwMpUE8DKCSt/IP7jcNRMbCT4TnbqlHl",uri="sip:register.domain.com",response="6122245b77e2df0b90179304464341e7",algorithm=MD5. Content-Length: 0. .
U +0.005146 xx.xx.xx.51:5060 -> yy.yy.yy.146:18832 SIP/2.0 401 Unauthorized. Via: SIP/2.0/UDP 192.168.0.191:18832;branch=z9hG4bK-d8754z-fc633b21627dca6d-1---d8754z-;rport=18832;received=yy.yy.yy.146. To: "Test Ast"sip:support1@register.domain.com;tag=e597ca73bdb255490f0cefa03b2fda82.fce3. From: "Test Ast"sip:support1@register.domain.com;tag=f710b930. Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY.. CSeq: 2 REGISTER. WWW-Authenticate: Digest realm="domain.com", nonce="TwMpUE8DKCSt/IP7jcNRMbCT4TnbqlHl". Server: kamailio (3.2.1 (i386/linux)). Content-Length: 0. .
[root@kam-rtp-100-51 mysql]# mail alijawad1@gmail.com< output.txt [root@kam-rtp-100-51 mysql]# ngrep -W byline -T support1 -q -d eth1 interface: eth1 (xx.xx.xx.0/255.255.255.0) match: support1
U +5.321505 yy.yy.yy.146:63610 -> xx.xx.xx.51:5060 REGISTER sip:register.domain.com SIP/2.0. Via: SIP/2.0/UDP 192.168.0.191:63610;branch=z9hG4bK-d8754z-fb28723daa3f772d-1---d8754z-;rport. Max-Forwards: 70. Contact:sip:support1@192.168.0.191:63610;rinstance=782b19a2fccc665f;transport=udp. To: "Test Ast"sip:support1@register.domain.com. From: "Test Ast"sip:support1@register.domain.com;tag=ba705453. Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI.. CSeq: 1 REGISTER. Expires: 3600. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. User-Agent: eyeBeam release 1102q stamp 51814. Content-Length: 0. .
U +0.004782 xx.xx.xx.51:5060 -> yy.yy.yy.146:63610 SIP/2.0 401 Unauthorized. Via: SIP/2.0/UDP 192.168.0.191:63610;branch=z9hG4bK-d8754z-fb28723daa3f772d-1---d8754z-;rport=63610;received=yy.yy.yy.146. To: "Test Ast"sip:support1@register.domain.com;tag=e597ca73bdb255490f0cefa03b2fda82.6b98. From: "Test Ast"sip:support1@register.domain.com;tag=ba705453. Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI.. CSeq: 1 REGISTER. WWW-Authenticate: Digest realm="domain.com", nonce="TwMpsU8DKIX4lvWDwPsV4iUhCl+iOAdk". Server: kamailio (3.2.1 (i386/linux)). Content-Length: 0. .
U +0.400706 yy.yy.yy.146:63610 -> xx.xx.xx.51:5060 REGISTER sip:register.domain.com SIP/2.0. Via: SIP/2.0/UDP 192.168.0.191:63610;branch=z9hG4bK-d8754z-81517d296225234f-1---d8754z-;rport. Max-Forwards: 70. Contact:sip:support1@192.168.0.191:63610;rinstance=782b19a2fccc665f;transport=udp. To: "Test Ast"sip:support1@register.domain.com. From: "Test Ast"sip:support1@register.domain.com;tag=ba705453. Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI.. CSeq: 2 REGISTER. Expires: 3600. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. User-Agent: eyeBeam release 1102q stamp 51814. Authorization: Digest username="support1",realm="domain.com",nonce="TwMpsU8DKIX4lvWDwPsV4iUhCl+iOAdk",uri="sip:register.domain.com",response="4bfd80b0b836c20b748ee19a1c886284",algorithm=MD5. Content-Length: 0. .
U +0.005302 xx.xx.xx.51:5060 -> yy.yy.yy.146:63610 SIP/2.0 401 Unauthorized. Via: SIP/2.0/UDP 192.168.0.191:63610;branch=z9hG4bK-d8754z-81517d296225234f-1---d8754z-;rport=63610;received=yy.yy.yy.146. To: "Test Ast"sip:support1@register.domain.com;tag=e597ca73bdb255490f0cefa03b2fda82.2f76. From: "Test Ast"sip:support1@register.domain.com;tag=ba705453. Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI.. CSeq: 2 REGISTER. WWW-Authenticate: Digest realm="domain.com", nonce="TwMpsU8DKIX4lvWDwPsV4iUhCl+iOAdk". Server: kamailio (3.2.1 (i386/linux)). Content-Length: 0. .
On Tue, Jan 3, 2012 at 6:08 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
I need the entire flow for registration, including the 401 reply and the following REGISTER request.
Cheers, Daniel
On 1/3/12 5:02 PM, Ali Jawad wrote:
Hi Please see the ngrep below, please note that if I use in the db register.domain.com and generate a hash against it for HA1 it works,but then the user cant logon to register2.domain.com
U +10.630576 xx.yy.yy.yy:20020 -> xx.xx.xx.xx:5060 REGISTER sip:register.domain SIP/2.0. Via: SIP/2.0/UDP
192.168.0.191:20020;branch=z9hG4bK-d8754z-af65a442980c375f-1---d8754z-;rport. Max-Forwards: 70.
Contact:sip:support1@192.168.0.191:20020;rinstance=4009190a4e109ac6;transport=udp. To: "Test Ast"sip:support1@register.domain. From: "Test Ast"sip:support1@register.domain;tag=976bb004. Call-ID: MDFmZDU2ZTI2YjJjMGNlMGFmOTIzMWFmZGQ1ZTNjMDE.. CSeq: 1 REGISTER. Expires: 3600. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. User-Agent: eyeBeam release 1102q stamp 51814. Content-Length: 0.
On Tue, Jan 3, 2012 at 5:58 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
On 1/3/12 4:48 PM, Ali Jawad wrote:
Hi Daniel
Please see
5(18649) DEBUG:<core> [db_res.c:184]: allocate 8 bytes for rows at 0xb7b78d74 5(18649) DEBUG:<core> [db_row.c:119]: allocate 20 bytes for row values at 0xb7b78dac 5(18649) DEBUG:<core> [db_val.c:117]: converting STRING [6f966cd9c628f14cdc20172f96a4d065] 5(18649) DEBUG: auth [api.c:210]: check_response: Our result = '6f95e6235edca0b7765042ef119fd83b' 5(18649) DEBUG: auth [api.c:220]: check_response: Authorization failed 5(18649) DEBUG:<core> [db_res.c:81]: freeing 1 columns 5(18649) DEBUG:<core> [db_res.c:85]: freeing RES_NAMES[0] at 0xb7b78d3c 5(18649) DEBUG:<core> [db_res.c:94]: freeing result names at 0xb7b78bfc 5(18649) DEBUG:<core> [db_res.c:99]: freeing result types at 0xb7b78c64 5(18649) DEBUG:<core> [db_res.c:54]: freeing 1 rows 5(18649) DEBUG:<core> [db_row.c:97]: freeing row values at 0xb7b78dac 5(18649) DEBUG:<core> [db_res.c:62]: freeing rows at 0xb7b78d74 5(18649) DEBUG:<core> [db_res.c:136]: freeing result set at 0xb7b78bb0 5(18649) DEBUG: auth [challenge.c:102]: build_challenge_hf: realm='nymgo.com' 5(18649) DEBUG: auth [challenge.c:244]: auth: 'WWW-Authenticate: Digest realm="domain.com", nonce="TwMcuk8DG47SLxatlNdZfyfR8p3OiyAE" '
I rebuilt the hashes against domain.com and then tried to connect to sip1.domain.com and sip2.domain.com and sip3.domain.com with all of the having
# ----- auth_db params ----- #!ifdef WITH_AUTH modparam("auth_db", "db_url", DBURL) modparam("auth_db", "calculate_ha1", 0 ) modparam("auth_db", "password_column", "ha1") modparam("auth_db", "load_credentials", "") modparam("auth_db", "use_domain", MULTIDOMAIN)
And in the routing process :
if (!www_authorize("domain.com", "subscriber")) { www_challenge("domain.com", "0"); exit; }+++++++++++++
My point is that the hashes are caculated from user:doman:pwd which are extracted from the SIP packet and in this case the domains are sip1,sip2,sip3 while the hashes stored in the database are generated against domain.com
If " ha1 is actually hash over 'user:realm:pwd' " shouldn't I have to set the domain/realm in the config file ?
the first parameter in www_authorize and www_challenge functions is the realm and it is used to build the digest response.
Is your phone putting user@domain in authorization header? Can you paste here the ngrep of registration?
Cheers, Daniel
I might be wrong....thanks for the help so far.
Regards
On Tue, Jan 3, 2012 at 5:15 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
On 1/3/12 4:12 PM, Ali Jawad wrote: > Hi Daniel > This certainly makes sense, I will try it in a few mins, but what I > observed at Debug Level 3 is that Hash is calculated before > www_authenticate is executed and it shows HA comparison failed, if I > do use domain.com instead of $fd and use $domain.com in db domain > field and build HA1 filed based on that, wont Kamailio still try to > build the HA1 hash which it will compare form user:domain:pwd where > domain is fed in to the hash function from the header of the SIP > packet ?
the ha1 is actually hash over 'user:realm:pwd' -- it is just common practice to use the domain as realm, since realm should be a unique token to identify the service, but it can be any random string. realm is given as parameter to auth functions in kamailio.cfg
Cheers, Daniel
> Regards > > On Tue, Jan 3, 2012 at 5:07 PM, Daniel-Constantin Mierla > miconda@gmail.com wrote: >> Hello, >> >> you can simply use 'domain.com' as realm parameter to authentication >> function instead of $fd. Also build ha1 and ha1b with domain.com and >> then >> you are safe no matter which sip server is used. >> >> Of course you can build the realm by striping first token before '.' >> in >> $fd >> and pass it to authentication functions, but not sure if makes sense >> since >> it should be always domain.com >> >> Cheers, >> Daniel >> >> >> On 1/3/12 3:15 PM, Ali Jawad wrote: >>> Hi >>> After some research it seems to me that the only way to achieve this >>> is to "try" and change how hashing is done in the source code, a >>> little bit too ambitious for me, and it means I will have loads of >>> problems each time an upgrade is released. >>> >>> Or >>> >>> Use pseudovariables to fix the value of the $fd value to something >>> constant, while this worked for values like $var(y) I was not able >>> to >>> assign/strip $fd to remove the subdomain part. >>> >>> Any input please ? >>> >>> Regards >>> >>> On Tue, Jan 3, 2012 at 2:06 PM, Ali Jawadali.jawad@splendor.net >>> wrote: >>>> Hi >>>> I do have 3 Kamailio servers, one for mobile phone registrations, >>>> one >>>> for softphone registrations and one for SIP device registrations. >>>> Each >>>> of those devices connects to it's perspective kamailio server >>>> >>>> sip1.domain.com >>>> sip2.domain.com >>>> sip3.domain.com >>>> >>>> All 3 Kamailio servers share the same database, and users can use >>>> their kamailio user/pwd on any of the devices, now I want to use >>>> encrypted passwords and remove clear text passwords from the >>>> database. >>>> I did test with one server and all is fine,however if a user want >>>> to >>>> register from the second kamailio server it does not work, >>>> basically >>>> because the db domain entry from which the hash is created is >>>> sip1.domain.com and stored in the db, while the user connects from >>>> to >>>> sip2.domain.com this eventually generates a different hash. >>>> >>>> Is there anyway to overcome this ? Can I exclude Domain from Hash >>>> generation ? Any other option that allows me to do the above ? >>>> >>>> Thanks >>> >>> >> -- >> Daniel-Constantin Mierla -- http://www.asipto.com >> http://linkedin.com/in/miconda -- http://twitter.com/miconda >> > -- > Daniel-Constantin Mierla -- http://www.asipto.com > http://linkedin.com/in/miconda -- http://twitter.com/miconda
-- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda
-- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda
Hi In Xlite/eyebeam I put in the username and one of my 3 kamailio servers respectively as the sip registrar, I.e. register1.domain.com, register2.domain.com and register3.domain.com, that is why I was saying that hashing will create different hashes based on the register domain. With reference to my first related post, one kamailio server is for softphones, one for sip devices and one for mobile phones with SIP software. Each server has a slightly different NAT and Call routing structure. This is why I wanted to eliminate the domain factor from the hashing procedure, I am sure it chooses the right value from the DB value because it is the same value shown in the log of kamailio against which a comparison is being done and because it works if I put register.domain.com in the domain column rehash the HA! value of the db.
values at 0xb7b78dac
5(18649) DEBUG:<core> [db_val.c:117]: converting STRING [6f966cd9c628f14cdc20172f96a4d065] <====##### This is the value in the DB based on domain.com 5(18649) DEBUG: auth [api.c:210]: check_response: Our result = '6f95e6235edca0b7765042ef119fd83b' <====##### This value appears to be the value generated register.domain.com 5(18649) DEBUG: auth [api.c:220]: check_response: Authorization
How can I enable the SQL query log ?
On Tue, Jan 3, 2012 at 8:12 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
why are you using register.domain.com as domain for registration? Isn't domain.com the right one?
Can you enable the sql query log for mysql server and double check if the right value (column) is selected from the database table?
Cheers, Daniel
On 1/3/12 5:13 PM, Ali Jawad wrote:
Hi Please see the below, thanks !
interface: eth1 (xx.xx.xx.0/255.255.255.0) match: support1
U +6.698682 yy.yy.yy.146:18832 -> xx.xx.xx.51:5060 REGISTER sip:register.domain.com SIP/2.0. Via: SIP/2.0/UDP
192.168.0.191:18832;branch=z9hG4bK-d8754z-05164a466600837d-1---d8754z-;rport. Max-Forwards: 70.
Contact:sip:support1@192.168.0.191:18832;rinstance=f8e37e314657e0d7;transport=udp. To: "Test Ast"sip:support1@register.domain.com. From: "Test Ast"sip:support1@register.domain.com;tag=f710b930. Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY.. CSeq: 1 REGISTER. Expires: 3600. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. User-Agent: eyeBeam release 1102q stamp 51814. Content-Length: 0. .
U +0.005245 xx.xx.xx.51:5060 -> yy.yy.yy.146:18832 SIP/2.0 401 Unauthorized. Via: SIP/2.0/UDP
192.168.0.191:18832;branch=z9hG4bK-d8754z-05164a466600837d-1---d8754z-;rport=18832;received=yy.yy.yy.146. To: "Test Ast"sip:support1@register.domain.com;tag=e597ca73bdb255490f0cefa03b2fda82.3053. From: "Test Ast"sip:support1@register.domain.com;tag=f710b930. Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY.. CSeq: 1 REGISTER. WWW-Authenticate: Digest realm="domain.com", nonce="TwMpUE8DKCSt/IP7jcNRMbCT4TnbqlHl". Server: kamailio (3.2.1 (i386/linux)). Content-Length: 0. .
U +0.428042 yy.yy.yy.146:18832 -> xx.xx.xx.51:5060 REGISTER sip:register.domain.com SIP/2.0. Via: SIP/2.0/UDP
192.168.0.191:18832;branch=z9hG4bK-d8754z-fc633b21627dca6d-1---d8754z-;rport. Max-Forwards: 70.
Contact:sip:support1@192.168.0.191:18832;rinstance=f8e37e314657e0d7;transport=udp. To: "Test Ast"sip:support1@register.domain.com. From: "Test Ast"sip:support1@register.domain.com;tag=f710b930. Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY.. CSeq: 2 REGISTER. Expires: 3600. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. User-Agent: eyeBeam release 1102q stamp 51814. Authorization: Digest
username="support1",realm="domain.com",nonce="TwMpUE8DKCSt/IP7jcNRMbCT4TnbqlHl",uri="sip:register.domain.com",response="6122245b77e2df0b90179304464341e7",algorithm=MD5. Content-Length: 0. .
U +0.005146 xx.xx.xx.51:5060 -> yy.yy.yy.146:18832 SIP/2.0 401 Unauthorized. Via: SIP/2.0/UDP
192.168.0.191:18832;branch=z9hG4bK-d8754z-fc633b21627dca6d-1---d8754z-;rport=18832;received=yy.yy.yy.146. To: "Test Ast"sip:support1@register.domain.com;tag=e597ca73bdb255490f0cefa03b2fda82.fce3. From: "Test Ast"sip:support1@register.domain.com;tag=f710b930. Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY.. CSeq: 2 REGISTER. WWW-Authenticate: Digest realm="domain.com", nonce="TwMpUE8DKCSt/IP7jcNRMbCT4TnbqlHl". Server: kamailio (3.2.1 (i386/linux)). Content-Length: 0. .
[root@kam-rtp-100-51 mysql]# mail alijawad1@gmail.com< output.txt [root@kam-rtp-100-51 mysql]# ngrep -W byline -T support1 -q -d eth1 interface: eth1 (xx.xx.xx.0/255.255.255.0) match: support1
U +5.321505 yy.yy.yy.146:63610 -> xx.xx.xx.51:5060 REGISTER sip:register.domain.com SIP/2.0. Via: SIP/2.0/UDP
192.168.0.191:63610;branch=z9hG4bK-d8754z-fb28723daa3f772d-1---d8754z-;rport. Max-Forwards: 70.
Contact:sip:support1@192.168.0.191:63610;rinstance=782b19a2fccc665f;transport=udp. To: "Test Ast"sip:support1@register.domain.com. From: "Test Ast"sip:support1@register.domain.com;tag=ba705453. Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI.. CSeq: 1 REGISTER. Expires: 3600. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. User-Agent: eyeBeam release 1102q stamp 51814. Content-Length: 0. .
U +0.004782 xx.xx.xx.51:5060 -> yy.yy.yy.146:63610 SIP/2.0 401 Unauthorized. Via: SIP/2.0/UDP
192.168.0.191:63610;branch=z9hG4bK-d8754z-fb28723daa3f772d-1---d8754z-;rport=63610;received=yy.yy.yy.146. To: "Test Ast"sip:support1@register.domain.com;tag=e597ca73bdb255490f0cefa03b2fda82.6b98. From: "Test Ast"sip:support1@register.domain.com;tag=ba705453. Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI.. CSeq: 1 REGISTER. WWW-Authenticate: Digest realm="domain.com", nonce="TwMpsU8DKIX4lvWDwPsV4iUhCl+iOAdk". Server: kamailio (3.2.1 (i386/linux)). Content-Length: 0. .
U +0.400706 yy.yy.yy.146:63610 -> xx.xx.xx.51:5060 REGISTER sip:register.domain.com SIP/2.0. Via: SIP/2.0/UDP
192.168.0.191:63610;branch=z9hG4bK-d8754z-81517d296225234f-1---d8754z-;rport. Max-Forwards: 70.
Contact:sip:support1@192.168.0.191:63610;rinstance=782b19a2fccc665f;transport=udp. To: "Test Ast"sip:support1@register.domain.com. From: "Test Ast"sip:support1@register.domain.com;tag=ba705453. Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI.. CSeq: 2 REGISTER. Expires: 3600. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. User-Agent: eyeBeam release 1102q stamp 51814. Authorization: Digest
username="support1",realm="domain.com",nonce="TwMpsU8DKIX4lvWDwPsV4iUhCl+iOAdk",uri="sip:register.domain.com",response="4bfd80b0b836c20b748ee19a1c886284",algorithm=MD5. Content-Length: 0. .
U +0.005302 xx.xx.xx.51:5060 -> yy.yy.yy.146:63610 SIP/2.0 401 Unauthorized. Via: SIP/2.0/UDP
192.168.0.191:63610;branch=z9hG4bK-d8754z-81517d296225234f-1---d8754z-;rport=63610;received=yy.yy.yy.146. To: "Test Ast"sip:support1@register.domain.com;tag=e597ca73bdb255490f0cefa03b2fda82.2f76. From: "Test Ast"sip:support1@register.domain.com;tag=ba705453. Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI.. CSeq: 2 REGISTER. WWW-Authenticate: Digest realm="domain.com", nonce="TwMpsU8DKIX4lvWDwPsV4iUhCl+iOAdk". Server: kamailio (3.2.1 (i386/linux)). Content-Length: 0. .
On Tue, Jan 3, 2012 at 6:08 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
I need the entire flow for registration, including the 401 reply and the following REGISTER request.
Cheers, Daniel
On 1/3/12 5:02 PM, Ali Jawad wrote:
Hi Please see the ngrep below, please note that if I use in the db register.domain.com and generate a hash against it for HA1 it works,but then the user cant logon to register2.domain.com
U +10.630576 xx.yy.yy.yy:20020 -> xx.xx.xx.xx:5060 REGISTER sip:register.domain SIP/2.0. Via: SIP/2.0/UDP
192.168.0.191:20020;branch=z9hG4bK-d8754z-af65a442980c375f-1---d8754z-;rport. Max-Forwards: 70.
Contact:sip:support1@192.168.0.191:20020;rinstance=4009190a4e109ac6;transport=udp. To: "Test Ast"sip:support1@register.domain. From: "Test Ast"sip:support1@register.domain;tag=976bb004. Call-ID: MDFmZDU2ZTI2YjJjMGNlMGFmOTIzMWFmZGQ1ZTNjMDE.. CSeq: 1 REGISTER. Expires: 3600. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. User-Agent: eyeBeam release 1102q stamp 51814. Content-Length: 0.
On Tue, Jan 3, 2012 at 5:58 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
On 1/3/12 4:48 PM, Ali Jawad wrote:
Hi Daniel
Please see
5(18649) DEBUG:<core> [db_res.c:184]: allocate 8 bytes for rows at 0xb7b78d74 5(18649) DEBUG:<core> [db_row.c:119]: allocate 20 bytes for row values at 0xb7b78dac 5(18649) DEBUG:<core> [db_val.c:117]: converting STRING [6f966cd9c628f14cdc20172f96a4d065] 5(18649) DEBUG: auth [api.c:210]: check_response: Our result = '6f95e6235edca0b7765042ef119fd83b' 5(18649) DEBUG: auth [api.c:220]: check_response: Authorization failed 5(18649) DEBUG:<core> [db_res.c:81]: freeing 1 columns 5(18649) DEBUG:<core> [db_res.c:85]: freeing RES_NAMES[0] at 0xb7b78d3c 5(18649) DEBUG:<core> [db_res.c:94]: freeing result names at 0xb7b78bfc 5(18649) DEBUG:<core> [db_res.c:99]: freeing result types at 0xb7b78c64 5(18649) DEBUG:<core> [db_res.c:54]: freeing 1 rows 5(18649) DEBUG:<core> [db_row.c:97]: freeing row values at 0xb7b78dac 5(18649) DEBUG:<core> [db_res.c:62]: freeing rows at 0xb7b78d74 5(18649) DEBUG:<core> [db_res.c:136]: freeing result set at 0xb7b78bb0 5(18649) DEBUG: auth [challenge.c:102]: build_challenge_hf: realm='nymgo.com' 5(18649) DEBUG: auth [challenge.c:244]: auth: 'WWW-Authenticate: Digest realm="domain.com", nonce="TwMcuk8DG47SLxatlNdZfyfR8p3OiyAE" '
I rebuilt the hashes against domain.com and then tried to connect to sip1.domain.com and sip2.domain.com and sip3.domain.com with all of the having
# ----- auth_db params ----- #!ifdef WITH_AUTH modparam("auth_db", "db_url", DBURL) modparam("auth_db", "calculate_ha1", 0 ) modparam("auth_db", "password_column", "ha1") modparam("auth_db", "load_credentials", "") modparam("auth_db", "use_domain", MULTIDOMAIN)
And in the routing process :
if (!www_authorize("domain.com", "subscriber")) {
www_challenge("domain.com", "0"); exit; }
+++++++++++++
My point is that the hashes are caculated from user:doman:pwd which are extracted from the SIP packet and in this case the domains are sip1,sip2,sip3 while the hashes stored in the database are generated against domain.com
If " ha1 is actually hash over 'user:realm:pwd' " shouldn't I have to set the domain/realm in the config file ?
the first parameter in www_authorize and www_challenge functions is the realm and it is used to build the digest response.
Is your phone putting user@domain in authorization header? Can you paste here the ngrep of registration?
Cheers, Daniel
I might be wrong....thanks for the help so far.
Regards
On Tue, Jan 3, 2012 at 5:15 PM, Daniel-Constantin Mierla miconda@gmail.com wrote: > > Hello, > > > On 1/3/12 4:12 PM, Ali Jawad wrote: >> >> Hi Daniel >> This certainly makes sense, I will try it in a few mins, but what I >> observed at Debug Level 3 is that Hash is calculated before >> www_authenticate is executed and it shows HA comparison failed, if I >> do use domain.com instead of $fd and use $domain.com in db domain >> field and build HA1 filed based on that, wont Kamailio still try to >> build the HA1 hash which it will compare form user:domain:pwd where >> domain is fed in to the hash function from the header of the SIP >> packet ? > > > the ha1 is actually hash over 'user:realm:pwd' -- it is just common > practice > to use the domain as realm, since realm should be a unique token to > identify > the service, but it can be any random string. realm is given as > parameter > to auth functions in kamailio.cfg > > Cheers, > Daniel > > >> Regards >> >> On Tue, Jan 3, 2012 at 5:07 PM, Daniel-Constantin Mierla >> miconda@gmail.com wrote: >>> >>> Hello, >>> >>> you can simply use 'domain.com' as realm parameter to >>> authentication >>> function instead of $fd. Also build ha1 and ha1b with domain.com >>> and >>> then >>> you are safe no matter which sip server is used. >>> >>> Of course you can build the realm by striping first token before >>> '.' >>> in >>> $fd >>> and pass it to authentication functions, but not sure if makes >>> sense >>> since >>> it should be always domain.com >>> >>> Cheers, >>> Daniel >>> >>> >>> On 1/3/12 3:15 PM, Ali Jawad wrote: >>>> >>>> Hi >>>> After some research it seems to me that the only way to achieve >>>> this >>>> is to "try" and change how hashing is done in the source code, a >>>> little bit too ambitious for me, and it means I will have loads of >>>> problems each time an upgrade is released. >>>> >>>> Or >>>> >>>> Use pseudovariables to fix the value of the $fd value to something >>>> constant, while this worked for values like $var(y) I was not able >>>> to >>>> assign/strip $fd to remove the subdomain part. >>>> >>>> Any input please ? >>>> >>>> Regards >>>> >>>> On Tue, Jan 3, 2012 at 2:06 PM, Ali Jawadali.jawad@splendor.net >>>> wrote: >>>>> >>>>> Hi >>>>> I do have 3 Kamailio servers, one for mobile phone registrations, >>>>> one >>>>> for softphone registrations and one for SIP device registrations. >>>>> Each >>>>> of those devices connects to it's perspective kamailio server >>>>> >>>>> sip1.domain.com >>>>> sip2.domain.com >>>>> sip3.domain.com >>>>> >>>>> All 3 Kamailio servers share the same database, and users can use >>>>> their kamailio user/pwd on any of the devices, now I want to use >>>>> encrypted passwords and remove clear text passwords from the >>>>> database. >>>>> I did test with one server and all is fine,however if a user want >>>>> to >>>>> register from the second kamailio server it does not work, >>>>> basically >>>>> because the db domain entry from which the hash is created is >>>>> sip1.domain.com and stored in the db, while the user connects >>>>> from >>>>> to >>>>> sip2.domain.com this eventually generates a different hash. >>>>> >>>>> Is there anyway to overcome this ? Can I exclude Domain from Hash >>>>> generation ? Any other option that allows me to do the above ? >>>>> >>>>> Thanks >>>> >>>> >>>> >>> -- >>> Daniel-Constantin Mierla -- http://www.asipto.com >>> http://linkedin.com/in/miconda -- http://twitter.com/miconda >>> >> -- >> Daniel-Constantin Mierla -- http://www.asipto.com >> http://linkedin.com/in/miconda -- http://twitter.com/miconda
-- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda
-- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda
-- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda
Hello,
On 1/3/12 10:08 PM, Ali Jawad wrote:
Hi In Xlite/eyebeam I put in the username and one of my 3 kamailio servers respectively as the sip registrar, I.e. register1.domain.com, register2.domain.com and register3.domain.com, that is why I was saying that hashing will create different hashes based on the register domain. With reference to my first related post, one kamailio server is for softphones, one for sip devices and one for mobile phones with SIP software. Each server has a slightly different NAT and Call routing structure.
but your service domain is 'domain.com', specific server addresses (domains) per UA type should be set as outbound proxy on the UA devices.
This is why I wanted to eliminate the domain factor from the hashing procedure, I am sure it chooses the right value from the DB value because it is the same value shown in the log of kamailio against which a comparison is being done and because it works if I put register.domain.com in the domain column rehash the HA! value of the db.
When auth_db module is configured to take the hashed value from database (calculate_ha1 parameter is 0), there is no more computation of it in kamailio -- it is just fetched from database and used -- so it does not matter anymore the domains in the sip message.
Check to see if the xlite does not have a realm field that has to be set properly.
values at 0xb7b78dac > 5(18649) DEBUG:<core> [db_val.c:117]: converting STRING > [6f966cd9c628f14cdc20172f96a4d065]<====##### This is the value in the DB based on domain.com > 5(18649) DEBUG: auth [api.c:210]: check_response: Our result = > '6f95e6235edca0b7765042ef119fd83b'<====##### This value appears to be the value generated register.domain.com > 5(18649) DEBUG: auth [api.c:220]: check_response: Authorization
How can I enable the SQL query log ?
I don't know by hart, googling should help you.
Cheers, Daniel
On Tue, Jan 3, 2012 at 8:12 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
why are you using register.domain.com as domain for registration? Isn't domain.com the right one?
Can you enable the sql query log for mysql server and double check if the right value (column) is selected from the database table?
Cheers, Daniel
On 1/3/12 5:13 PM, Ali Jawad wrote:
Hi Please see the below, thanks !
interface: eth1 (xx.xx.xx.0/255.255.255.0) match: support1
U +6.698682 yy.yy.yy.146:18832 -> xx.xx.xx.51:5060 REGISTER sip:register.domain.com SIP/2.0. Via: SIP/2.0/UDP
192.168.0.191:18832;branch=z9hG4bK-d8754z-05164a466600837d-1---d8754z-;rport. Max-Forwards: 70.
Contact:sip:support1@192.168.0.191:18832;rinstance=f8e37e314657e0d7;transport=udp. To: "Test Ast"sip:support1@register.domain.com. From: "Test Ast"sip:support1@register.domain.com;tag=f710b930. Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY.. CSeq: 1 REGISTER. Expires: 3600. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. User-Agent: eyeBeam release 1102q stamp 51814. Content-Length: 0. .
U +0.005245 xx.xx.xx.51:5060 -> yy.yy.yy.146:18832 SIP/2.0 401 Unauthorized. Via: SIP/2.0/UDP
192.168.0.191:18832;branch=z9hG4bK-d8754z-05164a466600837d-1---d8754z-;rport=18832;received=yy.yy.yy.146. To: "Test Ast"sip:support1@register.domain.com;tag=e597ca73bdb255490f0cefa03b2fda82.3053. From: "Test Ast"sip:support1@register.domain.com;tag=f710b930. Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY.. CSeq: 1 REGISTER. WWW-Authenticate: Digest realm="domain.com", nonce="TwMpUE8DKCSt/IP7jcNRMbCT4TnbqlHl". Server: kamailio (3.2.1 (i386/linux)). Content-Length: 0. .
U +0.428042 yy.yy.yy.146:18832 -> xx.xx.xx.51:5060 REGISTER sip:register.domain.com SIP/2.0. Via: SIP/2.0/UDP
192.168.0.191:18832;branch=z9hG4bK-d8754z-fc633b21627dca6d-1---d8754z-;rport. Max-Forwards: 70.
Contact:sip:support1@192.168.0.191:18832;rinstance=f8e37e314657e0d7;transport=udp. To: "Test Ast"sip:support1@register.domain.com. From: "Test Ast"sip:support1@register.domain.com;tag=f710b930. Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY.. CSeq: 2 REGISTER. Expires: 3600. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. User-Agent: eyeBeam release 1102q stamp 51814. Authorization: Digest
username="support1",realm="domain.com",nonce="TwMpUE8DKCSt/IP7jcNRMbCT4TnbqlHl",uri="sip:register.domain.com",response="6122245b77e2df0b90179304464341e7",algorithm=MD5. Content-Length: 0. .
U +0.005146 xx.xx.xx.51:5060 -> yy.yy.yy.146:18832 SIP/2.0 401 Unauthorized. Via: SIP/2.0/UDP
192.168.0.191:18832;branch=z9hG4bK-d8754z-fc633b21627dca6d-1---d8754z-;rport=18832;received=yy.yy.yy.146. To: "Test Ast"sip:support1@register.domain.com;tag=e597ca73bdb255490f0cefa03b2fda82.fce3. From: "Test Ast"sip:support1@register.domain.com;tag=f710b930. Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY.. CSeq: 2 REGISTER. WWW-Authenticate: Digest realm="domain.com", nonce="TwMpUE8DKCSt/IP7jcNRMbCT4TnbqlHl". Server: kamailio (3.2.1 (i386/linux)). Content-Length: 0. .
[root@kam-rtp-100-51 mysql]# mail alijawad1@gmail.com< output.txt [root@kam-rtp-100-51 mysql]# ngrep -W byline -T support1 -q -d eth1 interface: eth1 (xx.xx.xx.0/255.255.255.0) match: support1
U +5.321505 yy.yy.yy.146:63610 -> xx.xx.xx.51:5060 REGISTER sip:register.domain.com SIP/2.0. Via: SIP/2.0/UDP
192.168.0.191:63610;branch=z9hG4bK-d8754z-fb28723daa3f772d-1---d8754z-;rport. Max-Forwards: 70.
Contact:sip:support1@192.168.0.191:63610;rinstance=782b19a2fccc665f;transport=udp. To: "Test Ast"sip:support1@register.domain.com. From: "Test Ast"sip:support1@register.domain.com;tag=ba705453. Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI.. CSeq: 1 REGISTER. Expires: 3600. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. User-Agent: eyeBeam release 1102q stamp 51814. Content-Length: 0. .
U +0.004782 xx.xx.xx.51:5060 -> yy.yy.yy.146:63610 SIP/2.0 401 Unauthorized. Via: SIP/2.0/UDP
192.168.0.191:63610;branch=z9hG4bK-d8754z-fb28723daa3f772d-1---d8754z-;rport=63610;received=yy.yy.yy.146. To: "Test Ast"sip:support1@register.domain.com;tag=e597ca73bdb255490f0cefa03b2fda82.6b98. From: "Test Ast"sip:support1@register.domain.com;tag=ba705453. Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI.. CSeq: 1 REGISTER. WWW-Authenticate: Digest realm="domain.com", nonce="TwMpsU8DKIX4lvWDwPsV4iUhCl+iOAdk". Server: kamailio (3.2.1 (i386/linux)). Content-Length: 0. .
U +0.400706 yy.yy.yy.146:63610 -> xx.xx.xx.51:5060 REGISTER sip:register.domain.com SIP/2.0. Via: SIP/2.0/UDP
192.168.0.191:63610;branch=z9hG4bK-d8754z-81517d296225234f-1---d8754z-;rport. Max-Forwards: 70.
Contact:sip:support1@192.168.0.191:63610;rinstance=782b19a2fccc665f;transport=udp. To: "Test Ast"sip:support1@register.domain.com. From: "Test Ast"sip:support1@register.domain.com;tag=ba705453. Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI.. CSeq: 2 REGISTER. Expires: 3600. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. User-Agent: eyeBeam release 1102q stamp 51814. Authorization: Digest
username="support1",realm="domain.com",nonce="TwMpsU8DKIX4lvWDwPsV4iUhCl+iOAdk",uri="sip:register.domain.com",response="4bfd80b0b836c20b748ee19a1c886284",algorithm=MD5. Content-Length: 0. .
U +0.005302 xx.xx.xx.51:5060 -> yy.yy.yy.146:63610 SIP/2.0 401 Unauthorized. Via: SIP/2.0/UDP
192.168.0.191:63610;branch=z9hG4bK-d8754z-81517d296225234f-1---d8754z-;rport=63610;received=yy.yy.yy.146. To: "Test Ast"sip:support1@register.domain.com;tag=e597ca73bdb255490f0cefa03b2fda82.2f76. From: "Test Ast"sip:support1@register.domain.com;tag=ba705453. Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI.. CSeq: 2 REGISTER. WWW-Authenticate: Digest realm="domain.com", nonce="TwMpsU8DKIX4lvWDwPsV4iUhCl+iOAdk". Server: kamailio (3.2.1 (i386/linux)). Content-Length: 0. .
On Tue, Jan 3, 2012 at 6:08 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
I need the entire flow for registration, including the 401 reply and the following REGISTER request.
Cheers, Daniel
On 1/3/12 5:02 PM, Ali Jawad wrote:
Hi Please see the ngrep below, please note that if I use in the db register.domain.com and generate a hash against it for HA1 it works,but then the user cant logon to register2.domain.com
U +10.630576 xx.yy.yy.yy:20020 -> xx.xx.xx.xx:5060 REGISTER sip:register.domain SIP/2.0. Via: SIP/2.0/UDP
192.168.0.191:20020;branch=z9hG4bK-d8754z-af65a442980c375f-1---d8754z-;rport. Max-Forwards: 70.
Contact:sip:support1@192.168.0.191:20020;rinstance=4009190a4e109ac6;transport=udp. To: "Test Ast"sip:support1@register.domain. From: "Test Ast"sip:support1@register.domain;tag=976bb004. Call-ID: MDFmZDU2ZTI2YjJjMGNlMGFmOTIzMWFmZGQ1ZTNjMDE.. CSeq: 1 REGISTER. Expires: 3600. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. User-Agent: eyeBeam release 1102q stamp 51814. Content-Length: 0.
On Tue, Jan 3, 2012 at 5:58 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
On 1/3/12 4:48 PM, Ali Jawad wrote: > Hi Daniel > > Please see > > 5(18649) DEBUG:<core> [db_res.c:184]: allocate 8 bytes for rows > at > 0xb7b78d74 > 5(18649) DEBUG:<core> [db_row.c:119]: allocate 20 bytes for row > values at 0xb7b78dac > 5(18649) DEBUG:<core> [db_val.c:117]: converting STRING > [6f966cd9c628f14cdc20172f96a4d065] > 5(18649) DEBUG: auth [api.c:210]: check_response: Our result = > '6f95e6235edca0b7765042ef119fd83b' > 5(18649) DEBUG: auth [api.c:220]: check_response: Authorization > failed > 5(18649) DEBUG:<core> [db_res.c:81]: freeing 1 columns > 5(18649) DEBUG:<core> [db_res.c:85]: freeing RES_NAMES[0] at > 0xb7b78d3c > 5(18649) DEBUG:<core> [db_res.c:94]: freeing result names at > 0xb7b78bfc > 5(18649) DEBUG:<core> [db_res.c:99]: freeing result types at > 0xb7b78c64 > 5(18649) DEBUG:<core> [db_res.c:54]: freeing 1 rows > 5(18649) DEBUG:<core> [db_row.c:97]: freeing row values at > 0xb7b78dac > 5(18649) DEBUG:<core> [db_res.c:62]: freeing rows at 0xb7b78d74 > 5(18649) DEBUG:<core> [db_res.c:136]: freeing result set at > 0xb7b78bb0 > 5(18649) DEBUG: auth [challenge.c:102]: build_challenge_hf: > realm='nymgo.com' > 5(18649) DEBUG: auth [challenge.c:244]: auth: 'WWW-Authenticate: > Digest realm="domain.com", nonce="TwMcuk8DG47SLxatlNdZfyfR8p3OiyAE" > ' > > I rebuilt the hashes against domain.com and then tried to connect to > sip1.domain.com and sip2.domain.com and sip3.domain.com with all of > the having > > > # ----- auth_db params ----- > #!ifdef WITH_AUTH > modparam("auth_db", "db_url", DBURL) > modparam("auth_db", "calculate_ha1", 0 ) > modparam("auth_db", "password_column", "ha1") > modparam("auth_db", "load_credentials", "") > modparam("auth_db", "use_domain", MULTIDOMAIN) > > And in the routing process : > > if (!www_authorize("domain.com", "subscriber")) > { > > www_challenge("domain.com", "0"); > exit; > } > > > +++++++++++++ > > My point is that the hashes are caculated from user:doman:pwd which > are extracted from the SIP packet and in this case the domains are > sip1,sip2,sip3 while the hashes stored in the database are generated > against domain.com > > If " ha1 is actually hash over 'user:realm:pwd' " shouldn't I have to > set the domain/realm in the config file ?
the first parameter in www_authorize and www_challenge functions is the realm and it is used to build the digest response.
Is your phone putting user@domain in authorization header? Can you paste here the ngrep of registration?
Cheers, Daniel
> I might be wrong....thanks for the help so far. > > Regards > > On Tue, Jan 3, 2012 at 5:15 PM, Daniel-Constantin Mierla > miconda@gmail.com wrote: >> Hello, >> >> >> On 1/3/12 4:12 PM, Ali Jawad wrote: >>> Hi Daniel >>> This certainly makes sense, I will try it in a few mins, but what I >>> observed at Debug Level 3 is that Hash is calculated before >>> www_authenticate is executed and it shows HA comparison failed, if I >>> do use domain.com instead of $fd and use $domain.com in db domain >>> field and build HA1 filed based on that, wont Kamailio still try to >>> build the HA1 hash which it will compare form user:domain:pwd where >>> domain is fed in to the hash function from the header of the SIP >>> packet ? >> >> the ha1 is actually hash over 'user:realm:pwd' -- it is just common >> practice >> to use the domain as realm, since realm should be a unique token to >> identify >> the service, but it can be any random string. realm is given as >> parameter >> to auth functions in kamailio.cfg >> >> Cheers, >> Daniel >> >> >>> Regards >>> >>> On Tue, Jan 3, 2012 at 5:07 PM, Daniel-Constantin Mierla >>> miconda@gmail.com wrote: >>>> Hello, >>>> >>>> you can simply use 'domain.com' as realm parameter to >>>> authentication >>>> function instead of $fd. Also build ha1 and ha1b with domain.com >>>> and >>>> then >>>> you are safe no matter which sip server is used. >>>> >>>> Of course you can build the realm by striping first token before >>>> '.' >>>> in >>>> $fd >>>> and pass it to authentication functions, but not sure if makes >>>> sense >>>> since >>>> it should be always domain.com >>>> >>>> Cheers, >>>> Daniel >>>> >>>> >>>> On 1/3/12 3:15 PM, Ali Jawad wrote: >>>>> Hi >>>>> After some research it seems to me that the only way to achieve >>>>> this >>>>> is to "try" and change how hashing is done in the source code, a >>>>> little bit too ambitious for me, and it means I will have loads of >>>>> problems each time an upgrade is released. >>>>> >>>>> Or >>>>> >>>>> Use pseudovariables to fix the value of the $fd value to something >>>>> constant, while this worked for values like $var(y) I was not able >>>>> to >>>>> assign/strip $fd to remove the subdomain part. >>>>> >>>>> Any input please ? >>>>> >>>>> Regards >>>>> >>>>> On Tue, Jan 3, 2012 at 2:06 PM, Ali Jawadali.jawad@splendor.net >>>>> wrote: >>>>>> Hi >>>>>> I do have 3 Kamailio servers, one for mobile phone registrations, >>>>>> one >>>>>> for softphone registrations and one for SIP device registrations. >>>>>> Each >>>>>> of those devices connects to it's perspective kamailio server >>>>>> >>>>>> sip1.domain.com >>>>>> sip2.domain.com >>>>>> sip3.domain.com >>>>>> >>>>>> All 3 Kamailio servers share the same database, and users can use >>>>>> their kamailio user/pwd on any of the devices, now I want to use >>>>>> encrypted passwords and remove clear text passwords from the >>>>>> database. >>>>>> I did test with one server and all is fine,however if a user want >>>>>> to >>>>>> register from the second kamailio server it does not work, >>>>>> basically >>>>>> because the db domain entry from which the hash is created is >>>>>> sip1.domain.com and stored in the db, while the user connects >>>>>> from >>>>>> to >>>>>> sip2.domain.com this eventually generates a different hash. >>>>>> >>>>>> Is there anyway to overcome this ? Can I exclude Domain from Hash >>>>>> generation ? Any other option that allows me to do the above ? >>>>>> >>>>>> Thanks >>>>> >>>>> >>>> -- >>>> Daniel-Constantin Mierla -- http://www.asipto.com >>>> http://linkedin.com/in/miconda -- http://twitter.com/miconda >>>> >>> -- >>> Daniel-Constantin Mierla -- http://www.asipto.com >>> http://linkedin.com/in/miconda -- http://twitter.com/miconda >
>
Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda
-- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda
-- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda
Hi It fetches one value from the database to compare it against a second value that has to be computed right, in the computation of the second hash where is the domain part fetched from ? Regards
On Wed, Jan 4, 2012 at 12:26 AM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
On 1/3/12 10:08 PM, Ali Jawad wrote:
Hi
In Xlite/eyebeam I put in the username and one of my 3 kamailio servers respectively as the sip registrar, I.e. register1.domain.com, register2.domain.com and register3.domain.com, that is why I was saying that hashing will create different hashes based on the register domain. With reference to my first related post, one kamailio server is for softphones, one for sip devices and one for mobile phones with SIP software. Each server has a slightly different NAT and Call routing structure.
but your service domain is 'domain.com', specific server addresses (domains) per UA type should be set as outbound proxy on the UA devices.
This is why I wanted to eliminate the domain factor from the hashing procedure, I am sure it chooses the right value from the DB value because it is the same value shown in the log of kamailio against which a comparison is being done and because it works if I put register.domain.com in the domain column rehash the HA! value of the db.
When auth_db module is configured to take the hashed value from database (calculate_ha1 parameter is 0), there is no more computation of it in kamailio -- it is just fetched from database and used -- so it does not matter anymore the domains in the sip message.
Check to see if the xlite does not have a realm field that has to be set properly.
> values at 0xb7b78dac >> >> 5(18649) DEBUG:<core> [db_val.c:117]: converting STRING >> [6f966cd9c628f14cdc20172f96a4d065]<====##### This is the value in >> the DB based on domain.com >> 5(18649) DEBUG: auth [api.c:210]: check_response: Our result = >> '6f95e6235edca0b7765042ef119fd83b'<====##### This value appears to >> be the value generated register.domain.com >> 5(18649) DEBUG: auth [api.c:220]: check_response: Authorization
How can I enable the SQL query log ?
I don't know by hart, googling should help you.
Cheers, Daniel
On Tue, Jan 3, 2012 at 8:12 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
why are you using register.domain.com as domain for registration? Isn't domain.com the right one?
Can you enable the sql query log for mysql server and double check if the right value (column) is selected from the database table?
Cheers, Daniel
On 1/3/12 5:13 PM, Ali Jawad wrote:
Hi Please see the below, thanks !
interface: eth1 (xx.xx.xx.0/255.255.255.0) match: support1
U +6.698682 yy.yy.yy.146:18832 -> xx.xx.xx.51:5060 REGISTER sip:register.domain.com SIP/2.0. Via: SIP/2.0/UDP
192.168.0.191:18832;branch=z9hG4bK-d8754z-05164a466600837d-1---d8754z-;rport. Max-Forwards: 70.
Contact:sip:support1@192.168.0.191:18832;rinstance=f8e37e314657e0d7;transport=udp. To: "Test Ast"sip:support1@register.domain.com. From: "Test Ast"sip:support1@register.domain.com;tag=f710b930. Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY.. CSeq: 1 REGISTER. Expires: 3600. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. User-Agent: eyeBeam release 1102q stamp 51814. Content-Length: 0. .
U +0.005245 xx.xx.xx.51:5060 -> yy.yy.yy.146:18832 SIP/2.0 401 Unauthorized. Via: SIP/2.0/UDP
192.168.0.191:18832;branch=z9hG4bK-d8754z-05164a466600837d-1---d8754z-;rport=18832;received=yy.yy.yy.146. To: "Test
Ast"sip:support1@register.domain.com;tag=e597ca73bdb255490f0cefa03b2fda82.3053. From: "Test Ast"sip:support1@register.domain.com;tag=f710b930. Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY.. CSeq: 1 REGISTER. WWW-Authenticate: Digest realm="domain.com", nonce="TwMpUE8DKCSt/IP7jcNRMbCT4TnbqlHl". Server: kamailio (3.2.1 (i386/linux)). Content-Length: 0. .
U +0.428042 yy.yy.yy.146:18832 -> xx.xx.xx.51:5060 REGISTER sip:register.domain.com SIP/2.0. Via: SIP/2.0/UDP
192.168.0.191:18832;branch=z9hG4bK-d8754z-fc633b21627dca6d-1---d8754z-;rport. Max-Forwards: 70.
Contact:sip:support1@192.168.0.191:18832;rinstance=f8e37e314657e0d7;transport=udp. To: "Test Ast"sip:support1@register.domain.com. From: "Test Ast"sip:support1@register.domain.com;tag=f710b930. Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY.. CSeq: 2 REGISTER. Expires: 3600. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. User-Agent: eyeBeam release 1102q stamp 51814. Authorization: Digest
username="support1",realm="domain.com",nonce="TwMpUE8DKCSt/IP7jcNRMbCT4TnbqlHl",uri="sip:register.domain.com",response="6122245b77e2df0b90179304464341e7",algorithm=MD5. Content-Length: 0. .
U +0.005146 xx.xx.xx.51:5060 -> yy.yy.yy.146:18832 SIP/2.0 401 Unauthorized. Via: SIP/2.0/UDP
192.168.0.191:18832;branch=z9hG4bK-d8754z-fc633b21627dca6d-1---d8754z-;rport=18832;received=yy.yy.yy.146. To: "Test
Ast"sip:support1@register.domain.com;tag=e597ca73bdb255490f0cefa03b2fda82.fce3. From: "Test Ast"sip:support1@register.domain.com;tag=f710b930. Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY.. CSeq: 2 REGISTER. WWW-Authenticate: Digest realm="domain.com", nonce="TwMpUE8DKCSt/IP7jcNRMbCT4TnbqlHl". Server: kamailio (3.2.1 (i386/linux)). Content-Length: 0. .
[root@kam-rtp-100-51 mysql]# mail alijawad1@gmail.com< output.txt [root@kam-rtp-100-51 mysql]# ngrep -W byline -T support1 -q -d eth1 interface: eth1 (xx.xx.xx.0/255.255.255.0) match: support1
U +5.321505 yy.yy.yy.146:63610 -> xx.xx.xx.51:5060 REGISTER sip:register.domain.com SIP/2.0. Via: SIP/2.0/UDP
192.168.0.191:63610;branch=z9hG4bK-d8754z-fb28723daa3f772d-1---d8754z-;rport. Max-Forwards: 70.
Contact:sip:support1@192.168.0.191:63610;rinstance=782b19a2fccc665f;transport=udp. To: "Test Ast"sip:support1@register.domain.com. From: "Test Ast"sip:support1@register.domain.com;tag=ba705453. Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI.. CSeq: 1 REGISTER. Expires: 3600. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. User-Agent: eyeBeam release 1102q stamp 51814. Content-Length: 0. .
U +0.004782 xx.xx.xx.51:5060 -> yy.yy.yy.146:63610 SIP/2.0 401 Unauthorized. Via: SIP/2.0/UDP
192.168.0.191:63610;branch=z9hG4bK-d8754z-fb28723daa3f772d-1---d8754z-;rport=63610;received=yy.yy.yy.146. To: "Test
Ast"sip:support1@register.domain.com;tag=e597ca73bdb255490f0cefa03b2fda82.6b98. From: "Test Ast"sip:support1@register.domain.com;tag=ba705453. Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI.. CSeq: 1 REGISTER. WWW-Authenticate: Digest realm="domain.com", nonce="TwMpsU8DKIX4lvWDwPsV4iUhCl+iOAdk". Server: kamailio (3.2.1 (i386/linux)). Content-Length: 0. .
U +0.400706 yy.yy.yy.146:63610 -> xx.xx.xx.51:5060 REGISTER sip:register.domain.com SIP/2.0. Via: SIP/2.0/UDP
192.168.0.191:63610;branch=z9hG4bK-d8754z-81517d296225234f-1---d8754z-;rport. Max-Forwards: 70.
Contact:sip:support1@192.168.0.191:63610;rinstance=782b19a2fccc665f;transport=udp. To: "Test Ast"sip:support1@register.domain.com. From: "Test Ast"sip:support1@register.domain.com;tag=ba705453. Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI.. CSeq: 2 REGISTER. Expires: 3600. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. User-Agent: eyeBeam release 1102q stamp 51814. Authorization: Digest
username="support1",realm="domain.com",nonce="TwMpsU8DKIX4lvWDwPsV4iUhCl+iOAdk",uri="sip:register.domain.com",response="4bfd80b0b836c20b748ee19a1c886284",algorithm=MD5. Content-Length: 0. .
U +0.005302 xx.xx.xx.51:5060 -> yy.yy.yy.146:63610 SIP/2.0 401 Unauthorized. Via: SIP/2.0/UDP
192.168.0.191:63610;branch=z9hG4bK-d8754z-81517d296225234f-1---d8754z-;rport=63610;received=yy.yy.yy.146. To: "Test
Ast"sip:support1@register.domain.com;tag=e597ca73bdb255490f0cefa03b2fda82.2f76. From: "Test Ast"sip:support1@register.domain.com;tag=ba705453. Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI.. CSeq: 2 REGISTER. WWW-Authenticate: Digest realm="domain.com", nonce="TwMpsU8DKIX4lvWDwPsV4iUhCl+iOAdk". Server: kamailio (3.2.1 (i386/linux)). Content-Length: 0. .
On Tue, Jan 3, 2012 at 6:08 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
I need the entire flow for registration, including the 401 reply and the following REGISTER request.
Cheers, Daniel
On 1/3/12 5:02 PM, Ali Jawad wrote:
Hi Please see the ngrep below, please note that if I use in the db register.domain.com and generate a hash against it for HA1 it works,but then the user cant logon to register2.domain.com
U +10.630576 xx.yy.yy.yy:20020 -> xx.xx.xx.xx:5060 REGISTER sip:register.domain SIP/2.0. Via: SIP/2.0/UDP
192.168.0.191:20020;branch=z9hG4bK-d8754z-af65a442980c375f-1---d8754z-;rport. Max-Forwards: 70.
Contact:sip:support1@192.168.0.191:20020;rinstance=4009190a4e109ac6;transport=udp. To: "Test Ast"sip:support1@register.domain. From: "Test Ast"sip:support1@register.domain;tag=976bb004. Call-ID: MDFmZDU2ZTI2YjJjMGNlMGFmOTIzMWFmZGQ1ZTNjMDE.. CSeq: 1 REGISTER. Expires: 3600. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. User-Agent: eyeBeam release 1102q stamp 51814. Content-Length: 0.
On Tue, Jan 3, 2012 at 5:58 PM, Daniel-Constantin Mierla miconda@gmail.com wrote: > > Hello, > > > On 1/3/12 4:48 PM, Ali Jawad wrote: >> >> Hi Daniel >> >> Please see >> >> 5(18649) DEBUG:<core> [db_res.c:184]: allocate 8 bytes for >> rows >> at >> 0xb7b78d74 >> 5(18649) DEBUG:<core> [db_row.c:119]: allocate 20 bytes for >> row >> values at 0xb7b78dac >> 5(18649) DEBUG:<core> [db_val.c:117]: converting STRING >> [6f966cd9c628f14cdc20172f96a4d065] >> 5(18649) DEBUG: auth [api.c:210]: check_response: Our result = >> '6f95e6235edca0b7765042ef119fd83b' >> 5(18649) DEBUG: auth [api.c:220]: check_response: Authorization >> failed >> 5(18649) DEBUG:<core> [db_res.c:81]: freeing 1 columns >> 5(18649) DEBUG:<core> [db_res.c:85]: freeing RES_NAMES[0] at >> 0xb7b78d3c >> 5(18649) DEBUG:<core> [db_res.c:94]: freeing result names at >> 0xb7b78bfc >> 5(18649) DEBUG:<core> [db_res.c:99]: freeing result types at >> 0xb7b78c64 >> 5(18649) DEBUG:<core> [db_res.c:54]: freeing 1 rows >> 5(18649) DEBUG:<core> [db_row.c:97]: freeing row values at >> 0xb7b78dac >> 5(18649) DEBUG:<core> [db_res.c:62]: freeing rows at >> 0xb7b78d74 >> 5(18649) DEBUG:<core> [db_res.c:136]: freeing result set at >> 0xb7b78bb0 >> 5(18649) DEBUG: auth [challenge.c:102]: build_challenge_hf: >> realm='nymgo.com' >> 5(18649) DEBUG: auth [challenge.c:244]: auth: 'WWW-Authenticate: >> Digest realm="domain.com", nonce="TwMcuk8DG47SLxatlNdZfyfR8p3OiyAE" >> ' >> >> I rebuilt the hashes against domain.com and then tried to connect to >> sip1.domain.com and sip2.domain.com and sip3.domain.com with all of >> the having >> >> >> # ----- auth_db params ----- >> #!ifdef WITH_AUTH >> modparam("auth_db", "db_url", DBURL) >> modparam("auth_db", "calculate_ha1", 0 ) >> modparam("auth_db", "password_column", "ha1") >> modparam("auth_db", "load_credentials", "") >> modparam("auth_db", "use_domain", MULTIDOMAIN) >> >> And in the routing process : >> >> if (!www_authorize("domain.com", "subscriber")) >> { >> >> www_challenge("domain.com", "0"); >> exit; >> } >> >> >> +++++++++++++ >> >> My point is that the hashes are caculated from user:doman:pwd which >> are extracted from the SIP packet and in this case the domains are >> sip1,sip2,sip3 while the hashes stored in the database are generated >> against domain.com >> >> If " ha1 is actually hash over 'user:realm:pwd' " shouldn't I have >> to >> set the domain/realm in the config file ? > > > the first parameter in www_authorize and www_challenge functions is > the > realm and it is used to build the digest response. > > Is your phone putting user@domain in authorization header? Can you > paste > here the ngrep of registration? > > Cheers, > Daniel > > >> I might be wrong....thanks for the help so far. >> >> Regards >> >> On Tue, Jan 3, 2012 at 5:15 PM, Daniel-Constantin Mierla >> miconda@gmail.com wrote: >>> >>> Hello, >>> >>> >>> On 1/3/12 4:12 PM, Ali Jawad wrote: >>>> >>>> Hi Daniel >>>> This certainly makes sense, I will try it in a few mins, but what >>>> I >>>> observed at Debug Level 3 is that Hash is calculated before >>>> www_authenticate is executed and it shows HA comparison failed, if >>>> I >>>> do use domain.com instead of $fd and use $domain.com in db domain >>>> field and build HA1 filed based on that, wont Kamailio still try >>>> to >>>> build the HA1 hash which it will compare form user:domain:pwd >>>> where >>>> domain is fed in to the hash function from the header of the SIP >>>> packet ? >>> >>> >>> the ha1 is actually hash over 'user:realm:pwd' -- it is just common >>> practice >>> to use the domain as realm, since realm should be a unique token to >>> identify >>> the service, but it can be any random string. realm is given as >>> parameter >>> to auth functions in kamailio.cfg >>> >>> Cheers, >>> Daniel >>> >>> >>>> Regards >>>> >>>> On Tue, Jan 3, 2012 at 5:07 PM, Daniel-Constantin Mierla >>>> miconda@gmail.com wrote: >>>>> >>>>> Hello, >>>>> >>>>> you can simply use 'domain.com' as realm parameter to >>>>> authentication >>>>> function instead of $fd. Also build ha1 and ha1b with domain.com >>>>> and >>>>> then >>>>> you are safe no matter which sip server is used. >>>>> >>>>> Of course you can build the realm by striping first token before >>>>> '.' >>>>> in >>>>> $fd >>>>> and pass it to authentication functions, but not sure if makes >>>>> sense >>>>> since >>>>> it should be always domain.com >>>>> >>>>> Cheers, >>>>> Daniel >>>>> >>>>> >>>>> On 1/3/12 3:15 PM, Ali Jawad wrote: >>>>>> >>>>>> Hi >>>>>> After some research it seems to me that the only way to achieve >>>>>> this >>>>>> is to "try" and change how hashing is done in the source code, a >>>>>> little bit too ambitious for me, and it means I will have loads >>>>>> of >>>>>> problems each time an upgrade is released. >>>>>> >>>>>> Or >>>>>> >>>>>> Use pseudovariables to fix the value of the $fd value to >>>>>> something >>>>>> constant, while this worked for values like $var(y) I was not >>>>>> able >>>>>> to >>>>>> assign/strip $fd to remove the subdomain part. >>>>>> >>>>>> Any input please ? >>>>>> >>>>>> Regards >>>>>> >>>>>> On Tue, Jan 3, 2012 at 2:06 PM, Ali >>>>>> Jawadali.jawad@splendor.net >>>>>> wrote: >>>>>>> >>>>>>> Hi >>>>>>> I do have 3 Kamailio servers, one for mobile phone >>>>>>> registrations, >>>>>>> one >>>>>>> for softphone registrations and one for SIP device >>>>>>> registrations. >>>>>>> Each >>>>>>> of those devices connects to it's perspective kamailio server >>>>>>> >>>>>>> sip1.domain.com >>>>>>> sip2.domain.com >>>>>>> sip3.domain.com >>>>>>> >>>>>>> All 3 Kamailio servers share the same database, and users can >>>>>>> use >>>>>>> their kamailio user/pwd on any of the devices, now I want to >>>>>>> use >>>>>>> encrypted passwords and remove clear text passwords from the >>>>>>> database. >>>>>>> I did test with one server and all is fine,however if a user >>>>>>> want >>>>>>> to >>>>>>> register from the second kamailio server it does not work, >>>>>>> basically >>>>>>> because the db domain entry from which the hash is created is >>>>>>> sip1.domain.com and stored in the db, while the user connects >>>>>>> from >>>>>>> to >>>>>>> sip2.domain.com this eventually generates a different hash. >>>>>>> >>>>>>> Is there anyway to overcome this ? Can I exclude Domain from >>>>>>> Hash >>>>>>> generation ? Any other option that allows me to do the above ? >>>>>>> >>>>>>> Thanks >>>>>> >>>>>> >>>>>> >>>>> -- >>>>> Daniel-Constantin Mierla -- http://www.asipto.com >>>>> http://linkedin.com/in/miconda -- http://twitter.com/miconda >>>>> >>>> -- >>>> Daniel-Constantin Mierla -- http://www.asipto.com >>>> http://linkedin.com/in/miconda -- http://twitter.com/miconda >> >> >> > -- > Daniel-Constantin Mierla -- http://www.asipto.com > http://linkedin.com/in/miconda -- http://twitter.com/miconda >
-- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda
-- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda
-- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda
Hi When I did set modparam("auth_db", "calculate_ha1", 0 )
Kamailio is crashing see
Regards
On Tue, Jan 3, 2012 at 11:54 PM, Ali Jawad ali.jawad@splendor.net wrote:
Hi It fetches one value from the database to compare it against a second value that has to be computed right, in the computation of the second hash where is the domain part fetched from ? Regards
On Wed, Jan 4, 2012 at 12:26 AM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
On 1/3/12 10:08 PM, Ali Jawad wrote:
Hi
In Xlite/eyebeam I put in the username and one of my 3 kamailio servers respectively as the sip registrar, I.e. register1.domain.com, register2.domain.com and register3.domain.com, that is why I was saying that hashing will create different hashes based on the register domain. With reference to my first related post, one kamailio server is for softphones, one for sip devices and one for mobile phones with SIP software. Each server has a slightly different NAT and Call routing structure.
but your service domain is 'domain.com', specific server addresses (domains) per UA type should be set as outbound proxy on the UA devices.
This is why I wanted to eliminate the domain factor from the hashing procedure, I am sure it chooses the right value from the DB value because it is the same value shown in the log of kamailio against which a comparison is being done and because it works if I put register.domain.com in the domain column rehash the HA! value of the db.
When auth_db module is configured to take the hashed value from database (calculate_ha1 parameter is 0), there is no more computation of it in kamailio -- it is just fetched from database and used -- so it does not matter anymore the domains in the sip message.
Check to see if the xlite does not have a realm field that has to be set properly.
>> values at 0xb7b78dac >>> >>> 5(18649) DEBUG:<core> [db_val.c:117]: converting STRING >>> [6f966cd9c628f14cdc20172f96a4d065]<====##### This is the value in >>> the DB based on domain.com >>> 5(18649) DEBUG: auth [api.c:210]: check_response: Our result = >>> '6f95e6235edca0b7765042ef119fd83b'<====##### This value appears to >>> be the value generated register.domain.com >>> 5(18649) DEBUG: auth [api.c:220]: check_response: Authorization
How can I enable the SQL query log ?
I don't know by hart, googling should help you.
Cheers, Daniel
On Tue, Jan 3, 2012 at 8:12 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
why are you using register.domain.com as domain for registration? Isn't domain.com the right one?
Can you enable the sql query log for mysql server and double check if the right value (column) is selected from the database table?
Cheers, Daniel
On 1/3/12 5:13 PM, Ali Jawad wrote:
Hi Please see the below, thanks !
interface: eth1 (xx.xx.xx.0/255.255.255.0) match: support1
U +6.698682 yy.yy.yy.146:18832 -> xx.xx.xx.51:5060 REGISTER sip:register.domain.com SIP/2.0. Via: SIP/2.0/UDP
192.168.0.191:18832;branch=z9hG4bK-d8754z-05164a466600837d-1---d8754z-;rport. Max-Forwards: 70.
Contact:sip:support1@192.168.0.191:18832;rinstance=f8e37e314657e0d7;transport=udp. To: "Test Ast"sip:support1@register.domain.com. From: "Test Ast"sip:support1@register.domain.com;tag=f710b930. Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY.. CSeq: 1 REGISTER. Expires: 3600. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. User-Agent: eyeBeam release 1102q stamp 51814. Content-Length: 0. .
U +0.005245 xx.xx.xx.51:5060 -> yy.yy.yy.146:18832 SIP/2.0 401 Unauthorized. Via: SIP/2.0/UDP
192.168.0.191:18832;branch=z9hG4bK-d8754z-05164a466600837d-1---d8754z-;rport=18832;received=yy.yy.yy.146. To: "Test
Ast"sip:support1@register.domain.com;tag=e597ca73bdb255490f0cefa03b2fda82.3053. From: "Test Ast"sip:support1@register.domain.com;tag=f710b930. Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY.. CSeq: 1 REGISTER. WWW-Authenticate: Digest realm="domain.com", nonce="TwMpUE8DKCSt/IP7jcNRMbCT4TnbqlHl". Server: kamailio (3.2.1 (i386/linux)). Content-Length: 0. .
U +0.428042 yy.yy.yy.146:18832 -> xx.xx.xx.51:5060 REGISTER sip:register.domain.com SIP/2.0. Via: SIP/2.0/UDP
192.168.0.191:18832;branch=z9hG4bK-d8754z-fc633b21627dca6d-1---d8754z-;rport. Max-Forwards: 70.
Contact:sip:support1@192.168.0.191:18832;rinstance=f8e37e314657e0d7;transport=udp. To: "Test Ast"sip:support1@register.domain.com. From: "Test Ast"sip:support1@register.domain.com;tag=f710b930. Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY.. CSeq: 2 REGISTER. Expires: 3600. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. User-Agent: eyeBeam release 1102q stamp 51814. Authorization: Digest
username="support1",realm="domain.com",nonce="TwMpUE8DKCSt/IP7jcNRMbCT4TnbqlHl",uri="sip:register.domain.com",response="6122245b77e2df0b90179304464341e7",algorithm=MD5. Content-Length: 0. .
U +0.005146 xx.xx.xx.51:5060 -> yy.yy.yy.146:18832 SIP/2.0 401 Unauthorized. Via: SIP/2.0/UDP
192.168.0.191:18832;branch=z9hG4bK-d8754z-fc633b21627dca6d-1---d8754z-;rport=18832;received=yy.yy.yy.146. To: "Test
Ast"sip:support1@register.domain.com;tag=e597ca73bdb255490f0cefa03b2fda82.fce3. From: "Test Ast"sip:support1@register.domain.com;tag=f710b930. Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY.. CSeq: 2 REGISTER. WWW-Authenticate: Digest realm="domain.com", nonce="TwMpUE8DKCSt/IP7jcNRMbCT4TnbqlHl". Server: kamailio (3.2.1 (i386/linux)). Content-Length: 0. .
[root@kam-rtp-100-51 mysql]# mail alijawad1@gmail.com< output.txt [root@kam-rtp-100-51 mysql]# ngrep -W byline -T support1 -q -d eth1 interface: eth1 (xx.xx.xx.0/255.255.255.0) match: support1
U +5.321505 yy.yy.yy.146:63610 -> xx.xx.xx.51:5060 REGISTER sip:register.domain.com SIP/2.0. Via: SIP/2.0/UDP
192.168.0.191:63610;branch=z9hG4bK-d8754z-fb28723daa3f772d-1---d8754z-;rport. Max-Forwards: 70.
Contact:sip:support1@192.168.0.191:63610;rinstance=782b19a2fccc665f;transport=udp. To: "Test Ast"sip:support1@register.domain.com. From: "Test Ast"sip:support1@register.domain.com;tag=ba705453. Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI.. CSeq: 1 REGISTER. Expires: 3600. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. User-Agent: eyeBeam release 1102q stamp 51814. Content-Length: 0. .
U +0.004782 xx.xx.xx.51:5060 -> yy.yy.yy.146:63610 SIP/2.0 401 Unauthorized. Via: SIP/2.0/UDP
192.168.0.191:63610;branch=z9hG4bK-d8754z-fb28723daa3f772d-1---d8754z-;rport=63610;received=yy.yy.yy.146. To: "Test
Ast"sip:support1@register.domain.com;tag=e597ca73bdb255490f0cefa03b2fda82.6b98. From: "Test Ast"sip:support1@register.domain.com;tag=ba705453. Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI.. CSeq: 1 REGISTER. WWW-Authenticate: Digest realm="domain.com", nonce="TwMpsU8DKIX4lvWDwPsV4iUhCl+iOAdk". Server: kamailio (3.2.1 (i386/linux)). Content-Length: 0. .
U +0.400706 yy.yy.yy.146:63610 -> xx.xx.xx.51:5060 REGISTER sip:register.domain.com SIP/2.0. Via: SIP/2.0/UDP
192.168.0.191:63610;branch=z9hG4bK-d8754z-81517d296225234f-1---d8754z-;rport. Max-Forwards: 70.
Contact:sip:support1@192.168.0.191:63610;rinstance=782b19a2fccc665f;transport=udp. To: "Test Ast"sip:support1@register.domain.com. From: "Test Ast"sip:support1@register.domain.com;tag=ba705453. Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI.. CSeq: 2 REGISTER. Expires: 3600. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. User-Agent: eyeBeam release 1102q stamp 51814. Authorization: Digest
username="support1",realm="domain.com",nonce="TwMpsU8DKIX4lvWDwPsV4iUhCl+iOAdk",uri="sip:register.domain.com",response="4bfd80b0b836c20b748ee19a1c886284",algorithm=MD5. Content-Length: 0. .
U +0.005302 xx.xx.xx.51:5060 -> yy.yy.yy.146:63610 SIP/2.0 401 Unauthorized. Via: SIP/2.0/UDP
192.168.0.191:63610;branch=z9hG4bK-d8754z-81517d296225234f-1---d8754z-;rport=63610;received=yy.yy.yy.146. To: "Test
Ast"sip:support1@register.domain.com;tag=e597ca73bdb255490f0cefa03b2fda82.2f76. From: "Test Ast"sip:support1@register.domain.com;tag=ba705453. Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI.. CSeq: 2 REGISTER. WWW-Authenticate: Digest realm="domain.com", nonce="TwMpsU8DKIX4lvWDwPsV4iUhCl+iOAdk". Server: kamailio (3.2.1 (i386/linux)). Content-Length: 0. .
On Tue, Jan 3, 2012 at 6:08 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
I need the entire flow for registration, including the 401 reply and the following REGISTER request.
Cheers, Daniel
On 1/3/12 5:02 PM, Ali Jawad wrote: > > Hi > Please see the ngrep below, please note that if I use in the db > register.domain.com and generate a hash against it for HA1 it > works,but then the user cant logon to register2.domain.com > > > U +10.630576 xx.yy.yy.yy:20020 -> xx.xx.xx.xx:5060 > REGISTER sip:register.domain SIP/2.0. > Via: SIP/2.0/UDP > > > > 192.168.0.191:20020;branch=z9hG4bK-d8754z-af65a442980c375f-1---d8754z-;rport. > Max-Forwards: 70. > > > > Contact:sip:support1@192.168.0.191:20020;rinstance=4009190a4e109ac6;transport=udp. > To: "Test Ast"sip:support1@register.domain. > From: "Test Ast"sip:support1@register.domain;tag=976bb004. > Call-ID: MDFmZDU2ZTI2YjJjMGNlMGFmOTIzMWFmZGQ1ZTNjMDE.. > CSeq: 1 REGISTER. > Expires: 3600. > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, > SUBSCRIBE, INFO. > User-Agent: eyeBeam release 1102q stamp 51814. > Content-Length: 0. > > On Tue, Jan 3, 2012 at 5:58 PM, Daniel-Constantin Mierla > miconda@gmail.com wrote: >> >> Hello, >> >> >> On 1/3/12 4:48 PM, Ali Jawad wrote: >>> >>> Hi Daniel >>> >>> Please see >>> >>> 5(18649) DEBUG:<core> [db_res.c:184]: allocate 8 bytes for >>> rows >>> at >>> 0xb7b78d74 >>> 5(18649) DEBUG:<core> [db_row.c:119]: allocate 20 bytes for >>> row >>> values at 0xb7b78dac >>> 5(18649) DEBUG:<core> [db_val.c:117]: converting STRING >>> [6f966cd9c628f14cdc20172f96a4d065] >>> 5(18649) DEBUG: auth [api.c:210]: check_response: Our result = >>> '6f95e6235edca0b7765042ef119fd83b' >>> 5(18649) DEBUG: auth [api.c:220]: check_response: Authorization >>> failed >>> 5(18649) DEBUG:<core> [db_res.c:81]: freeing 1 columns >>> 5(18649) DEBUG:<core> [db_res.c:85]: freeing RES_NAMES[0] at >>> 0xb7b78d3c >>> 5(18649) DEBUG:<core> [db_res.c:94]: freeing result names at >>> 0xb7b78bfc >>> 5(18649) DEBUG:<core> [db_res.c:99]: freeing result types at >>> 0xb7b78c64 >>> 5(18649) DEBUG:<core> [db_res.c:54]: freeing 1 rows >>> 5(18649) DEBUG:<core> [db_row.c:97]: freeing row values at >>> 0xb7b78dac >>> 5(18649) DEBUG:<core> [db_res.c:62]: freeing rows at >>> 0xb7b78d74 >>> 5(18649) DEBUG:<core> [db_res.c:136]: freeing result set at >>> 0xb7b78bb0 >>> 5(18649) DEBUG: auth [challenge.c:102]: build_challenge_hf: >>> realm='nymgo.com' >>> 5(18649) DEBUG: auth [challenge.c:244]: auth: 'WWW-Authenticate: >>> Digest realm="domain.com", nonce="TwMcuk8DG47SLxatlNdZfyfR8p3OiyAE" >>> ' >>> >>> I rebuilt the hashes against domain.com and then tried to connect to >>> sip1.domain.com and sip2.domain.com and sip3.domain.com with all of >>> the having >>> >>> >>> # ----- auth_db params ----- >>> #!ifdef WITH_AUTH >>> modparam("auth_db", "db_url", DBURL) >>> modparam("auth_db", "calculate_ha1", 0 ) >>> modparam("auth_db", "password_column", "ha1") >>> modparam("auth_db", "load_credentials", "") >>> modparam("auth_db", "use_domain", MULTIDOMAIN) >>> >>> And in the routing process : >>> >>> if (!www_authorize("domain.com", "subscriber")) >>> { >>> >>> www_challenge("domain.com", "0"); >>> exit; >>> } >>> >>> >>> +++++++++++++ >>> >>> My point is that the hashes are caculated from user:doman:pwd which >>> are extracted from the SIP packet and in this case the domains are >>> sip1,sip2,sip3 while the hashes stored in the database are generated >>> against domain.com >>> >>> If " ha1 is actually hash over 'user:realm:pwd' " shouldn't I have >>> to >>> set the domain/realm in the config file ? >> >> >> the first parameter in www_authorize and www_challenge functions is >> the >> realm and it is used to build the digest response. >> >> Is your phone putting user@domain in authorization header? Can you >> paste >> here the ngrep of registration? >> >> Cheers, >> Daniel >> >> >>> I might be wrong....thanks for the help so far. >>> >>> Regards >>> >>> On Tue, Jan 3, 2012 at 5:15 PM, Daniel-Constantin Mierla >>> miconda@gmail.com wrote: >>>> >>>> Hello, >>>> >>>> >>>> On 1/3/12 4:12 PM, Ali Jawad wrote: >>>>> >>>>> Hi Daniel >>>>> This certainly makes sense, I will try it in a few mins, but what >>>>> I >>>>> observed at Debug Level 3 is that Hash is calculated before >>>>> www_authenticate is executed and it shows HA comparison failed, if >>>>> I >>>>> do use domain.com instead of $fd and use $domain.com in db domain >>>>> field and build HA1 filed based on that, wont Kamailio still try >>>>> to >>>>> build the HA1 hash which it will compare form user:domain:pwd >>>>> where >>>>> domain is fed in to the hash function from the header of the SIP >>>>> packet ? >>>> >>>> >>>> the ha1 is actually hash over 'user:realm:pwd' -- it is just common >>>> practice >>>> to use the domain as realm, since realm should be a unique token to >>>> identify >>>> the service, but it can be any random string. realm is given as >>>> parameter >>>> to auth functions in kamailio.cfg >>>> >>>> Cheers, >>>> Daniel >>>> >>>> >>>>> Regards >>>>> >>>>> On Tue, Jan 3, 2012 at 5:07 PM, Daniel-Constantin Mierla >>>>> miconda@gmail.com wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> you can simply use 'domain.com' as realm parameter to >>>>>> authentication >>>>>> function instead of $fd. Also build ha1 and ha1b with domain.com >>>>>> and >>>>>> then >>>>>> you are safe no matter which sip server is used. >>>>>> >>>>>> Of course you can build the realm by striping first token before >>>>>> '.' >>>>>> in >>>>>> $fd >>>>>> and pass it to authentication functions, but not sure if makes >>>>>> sense >>>>>> since >>>>>> it should be always domain.com >>>>>> >>>>>> Cheers, >>>>>> Daniel >>>>>> >>>>>> >>>>>> On 1/3/12 3:15 PM, Ali Jawad wrote: >>>>>>> >>>>>>> Hi >>>>>>> After some research it seems to me that the only way to achieve >>>>>>> this >>>>>>> is to "try" and change how hashing is done in the source code, a >>>>>>> little bit too ambitious for me, and it means I will have loads >>>>>>> of >>>>>>> problems each time an upgrade is released. >>>>>>> >>>>>>> Or >>>>>>> >>>>>>> Use pseudovariables to fix the value of the $fd value to >>>>>>> something >>>>>>> constant, while this worked for values like $var(y) I was not >>>>>>> able >>>>>>> to >>>>>>> assign/strip $fd to remove the subdomain part. >>>>>>> >>>>>>> Any input please ? >>>>>>> >>>>>>> Regards >>>>>>> >>>>>>> On Tue, Jan 3, 2012 at 2:06 PM, Ali >>>>>>> Jawadali.jawad@splendor.net >>>>>>> wrote: >>>>>>>> >>>>>>>> Hi >>>>>>>> I do have 3 Kamailio servers, one for mobile phone >>>>>>>> registrations, >>>>>>>> one >>>>>>>> for softphone registrations and one for SIP device >>>>>>>> registrations. >>>>>>>> Each >>>>>>>> of those devices connects to it's perspective kamailio server >>>>>>>> >>>>>>>> sip1.domain.com >>>>>>>> sip2.domain.com >>>>>>>> sip3.domain.com >>>>>>>> >>>>>>>> All 3 Kamailio servers share the same database, and users can >>>>>>>> use >>>>>>>> their kamailio user/pwd on any of the devices, now I want to >>>>>>>> use >>>>>>>> encrypted passwords and remove clear text passwords from the >>>>>>>> database. >>>>>>>> I did test with one server and all is fine,however if a user >>>>>>>> want >>>>>>>> to >>>>>>>> register from the second kamailio server it does not work, >>>>>>>> basically >>>>>>>> because the db domain entry from which the hash is created is >>>>>>>> sip1.domain.com and stored in the db, while the user connects >>>>>>>> from >>>>>>>> to >>>>>>>> sip2.domain.com this eventually generates a different hash. >>>>>>>> >>>>>>>> Is there anyway to overcome this ? Can I exclude Domain from >>>>>>>> Hash >>>>>>>> generation ? Any other option that allows me to do the above ? >>>>>>>> >>>>>>>> Thanks >>>>>>> >>>>>>> >>>>>>> >>>>>> -- >>>>>> Daniel-Constantin Mierla -- http://www.asipto.com >>>>>> http://linkedin.com/in/miconda -- http://twitter.com/miconda >>>>>> >>>>> -- >>>>> Daniel-Constantin Mierla -- http://www.asipto.com >>>>> http://linkedin.com/in/miconda -- http://twitter.com/miconda >>> >>> >>> >> -- >> Daniel-Constantin Mierla -- http://www.asipto.com >> http://linkedin.com/in/miconda -- http://twitter.com/miconda
>>
Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda
-- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda
-- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda
-- Ali Jawad Information Systems Manager Splendor Telecom (www.splendor.net) Beirut, Lebanon Phone: +9611373725/ext 116 FAX: +9611375554
On a seperate note, am I correct to assume that in order to remove domain calculation from Kamailio I need to work around
static inline int get_ha1(struct username* _username, str* _domain, ./authorize.c: const str* _table, char* _ha1, db1_res_t** res)
in authorize.c ?
Regards On Wed, Jan 4, 2012 at 10:17 AM, Ali Jawad ali.jawad@splendor.net wrote:
Hi When I did set modparam("auth_db", "calculate_ha1", 0 )
Kamailio is crashing see
Regards
On Tue, Jan 3, 2012 at 11:54 PM, Ali Jawad ali.jawad@splendor.net wrote:
Hi It fetches one value from the database to compare it against a second value that has to be computed right, in the computation of the second hash where is the domain part fetched from ? Regards
On Wed, Jan 4, 2012 at 12:26 AM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
On 1/3/12 10:08 PM, Ali Jawad wrote:
Hi
In Xlite/eyebeam I put in the username and one of my 3 kamailio servers respectively as the sip registrar, I.e. register1.domain.com, register2.domain.com and register3.domain.com, that is why I was saying that hashing will create different hashes based on the register domain. With reference to my first related post, one kamailio server is for softphones, one for sip devices and one for mobile phones with SIP software. Each server has a slightly different NAT and Call routing structure.
but your service domain is 'domain.com', specific server addresses (domains) per UA type should be set as outbound proxy on the UA devices.
This is why I wanted to eliminate the domain factor from the hashing procedure, I am sure it chooses the right value from the DB value because it is the same value shown in the log of kamailio against which a comparison is being done and because it works if I put register.domain.com in the domain column rehash the HA! value of the db.
When auth_db module is configured to take the hashed value from database (calculate_ha1 parameter is 0), there is no more computation of it in kamailio -- it is just fetched from database and used -- so it does not matter anymore the domains in the sip message.
Check to see if the xlite does not have a realm field that has to be set properly.
>>> values at 0xb7b78dac >>>> >>>> 5(18649) DEBUG:<core> [db_val.c:117]: converting STRING >>>> [6f966cd9c628f14cdc20172f96a4d065]<====##### This is the value in >>>> the DB based on domain.com >>>> 5(18649) DEBUG: auth [api.c:210]: check_response: Our result = >>>> '6f95e6235edca0b7765042ef119fd83b'<====##### This value appears to >>>> be the value generated register.domain.com >>>> 5(18649) DEBUG: auth [api.c:220]: check_response: Authorization
How can I enable the SQL query log ?
I don't know by hart, googling should help you.
Cheers, Daniel
On Tue, Jan 3, 2012 at 8:12 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
why are you using register.domain.com as domain for registration? Isn't domain.com the right one?
Can you enable the sql query log for mysql server and double check if the right value (column) is selected from the database table?
Cheers, Daniel
On 1/3/12 5:13 PM, Ali Jawad wrote:
Hi Please see the below, thanks !
interface: eth1 (xx.xx.xx.0/255.255.255.0) match: support1
U +6.698682 yy.yy.yy.146:18832 -> xx.xx.xx.51:5060 REGISTER sip:register.domain.com SIP/2.0. Via: SIP/2.0/UDP
192.168.0.191:18832;branch=z9hG4bK-d8754z-05164a466600837d-1---d8754z-;rport. Max-Forwards: 70.
Contact:sip:support1@192.168.0.191:18832;rinstance=f8e37e314657e0d7;transport=udp. To: "Test Ast"sip:support1@register.domain.com. From: "Test Ast"sip:support1@register.domain.com;tag=f710b930. Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY.. CSeq: 1 REGISTER. Expires: 3600. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. User-Agent: eyeBeam release 1102q stamp 51814. Content-Length: 0. .
U +0.005245 xx.xx.xx.51:5060 -> yy.yy.yy.146:18832 SIP/2.0 401 Unauthorized. Via: SIP/2.0/UDP
192.168.0.191:18832;branch=z9hG4bK-d8754z-05164a466600837d-1---d8754z-;rport=18832;received=yy.yy.yy.146. To: "Test
Ast"sip:support1@register.domain.com;tag=e597ca73bdb255490f0cefa03b2fda82.3053. From: "Test Ast"sip:support1@register.domain.com;tag=f710b930. Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY.. CSeq: 1 REGISTER. WWW-Authenticate: Digest realm="domain.com", nonce="TwMpUE8DKCSt/IP7jcNRMbCT4TnbqlHl". Server: kamailio (3.2.1 (i386/linux)). Content-Length: 0. .
U +0.428042 yy.yy.yy.146:18832 -> xx.xx.xx.51:5060 REGISTER sip:register.domain.com SIP/2.0. Via: SIP/2.0/UDP
192.168.0.191:18832;branch=z9hG4bK-d8754z-fc633b21627dca6d-1---d8754z-;rport. Max-Forwards: 70.
Contact:sip:support1@192.168.0.191:18832;rinstance=f8e37e314657e0d7;transport=udp. To: "Test Ast"sip:support1@register.domain.com. From: "Test Ast"sip:support1@register.domain.com;tag=f710b930. Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY.. CSeq: 2 REGISTER. Expires: 3600. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. User-Agent: eyeBeam release 1102q stamp 51814. Authorization: Digest
username="support1",realm="domain.com",nonce="TwMpUE8DKCSt/IP7jcNRMbCT4TnbqlHl",uri="sip:register.domain.com",response="6122245b77e2df0b90179304464341e7",algorithm=MD5. Content-Length: 0. .
U +0.005146 xx.xx.xx.51:5060 -> yy.yy.yy.146:18832 SIP/2.0 401 Unauthorized. Via: SIP/2.0/UDP
192.168.0.191:18832;branch=z9hG4bK-d8754z-fc633b21627dca6d-1---d8754z-;rport=18832;received=yy.yy.yy.146. To: "Test
Ast"sip:support1@register.domain.com;tag=e597ca73bdb255490f0cefa03b2fda82.fce3. From: "Test Ast"sip:support1@register.domain.com;tag=f710b930. Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY.. CSeq: 2 REGISTER. WWW-Authenticate: Digest realm="domain.com", nonce="TwMpUE8DKCSt/IP7jcNRMbCT4TnbqlHl". Server: kamailio (3.2.1 (i386/linux)). Content-Length: 0. .
[root@kam-rtp-100-51 mysql]# mail alijawad1@gmail.com< output.txt [root@kam-rtp-100-51 mysql]# ngrep -W byline -T support1 -q -d eth1 interface: eth1 (xx.xx.xx.0/255.255.255.0) match: support1
U +5.321505 yy.yy.yy.146:63610 -> xx.xx.xx.51:5060 REGISTER sip:register.domain.com SIP/2.0. Via: SIP/2.0/UDP
192.168.0.191:63610;branch=z9hG4bK-d8754z-fb28723daa3f772d-1---d8754z-;rport. Max-Forwards: 70.
Contact:sip:support1@192.168.0.191:63610;rinstance=782b19a2fccc665f;transport=udp. To: "Test Ast"sip:support1@register.domain.com. From: "Test Ast"sip:support1@register.domain.com;tag=ba705453. Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI.. CSeq: 1 REGISTER. Expires: 3600. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. User-Agent: eyeBeam release 1102q stamp 51814. Content-Length: 0. .
U +0.004782 xx.xx.xx.51:5060 -> yy.yy.yy.146:63610 SIP/2.0 401 Unauthorized. Via: SIP/2.0/UDP
192.168.0.191:63610;branch=z9hG4bK-d8754z-fb28723daa3f772d-1---d8754z-;rport=63610;received=yy.yy.yy.146. To: "Test
Ast"sip:support1@register.domain.com;tag=e597ca73bdb255490f0cefa03b2fda82.6b98. From: "Test Ast"sip:support1@register.domain.com;tag=ba705453. Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI.. CSeq: 1 REGISTER. WWW-Authenticate: Digest realm="domain.com", nonce="TwMpsU8DKIX4lvWDwPsV4iUhCl+iOAdk". Server: kamailio (3.2.1 (i386/linux)). Content-Length: 0. .
U +0.400706 yy.yy.yy.146:63610 -> xx.xx.xx.51:5060 REGISTER sip:register.domain.com SIP/2.0. Via: SIP/2.0/UDP
192.168.0.191:63610;branch=z9hG4bK-d8754z-81517d296225234f-1---d8754z-;rport. Max-Forwards: 70.
Contact:sip:support1@192.168.0.191:63610;rinstance=782b19a2fccc665f;transport=udp. To: "Test Ast"sip:support1@register.domain.com. From: "Test Ast"sip:support1@register.domain.com;tag=ba705453. Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI.. CSeq: 2 REGISTER. Expires: 3600. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. User-Agent: eyeBeam release 1102q stamp 51814. Authorization: Digest
username="support1",realm="domain.com",nonce="TwMpsU8DKIX4lvWDwPsV4iUhCl+iOAdk",uri="sip:register.domain.com",response="4bfd80b0b836c20b748ee19a1c886284",algorithm=MD5. Content-Length: 0. .
U +0.005302 xx.xx.xx.51:5060 -> yy.yy.yy.146:63610 SIP/2.0 401 Unauthorized. Via: SIP/2.0/UDP
192.168.0.191:63610;branch=z9hG4bK-d8754z-81517d296225234f-1---d8754z-;rport=63610;received=yy.yy.yy.146. To: "Test
Ast"sip:support1@register.domain.com;tag=e597ca73bdb255490f0cefa03b2fda82.2f76. From: "Test Ast"sip:support1@register.domain.com;tag=ba705453. Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI.. CSeq: 2 REGISTER. WWW-Authenticate: Digest realm="domain.com", nonce="TwMpsU8DKIX4lvWDwPsV4iUhCl+iOAdk". Server: kamailio (3.2.1 (i386/linux)). Content-Length: 0. .
On Tue, Jan 3, 2012 at 6:08 PM, Daniel-Constantin Mierla miconda@gmail.com wrote: > > Hello, > > I need the entire flow for registration, including the 401 reply and > the > following REGISTER request. > > Cheers, > Daniel > > > On 1/3/12 5:02 PM, Ali Jawad wrote: >> >> Hi >> Please see the ngrep below, please note that if I use in the db >> register.domain.com and generate a hash against it for HA1 it >> works,but then the user cant logon to register2.domain.com >> >> >> U +10.630576 xx.yy.yy.yy:20020 -> xx.xx.xx.xx:5060 >> REGISTER sip:register.domain SIP/2.0. >> Via: SIP/2.0/UDP >> >> >> >> 192.168.0.191:20020;branch=z9hG4bK-d8754z-af65a442980c375f-1---d8754z-;rport. >> Max-Forwards: 70. >> >> >> >> Contact:sip:support1@192.168.0.191:20020;rinstance=4009190a4e109ac6;transport=udp. >> To: "Test Ast"sip:support1@register.domain. >> From: "Test Ast"sip:support1@register.domain;tag=976bb004. >> Call-ID: MDFmZDU2ZTI2YjJjMGNlMGFmOTIzMWFmZGQ1ZTNjMDE.. >> CSeq: 1 REGISTER. >> Expires: 3600. >> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, >> SUBSCRIBE, INFO. >> User-Agent: eyeBeam release 1102q stamp 51814. >> Content-Length: 0. >> >> On Tue, Jan 3, 2012 at 5:58 PM, Daniel-Constantin Mierla >> miconda@gmail.com wrote: >>> >>> Hello, >>> >>> >>> On 1/3/12 4:48 PM, Ali Jawad wrote: >>>> >>>> Hi Daniel >>>> >>>> Please see >>>> >>>> 5(18649) DEBUG:<core> [db_res.c:184]: allocate 8 bytes for >>>> rows >>>> at >>>> 0xb7b78d74 >>>> 5(18649) DEBUG:<core> [db_row.c:119]: allocate 20 bytes for >>>> row >>>> values at 0xb7b78dac >>>> 5(18649) DEBUG:<core> [db_val.c:117]: converting STRING >>>> [6f966cd9c628f14cdc20172f96a4d065] >>>> 5(18649) DEBUG: auth [api.c:210]: check_response: Our result = >>>> '6f95e6235edca0b7765042ef119fd83b' >>>> 5(18649) DEBUG: auth [api.c:220]: check_response: Authorization >>>> failed >>>> 5(18649) DEBUG:<core> [db_res.c:81]: freeing 1 columns >>>> 5(18649) DEBUG:<core> [db_res.c:85]: freeing RES_NAMES[0] at >>>> 0xb7b78d3c >>>> 5(18649) DEBUG:<core> [db_res.c:94]: freeing result names at >>>> 0xb7b78bfc >>>> 5(18649) DEBUG:<core> [db_res.c:99]: freeing result types at >>>> 0xb7b78c64 >>>> 5(18649) DEBUG:<core> [db_res.c:54]: freeing 1 rows >>>> 5(18649) DEBUG:<core> [db_row.c:97]: freeing row values at >>>> 0xb7b78dac >>>> 5(18649) DEBUG:<core> [db_res.c:62]: freeing rows at >>>> 0xb7b78d74 >>>> 5(18649) DEBUG:<core> [db_res.c:136]: freeing result set at >>>> 0xb7b78bb0 >>>> 5(18649) DEBUG: auth [challenge.c:102]: build_challenge_hf: >>>> realm='nymgo.com' >>>> 5(18649) DEBUG: auth [challenge.c:244]: auth: 'WWW-Authenticate: >>>> Digest realm="domain.com", nonce="TwMcuk8DG47SLxatlNdZfyfR8p3OiyAE" >>>> ' >>>> >>>> I rebuilt the hashes against domain.com and then tried to connect to >>>> sip1.domain.com and sip2.domain.com and sip3.domain.com with all of >>>> the having >>>> >>>> >>>> # ----- auth_db params ----- >>>> #!ifdef WITH_AUTH >>>> modparam("auth_db", "db_url", DBURL) >>>> modparam("auth_db", "calculate_ha1", 0 ) >>>> modparam("auth_db", "password_column", "ha1") >>>> modparam("auth_db", "load_credentials", "") >>>> modparam("auth_db", "use_domain", MULTIDOMAIN) >>>> >>>> And in the routing process : >>>> >>>> if (!www_authorize("domain.com", "subscriber")) >>>> { >>>> >>>> www_challenge("domain.com", "0"); >>>> exit; >>>> } >>>> >>>> >>>> +++++++++++++ >>>> >>>> My point is that the hashes are caculated from user:doman:pwd which >>>> are extracted from the SIP packet and in this case the domains are >>>> sip1,sip2,sip3 while the hashes stored in the database are generated >>>> against domain.com >>>> >>>> If " ha1 is actually hash over 'user:realm:pwd' " shouldn't I have >>>> to >>>> set the domain/realm in the config file ? >>> >>> >>> the first parameter in www_authorize and www_challenge functions is >>> the >>> realm and it is used to build the digest response. >>> >>> Is your phone putting user@domain in authorization header? Can you >>> paste >>> here the ngrep of registration? >>> >>> Cheers, >>> Daniel >>> >>> >>>> I might be wrong....thanks for the help so far. >>>> >>>> Regards >>>> >>>> On Tue, Jan 3, 2012 at 5:15 PM, Daniel-Constantin Mierla >>>> miconda@gmail.com wrote: >>>>> >>>>> Hello, >>>>> >>>>> >>>>> On 1/3/12 4:12 PM, Ali Jawad wrote: >>>>>> >>>>>> Hi Daniel >>>>>> This certainly makes sense, I will try it in a few mins, but what >>>>>> I >>>>>> observed at Debug Level 3 is that Hash is calculated before >>>>>> www_authenticate is executed and it shows HA comparison failed, if >>>>>> I >>>>>> do use domain.com instead of $fd and use $domain.com in db domain >>>>>> field and build HA1 filed based on that, wont Kamailio still try >>>>>> to >>>>>> build the HA1 hash which it will compare form user:domain:pwd >>>>>> where >>>>>> domain is fed in to the hash function from the header of the SIP >>>>>> packet ? >>>>> >>>>> >>>>> the ha1 is actually hash over 'user:realm:pwd' -- it is just common >>>>> practice >>>>> to use the domain as realm, since realm should be a unique token to >>>>> identify >>>>> the service, but it can be any random string. realm is given as >>>>> parameter >>>>> to auth functions in kamailio.cfg >>>>> >>>>> Cheers, >>>>> Daniel >>>>> >>>>> >>>>>> Regards >>>>>> >>>>>> On Tue, Jan 3, 2012 at 5:07 PM, Daniel-Constantin Mierla >>>>>> miconda@gmail.com wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> you can simply use 'domain.com' as realm parameter to >>>>>>> authentication >>>>>>> function instead of $fd. Also build ha1 and ha1b with domain.com >>>>>>> and >>>>>>> then >>>>>>> you are safe no matter which sip server is used. >>>>>>> >>>>>>> Of course you can build the realm by striping first token before >>>>>>> '.' >>>>>>> in >>>>>>> $fd >>>>>>> and pass it to authentication functions, but not sure if makes >>>>>>> sense >>>>>>> since >>>>>>> it should be always domain.com >>>>>>> >>>>>>> Cheers, >>>>>>> Daniel >>>>>>> >>>>>>> >>>>>>> On 1/3/12 3:15 PM, Ali Jawad wrote: >>>>>>>> >>>>>>>> Hi >>>>>>>> After some research it seems to me that the only way to achieve >>>>>>>> this >>>>>>>> is to "try" and change how hashing is done in the source code, a >>>>>>>> little bit too ambitious for me, and it means I will have loads >>>>>>>> of >>>>>>>> problems each time an upgrade is released. >>>>>>>> >>>>>>>> Or >>>>>>>> >>>>>>>> Use pseudovariables to fix the value of the $fd value to >>>>>>>> something >>>>>>>> constant, while this worked for values like $var(y) I was not >>>>>>>> able >>>>>>>> to >>>>>>>> assign/strip $fd to remove the subdomain part. >>>>>>>> >>>>>>>> Any input please ? >>>>>>>> >>>>>>>> Regards >>>>>>>> >>>>>>>> On Tue, Jan 3, 2012 at 2:06 PM, Ali >>>>>>>> Jawadali.jawad@splendor.net >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi >>>>>>>>> I do have 3 Kamailio servers, one for mobile phone >>>>>>>>> registrations, >>>>>>>>> one >>>>>>>>> for softphone registrations and one for SIP device >>>>>>>>> registrations. >>>>>>>>> Each >>>>>>>>> of those devices connects to it's perspective kamailio server >>>>>>>>> >>>>>>>>> sip1.domain.com >>>>>>>>> sip2.domain.com >>>>>>>>> sip3.domain.com >>>>>>>>> >>>>>>>>> All 3 Kamailio servers share the same database, and users can >>>>>>>>> use >>>>>>>>> their kamailio user/pwd on any of the devices, now I want to >>>>>>>>> use >>>>>>>>> encrypted passwords and remove clear text passwords from the >>>>>>>>> database. >>>>>>>>> I did test with one server and all is fine,however if a user >>>>>>>>> want >>>>>>>>> to >>>>>>>>> register from the second kamailio server it does not work, >>>>>>>>> basically >>>>>>>>> because the db domain entry from which the hash is created is >>>>>>>>> sip1.domain.com and stored in the db, while the user connects >>>>>>>>> from >>>>>>>>> to >>>>>>>>> sip2.domain.com this eventually generates a different hash. >>>>>>>>> >>>>>>>>> Is there anyway to overcome this ? Can I exclude Domain from >>>>>>>>> Hash >>>>>>>>> generation ? Any other option that allows me to do the above ? >>>>>>>>> >>>>>>>>> Thanks >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> -- >>>>>>> Daniel-Constantin Mierla -- http://www.asipto.com >>>>>>> http://linkedin.com/in/miconda -- http://twitter.com/miconda >>>>>>> >>>>>> -- >>>>>> Daniel-Constantin Mierla -- http://www.asipto.com >>>>>> http://linkedin.com/in/miconda -- http://twitter.com/miconda >>>> >>>> >>>> >>> -- >>> Daniel-Constantin Mierla -- http://www.asipto.com >>> http://linkedin.com/in/miconda -- http://twitter.com/miconda >>> > -- > Daniel-Constantin Mierla -- http://www.asipto.com > http://linkedin.com/in/miconda -- http://twitter.com/miconda >
-- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda
-- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda
-- Ali Jawad Information Systems Manager Splendor Telecom (www.splendor.net) Beirut, Lebanon Phone: +9611373725/ext 116 FAX: +9611375554
-- Ali Jawad Information Systems Manager Splendor Telecom (www.splendor.net) Beirut, Lebanon Phone: +9611373725/ext 116 FAX: +9611375554
Hello,
can you get the backtrace? Locate the core file (perhaps in / directory if you don't use -w command line parameter) and do:
gdb /path/to/kamailio /path/to/corefile bt
Cheers, Daniel
On 1/4/12 9:17 AM, Ali Jawad wrote:
Hi When I did set modparam("auth_db", "calculate_ha1", 0 )
Kamailio is crashing see
Regards
On Tue, Jan 3, 2012 at 11:54 PM, Ali Jawadali.jawad@splendor.net wrote:
Hi It fetches one value from the database to compare it against a second value that has to be computed right, in the computation of the second hash where is the domain part fetched from ? Regards
On Wed, Jan 4, 2012 at 12:26 AM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
On 1/3/12 10:08 PM, Ali Jawad wrote:
Hi
In Xlite/eyebeam I put in the username and one of my 3 kamailio servers respectively as the sip registrar, I.e. register1.domain.com, register2.domain.com and register3.domain.com, that is why I was saying that hashing will create different hashes based on the register domain. With reference to my first related post, one kamailio server is for softphones, one for sip devices and one for mobile phones with SIP software. Each server has a slightly different NAT and Call routing structure.
but your service domain is 'domain.com', specific server addresses (domains) per UA type should be set as outbound proxy on the UA devices.
This is why I wanted to eliminate the domain factor from the hashing procedure, I am sure it chooses the right value from the DB value because it is the same value shown in the log of kamailio against which a comparison is being done and because it works if I put register.domain.com in the domain column rehash the HA! value of the db.
When auth_db module is configured to take the hashed value from database (calculate_ha1 parameter is 0), there is no more computation of it in kamailio -- it is just fetched from database and used -- so it does not matter anymore the domains in the sip message.
Check to see if the xlite does not have a realm field that has to be set properly.
>>> values at 0xb7b78dac >>>> 5(18649) DEBUG:<core> [db_val.c:117]: converting STRING >>>> [6f966cd9c628f14cdc20172f96a4d065]<====##### This is the value in >>>> the DB based on domain.com >>>> 5(18649) DEBUG: auth [api.c:210]: check_response: Our result = >>>> '6f95e6235edca0b7765042ef119fd83b'<====##### This value appears to >>>> be the value generated register.domain.com >>>> 5(18649) DEBUG: auth [api.c:220]: check_response: Authorization
How can I enable the SQL query log ?
I don't know by hart, googling should help you.
Cheers, Daniel
On Tue, Jan 3, 2012 at 8:12 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
why are you using register.domain.com as domain for registration? Isn't domain.com the right one?
Can you enable the sql query log for mysql server and double check if the right value (column) is selected from the database table?
Cheers, Daniel
On 1/3/12 5:13 PM, Ali Jawad wrote:
Hi Please see the below, thanks !
interface: eth1 (xx.xx.xx.0/255.255.255.0) match: support1
U +6.698682 yy.yy.yy.146:18832 -> xx.xx.xx.51:5060 REGISTER sip:register.domain.com SIP/2.0. Via: SIP/2.0/UDP
192.168.0.191:18832;branch=z9hG4bK-d8754z-05164a466600837d-1---d8754z-;rport. Max-Forwards: 70.
Contact:sip:support1@192.168.0.191:18832;rinstance=f8e37e314657e0d7;transport=udp. To: "Test Ast"sip:support1@register.domain.com. From: "Test Ast"sip:support1@register.domain.com;tag=f710b930. Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY.. CSeq: 1 REGISTER. Expires: 3600. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. User-Agent: eyeBeam release 1102q stamp 51814. Content-Length: 0. .
U +0.005245 xx.xx.xx.51:5060 -> yy.yy.yy.146:18832 SIP/2.0 401 Unauthorized. Via: SIP/2.0/UDP
192.168.0.191:18832;branch=z9hG4bK-d8754z-05164a466600837d-1---d8754z-;rport=18832;received=yy.yy.yy.146. To: "Test
Ast"sip:support1@register.domain.com;tag=e597ca73bdb255490f0cefa03b2fda82.3053. From: "Test Ast"sip:support1@register.domain.com;tag=f710b930. Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY.. CSeq: 1 REGISTER. WWW-Authenticate: Digest realm="domain.com", nonce="TwMpUE8DKCSt/IP7jcNRMbCT4TnbqlHl". Server: kamailio (3.2.1 (i386/linux)). Content-Length: 0. .
U +0.428042 yy.yy.yy.146:18832 -> xx.xx.xx.51:5060 REGISTER sip:register.domain.com SIP/2.0. Via: SIP/2.0/UDP
192.168.0.191:18832;branch=z9hG4bK-d8754z-fc633b21627dca6d-1---d8754z-;rport. Max-Forwards: 70.
Contact:sip:support1@192.168.0.191:18832;rinstance=f8e37e314657e0d7;transport=udp. To: "Test Ast"sip:support1@register.domain.com. From: "Test Ast"sip:support1@register.domain.com;tag=f710b930. Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY.. CSeq: 2 REGISTER. Expires: 3600. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. User-Agent: eyeBeam release 1102q stamp 51814. Authorization: Digest
username="support1",realm="domain.com",nonce="TwMpUE8DKCSt/IP7jcNRMbCT4TnbqlHl",uri="sip:register.domain.com",response="6122245b77e2df0b90179304464341e7",algorithm=MD5. Content-Length: 0. .
U +0.005146 xx.xx.xx.51:5060 -> yy.yy.yy.146:18832 SIP/2.0 401 Unauthorized. Via: SIP/2.0/UDP
192.168.0.191:18832;branch=z9hG4bK-d8754z-fc633b21627dca6d-1---d8754z-;rport=18832;received=yy.yy.yy.146. To: "Test
Ast"sip:support1@register.domain.com;tag=e597ca73bdb255490f0cefa03b2fda82.fce3. From: "Test Ast"sip:support1@register.domain.com;tag=f710b930. Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY.. CSeq: 2 REGISTER. WWW-Authenticate: Digest realm="domain.com", nonce="TwMpUE8DKCSt/IP7jcNRMbCT4TnbqlHl". Server: kamailio (3.2.1 (i386/linux)). Content-Length: 0. .
[root@kam-rtp-100-51 mysql]# mail alijawad1@gmail.com< output.txt [root@kam-rtp-100-51 mysql]# ngrep -W byline -T support1 -q -d eth1 interface: eth1 (xx.xx.xx.0/255.255.255.0) match: support1
U +5.321505 yy.yy.yy.146:63610 -> xx.xx.xx.51:5060 REGISTER sip:register.domain.com SIP/2.0. Via: SIP/2.0/UDP
192.168.0.191:63610;branch=z9hG4bK-d8754z-fb28723daa3f772d-1---d8754z-;rport. Max-Forwards: 70.
Contact:sip:support1@192.168.0.191:63610;rinstance=782b19a2fccc665f;transport=udp. To: "Test Ast"sip:support1@register.domain.com. From: "Test Ast"sip:support1@register.domain.com;tag=ba705453. Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI.. CSeq: 1 REGISTER. Expires: 3600. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. User-Agent: eyeBeam release 1102q stamp 51814. Content-Length: 0. .
U +0.004782 xx.xx.xx.51:5060 -> yy.yy.yy.146:63610 SIP/2.0 401 Unauthorized. Via: SIP/2.0/UDP
192.168.0.191:63610;branch=z9hG4bK-d8754z-fb28723daa3f772d-1---d8754z-;rport=63610;received=yy.yy.yy.146. To: "Test
Ast"sip:support1@register.domain.com;tag=e597ca73bdb255490f0cefa03b2fda82.6b98. From: "Test Ast"sip:support1@register.domain.com;tag=ba705453. Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI.. CSeq: 1 REGISTER. WWW-Authenticate: Digest realm="domain.com", nonce="TwMpsU8DKIX4lvWDwPsV4iUhCl+iOAdk". Server: kamailio (3.2.1 (i386/linux)). Content-Length: 0. .
U +0.400706 yy.yy.yy.146:63610 -> xx.xx.xx.51:5060 REGISTER sip:register.domain.com SIP/2.0. Via: SIP/2.0/UDP
192.168.0.191:63610;branch=z9hG4bK-d8754z-81517d296225234f-1---d8754z-;rport. Max-Forwards: 70.
Contact:sip:support1@192.168.0.191:63610;rinstance=782b19a2fccc665f;transport=udp. To: "Test Ast"sip:support1@register.domain.com. From: "Test Ast"sip:support1@register.domain.com;tag=ba705453. Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI.. CSeq: 2 REGISTER. Expires: 3600. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. User-Agent: eyeBeam release 1102q stamp 51814. Authorization: Digest
username="support1",realm="domain.com",nonce="TwMpsU8DKIX4lvWDwPsV4iUhCl+iOAdk",uri="sip:register.domain.com",response="4bfd80b0b836c20b748ee19a1c886284",algorithm=MD5. Content-Length: 0. .
U +0.005302 xx.xx.xx.51:5060 -> yy.yy.yy.146:63610 SIP/2.0 401 Unauthorized. Via: SIP/2.0/UDP
192.168.0.191:63610;branch=z9hG4bK-d8754z-81517d296225234f-1---d8754z-;rport=63610;received=yy.yy.yy.146. To: "Test
Ast"sip:support1@register.domain.com;tag=e597ca73bdb255490f0cefa03b2fda82.2f76. From: "Test Ast"sip:support1@register.domain.com;tag=ba705453. Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI.. CSeq: 2 REGISTER. WWW-Authenticate: Digest realm="domain.com", nonce="TwMpsU8DKIX4lvWDwPsV4iUhCl+iOAdk". Server: kamailio (3.2.1 (i386/linux)). Content-Length: 0. .
On Tue, Jan 3, 2012 at 6:08 PM, Daniel-Constantin Mierla miconda@gmail.com wrote: > Hello, > > I need the entire flow for registration, including the 401 reply and > the > following REGISTER request. > > Cheers, > Daniel > > > On 1/3/12 5:02 PM, Ali Jawad wrote: >> Hi >> Please see the ngrep below, please note that if I use in the db >> register.domain.com and generate a hash against it for HA1 it >> works,but then the user cant logon to register2.domain.com >> >> >> U +10.630576 xx.yy.yy.yy:20020 -> xx.xx.xx.xx:5060 >> REGISTER sip:register.domain SIP/2.0. >> Via: SIP/2.0/UDP >> >> >> >> 192.168.0.191:20020;branch=z9hG4bK-d8754z-af65a442980c375f-1---d8754z-;rport. >> Max-Forwards: 70. >> >> >> >> Contact:sip:support1@192.168.0.191:20020;rinstance=4009190a4e109ac6;transport=udp. >> To: "Test Ast"sip:support1@register.domain. >> From: "Test Ast"sip:support1@register.domain;tag=976bb004. >> Call-ID: MDFmZDU2ZTI2YjJjMGNlMGFmOTIzMWFmZGQ1ZTNjMDE.. >> CSeq: 1 REGISTER. >> Expires: 3600. >> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, >> SUBSCRIBE, INFO. >> User-Agent: eyeBeam release 1102q stamp 51814. >> Content-Length: 0. >> >> On Tue, Jan 3, 2012 at 5:58 PM, Daniel-Constantin Mierla >> miconda@gmail.com wrote: >>> Hello, >>> >>> >>> On 1/3/12 4:48 PM, Ali Jawad wrote: >>>> Hi Daniel >>>> >>>> Please see >>>> >>>> 5(18649) DEBUG:<core> [db_res.c:184]: allocate 8 bytes for >>>> rows >>>> at >>>> 0xb7b78d74 >>>> 5(18649) DEBUG:<core> [db_row.c:119]: allocate 20 bytes for >>>> row >>>> values at 0xb7b78dac >>>> 5(18649) DEBUG:<core> [db_val.c:117]: converting STRING >>>> [6f966cd9c628f14cdc20172f96a4d065] >>>> 5(18649) DEBUG: auth [api.c:210]: check_response: Our result = >>>> '6f95e6235edca0b7765042ef119fd83b' >>>> 5(18649) DEBUG: auth [api.c:220]: check_response: Authorization >>>> failed >>>> 5(18649) DEBUG:<core> [db_res.c:81]: freeing 1 columns >>>> 5(18649) DEBUG:<core> [db_res.c:85]: freeing RES_NAMES[0] at >>>> 0xb7b78d3c >>>> 5(18649) DEBUG:<core> [db_res.c:94]: freeing result names at >>>> 0xb7b78bfc >>>> 5(18649) DEBUG:<core> [db_res.c:99]: freeing result types at >>>> 0xb7b78c64 >>>> 5(18649) DEBUG:<core> [db_res.c:54]: freeing 1 rows >>>> 5(18649) DEBUG:<core> [db_row.c:97]: freeing row values at >>>> 0xb7b78dac >>>> 5(18649) DEBUG:<core> [db_res.c:62]: freeing rows at >>>> 0xb7b78d74 >>>> 5(18649) DEBUG:<core> [db_res.c:136]: freeing result set at >>>> 0xb7b78bb0 >>>> 5(18649) DEBUG: auth [challenge.c:102]: build_challenge_hf: >>>> realm='nymgo.com' >>>> 5(18649) DEBUG: auth [challenge.c:244]: auth: 'WWW-Authenticate: >>>> Digest realm="domain.com", nonce="TwMcuk8DG47SLxatlNdZfyfR8p3OiyAE" >>>> ' >>>> >>>> I rebuilt the hashes against domain.com and then tried to connect to >>>> sip1.domain.com and sip2.domain.com and sip3.domain.com with all of >>>> the having >>>> >>>> >>>> # ----- auth_db params ----- >>>> #!ifdef WITH_AUTH >>>> modparam("auth_db", "db_url", DBURL) >>>> modparam("auth_db", "calculate_ha1", 0 ) >>>> modparam("auth_db", "password_column", "ha1") >>>> modparam("auth_db", "load_credentials", "") >>>> modparam("auth_db", "use_domain", MULTIDOMAIN) >>>> >>>> And in the routing process : >>>> >>>> if (!www_authorize("domain.com", "subscriber")) >>>> { >>>> >>>> www_challenge("domain.com", "0"); >>>> exit; >>>> } >>>> >>>> >>>> +++++++++++++ >>>> >>>> My point is that the hashes are caculated from user:doman:pwd which >>>> are extracted from the SIP packet and in this case the domains are >>>> sip1,sip2,sip3 while the hashes stored in the database are generated >>>> against domain.com >>>> >>>> If " ha1 is actually hash over 'user:realm:pwd' " shouldn't I have >>>> to >>>> set the domain/realm in the config file ? >>> >>> the first parameter in www_authorize and www_challenge functions is >>> the >>> realm and it is used to build the digest response. >>> >>> Is your phone putting user@domain in authorization header? Can you >>> paste >>> here the ngrep of registration? >>> >>> Cheers, >>> Daniel >>> >>> >>>> I might be wrong....thanks for the help so far. >>>> >>>> Regards >>>> >>>> On Tue, Jan 3, 2012 at 5:15 PM, Daniel-Constantin Mierla >>>> miconda@gmail.com wrote: >>>>> Hello, >>>>> >>>>> >>>>> On 1/3/12 4:12 PM, Ali Jawad wrote: >>>>>> Hi Daniel >>>>>> This certainly makes sense, I will try it in a few mins, but what >>>>>> I >>>>>> observed at Debug Level 3 is that Hash is calculated before >>>>>> www_authenticate is executed and it shows HA comparison failed, if >>>>>> I >>>>>> do use domain.com instead of $fd and use $domain.com in db domain >>>>>> field and build HA1 filed based on that, wont Kamailio still try >>>>>> to >>>>>> build the HA1 hash which it will compare form user:domain:pwd >>>>>> where >>>>>> domain is fed in to the hash function from the header of the SIP >>>>>> packet ? >>>>> >>>>> the ha1 is actually hash over 'user:realm:pwd' -- it is just common >>>>> practice >>>>> to use the domain as realm, since realm should be a unique token to >>>>> identify >>>>> the service, but it can be any random string. realm is given as >>>>> parameter >>>>> to auth functions in kamailio.cfg >>>>> >>>>> Cheers, >>>>> Daniel >>>>> >>>>> >>>>>> Regards >>>>>> >>>>>> On Tue, Jan 3, 2012 at 5:07 PM, Daniel-Constantin Mierla >>>>>> miconda@gmail.com wrote: >>>>>>> Hello, >>>>>>> >>>>>>> you can simply use 'domain.com' as realm parameter to >>>>>>> authentication >>>>>>> function instead of $fd. Also build ha1 and ha1b with domain.com >>>>>>> and >>>>>>> then >>>>>>> you are safe no matter which sip server is used. >>>>>>> >>>>>>> Of course you can build the realm by striping first token before >>>>>>> '.' >>>>>>> in >>>>>>> $fd >>>>>>> and pass it to authentication functions, but not sure if makes >>>>>>> sense >>>>>>> since >>>>>>> it should be always domain.com >>>>>>> >>>>>>> Cheers, >>>>>>> Daniel >>>>>>> >>>>>>> >>>>>>> On 1/3/12 3:15 PM, Ali Jawad wrote: >>>>>>>> Hi >>>>>>>> After some research it seems to me that the only way to achieve >>>>>>>> this >>>>>>>> is to "try" and change how hashing is done in the source code, a >>>>>>>> little bit too ambitious for me, and it means I will have loads >>>>>>>> of >>>>>>>> problems each time an upgrade is released. >>>>>>>> >>>>>>>> Or >>>>>>>> >>>>>>>> Use pseudovariables to fix the value of the $fd value to >>>>>>>> something >>>>>>>> constant, while this worked for values like $var(y) I was not >>>>>>>> able >>>>>>>> to >>>>>>>> assign/strip $fd to remove the subdomain part. >>>>>>>> >>>>>>>> Any input please ? >>>>>>>> >>>>>>>> Regards >>>>>>>> >>>>>>>> On Tue, Jan 3, 2012 at 2:06 PM, Ali >>>>>>>> Jawadali.jawad@splendor.net >>>>>>>> wrote: >>>>>>>>> Hi >>>>>>>>> I do have 3 Kamailio servers, one for mobile phone >>>>>>>>> registrations, >>>>>>>>> one >>>>>>>>> for softphone registrations and one for SIP device >>>>>>>>> registrations. >>>>>>>>> Each >>>>>>>>> of those devices connects to it's perspective kamailio server >>>>>>>>> >>>>>>>>> sip1.domain.com >>>>>>>>> sip2.domain.com >>>>>>>>> sip3.domain.com >>>>>>>>> >>>>>>>>> All 3 Kamailio servers share the same database, and users can >>>>>>>>> use >>>>>>>>> their kamailio user/pwd on any of the devices, now I want to >>>>>>>>> use >>>>>>>>> encrypted passwords and remove clear text passwords from the >>>>>>>>> database. >>>>>>>>> I did test with one server and all is fine,however if a user >>>>>>>>> want >>>>>>>>> to >>>>>>>>> register from the second kamailio server it does not work, >>>>>>>>> basically >>>>>>>>> because the db domain entry from which the hash is created is >>>>>>>>> sip1.domain.com and stored in the db, while the user connects >>>>>>>>> from >>>>>>>>> to >>>>>>>>> sip2.domain.com this eventually generates a different hash. >>>>>>>>> >>>>>>>>> Is there anyway to overcome this ? Can I exclude Domain from >>>>>>>>> Hash >>>>>>>>> generation ? Any other option that allows me to do the above ? >>>>>>>>> >>>>>>>>> Thanks >>>>>>>> >>>>>>>> >>>>>>> -- >>>>>>> Daniel-Constantin Mierla -- http://www.asipto.com >>>>>>> http://linkedin.com/in/miconda -- http://twitter.com/miconda >>>>>>> >>>>>> -- >>>>>> Daniel-Constantin Mierla -- http://www.asipto.com >>>>>> http://linkedin.com/in/miconda -- http://twitter.com/miconda >>>> >>>> >>> -- >>> Daniel-Constantin Mierla -- http://www.asipto.com >>> http://linkedin.com/in/miconda -- http://twitter.com/miconda >>> > -- > Daniel-Constantin Mierla -- http://www.asipto.com > http://linkedin.com/in/miconda -- http://twitter.com/miconda >
-- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda
-- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda
-- Ali Jawad Information Systems Manager Splendor Telecom (www.splendor.net) Beirut, Lebanon Phone: +9611373725/ext 116 FAX: +9611375554
Hi Daniel Back-trace below, regards.
[root@kam-rtp-100-51 kamailio]# gdb /usr/local/kamailio/sbin/kamailio /core.18024GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-37.el5)Copyright (C) 2009 Free Software Foundation, Inc.License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.htmlThis is free software: you are free to change and redistribute it.There is NO WARRANTY, to the extent permitted by law. Type "show copying"and "show warranty" for details.This GDB was configured as "i386-redhat-linux-gnu".For bug reporting instructions, please see:http://www.gnu.org/software/gdb/bugs/...Reading symbols from /usr/local/kamailio/sbin/kamailio...done.[New Thread 18024]Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done.Loaded symbols for /lib/libdl.so.2Reading symbols from /lib/libresolv.so.2...(no debugging symbols found)...done.Loaded symbols for /lib/libresolv.so.2Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.Loaded symbols for /lib/libc.so.6Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.Loaded symbols for /lib/ld-linux.so.2Reading symbols from /usr/local/kamailio/lib/kamailio/modules/db_mysql.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules/db_mysql.soReading symbols from /usr/lib/mysql/libmysqlclient.so.15...(no debugging symbols found)...done.Loaded symbols for /usr/lib/mysql/libmysqlclient.so.15Reading symbols from /lib/libz.so.1...(no debugging symbols found)...done.Loaded symbols for /lib/libz.so.1Reading symbols from /lib/libcrypt.so.1...(no debugging symbols found)...done.Loaded symbols for /lib/libcrypt.so.1Reading symbols from /lib/libnsl.so.1...(no debugging symbols found)...done.Loaded symbols for /lib/libnsl.so.1Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done.Loaded symbols for /lib/libm.so.6Reading symbols from /lib/libssl.so.6...(no debugging symbols found)...done.Loaded symbols for /lib/libssl.so.6Reading symbols from /lib/libcrypto.so.6...(no debugging symbols found)...done.Loaded symbols for /lib/libcrypto.so.6Reading symbols from /usr/local/kamailio/lib/kamailio/libsrdb2.so.1...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/libsrdb2.so.1Reading symbols from /usr/local/kamailio/lib/kamailio/libsrdb1.so.1...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/libsrdb1.so.1Reading symbols from /usr/lib/libgssapi_krb5.so.2...(no debugging symbols found)...done.Loaded symbols for /usr/lib/libgssapi_krb5.so.2Reading symbols from /usr/lib/libkrb5.so.3...(no debugging symbols found)...done.Loaded symbols for /usr/lib/libkrb5.so.3Reading symbols from /lib/libcom_err.so.2...(no debugging symbols found)...done.Loaded symbols for /lib/libcom_err.so.2Reading symbols from /usr/lib/libk5crypto.so.3...(no debugging symbols found)...done.Loaded symbols for /usr/lib/libk5crypto.so.3Reading symbols from /usr/lib/libkrb5support.so.0...(no debugging symbols found)...done.Loaded symbols for /usr/lib/libkrb5support.so.0Reading symbols from /lib/libkeyutils.so.1...(no debugging symbols found)...done.Loaded symbols for /lib/libkeyutils.so.1Reading symbols from /lib/libselinux.so.1...(no debugging symbols found)...done.Loaded symbols for /lib/libselinux.so.1Reading symbols from /lib/libsepol.so.1...(no debugging symbols found)...done.Loaded symbols for /lib/libsepol.so.1Reading symbols from /usr/local/kamailio/lib/kamailio/modules_k/exec.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules_k/exec.soReading symbols from /usr/local/kamailio/lib/kamailio/modules_k/group.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules_k/group.soReading symbols from /usr/local/kamailio/lib/kamailio/libkcore.so.1...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/libkcore.so.1Reading symbols from /usr/local/kamailio/lib/kamailio/modules_k/speeddial.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules_k/speeddial.soReading symbols from /usr/local/kamailio/lib/kamailio/modules/carrierroute.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules/carrierroute.soReading symbols from /usr/lib/libconfuse.so.0...(no debugging symbols found)...done.Loaded symbols for /usr/lib/libconfuse.so.0Reading symbols from /usr/local/kamailio/lib/kamailio/libtrie.so.1...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/libtrie.so.1Reading symbols from /usr/local/kamailio/lib/kamailio/libkmi.so.1...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/libkmi.so.1Reading symbols from /usr/local/kamailio/lib/kamailio/modules_k/mi_fifo.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules_k/mi_fifo.soReading symbols from /usr/local/kamailio/lib/kamailio/modules_k/kex.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules_k/kex.soReading symbols from /usr/local/kamailio/lib/kamailio/modules/tm.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules/tm.soReading symbols from /usr/local/kamailio/lib/kamailio/modules_k/tmx.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules_k/tmx.soReading symbols from /usr/local/kamailio/lib/kamailio/modules/sl.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules/sl.soReading symbols from /usr/local/kamailio/lib/kamailio/modules_k/rr.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules_k/rr.soReading symbols from /usr/local/kamailio/lib/kamailio/modules_k/pv.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules_k/pv.soReading symbols from /usr/local/kamailio/lib/kamailio/modules_k/maxfwd.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules_k/maxfwd.soReading symbols from /usr/local/kamailio/lib/kamailio/modules_k/usrloc.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules_k/usrloc.soReading symbols from /usr/local/kamailio/lib/kamailio/modules_k/registrar.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules_k/registrar.soReading symbols from /usr/local/kamailio/lib/kamailio/modules_k/textops.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules_k/textops.soReading symbols from /usr/local/kamailio/lib/kamailio/modules_k/siputils.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules_k/siputils.soReading symbols from /usr/local/kamailio/lib/kamailio/modules_k/xlog.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules_k/xlog.soReading symbols from /usr/local/kamailio/lib/kamailio/modules/sanity.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules/sanity.soReading symbols from /usr/local/kamailio/lib/kamailio/modules/ctl.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules/ctl.soReading symbols from /usr/local/kamailio/lib/kamailio/modules/mi_rpc.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules/mi_rpc.soReading symbols from /usr/local/kamailio/lib/kamailio/modules_k/acc.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules_k/acc.soReading symbols from /usr/local/kamailio/lib/kamailio/modules/auth.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules/auth.soReading symbols from /usr/local/kamailio/lib/kamailio/modules_k/auth_db.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules_k/auth_db.soReading symbols from /usr/local/kamailio/lib/kamailio/modules_k/alias_db.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules_k/alias_db.soReading symbols from /usr/local/kamailio/lib/kamailio/modules_k/nathelper.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules_k/nathelper.soReading symbols from /usr/local/kamailio/lib/kamailio/modules/rtpproxy.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules/rtpproxy.soReading symbols from /usr/local/kamailio/lib/kamailio/modules/tls.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules/tls.soReading symbols from /lib/libnss_files.so.2...(no debugging symbols found)...done.Loaded symbols for /lib/libnss_files.so.2Core was generated by `./sbin/kamailio ./etc/kamailio/kamailio.cfg'.Program terminated with signal 11, Segmentation fault.#0 0x080b51a4 in U_MD5Update (context=0xbfd1a7b4, input=0x74756100 <Address 0x74756100 out of bounds>, inputLen=1650745192) at md5.c:160160 memcpy(gdb)
On Wed, Jan 4, 2012 at 10:48 AM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
can you get the backtrace? Locate the core file (perhaps in / directory if you don't use -w command line parameter) and do:
gdb /path/to/kamailio /path/to/corefile bt
Cheers, Daniel
On 1/4/12 9:17 AM, Ali Jawad wrote:
Hi When I did set modparam("auth_db", "calculate_ha1", 0 )
Kamailio is crashing see
Regards
On Tue, Jan 3, 2012 at 11:54 PM, Ali Jawadali.jawad@splendor.net wrote:
Hi It fetches one value from the database to compare it against a second value that has to be computed right, in the computation of the second hash where is the domain part fetched from ? Regards
On Wed, Jan 4, 2012 at 12:26 AM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
On 1/3/12 10:08 PM, Ali Jawad wrote:
Hi
In Xlite/eyebeam I put in the username and one of my 3 kamailio servers respectively as the sip registrar, I.e. register1.domain.com, register2.domain.com and register3.domain.com, that is why I was saying that hashing will create different hashes based on the register domain. With reference to my first related post, one kamailio server is for softphones, one for sip devices and one for mobile phones with SIP software. Each server has a slightly different NAT and Call routing structure.
but your service domain is 'domain.com', specific server addresses (domains) per UA type should be set as outbound proxy on the UA devices.
This is why I wanted to eliminate the domain factor from the hashing procedure, I am sure it chooses the right value from the DB value because it is the same value shown in the log of kamailio against which a comparison is being done and because it works if I put register.domain.com in the domain column rehash the HA! value of the db.
When auth_db module is configured to take the hashed value from database (calculate_ha1 parameter is 0), there is no more computation of it in kamailio -- it is just fetched from database and used -- so it does not matter anymore the domains in the sip message.
Check to see if the xlite does not have a realm field that has to be set properly.
>>>> values at 0xb7b78dac >>>>> >>>>> 5(18649) DEBUG:<core> [db_val.c:117]: converting STRING >>>>> [6f966cd9c628f14cdc20172f96a4d065]<====##### This is the value in >>>>> the DB based on domain.com >>>>> 5(18649) DEBUG: auth [api.c:210]: check_response: Our result = >>>>> '6f95e6235edca0b7765042ef119fd83b'<====##### This value appears >>>>> to >>>>> be the value generated register.domain.com >>>>> 5(18649) DEBUG: auth [api.c:220]: check_response: Authorization
How can I enable the SQL query log ?
I don't know by hart, googling should help you.
Cheers, Daniel
On Tue, Jan 3, 2012 at 8:12 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
why are you using register.domain.com as domain for registration? Isn't domain.com the right one?
Can you enable the sql query log for mysql server and double check if the right value (column) is selected from the database table?
Cheers, Daniel
On 1/3/12 5:13 PM, Ali Jawad wrote: > > Hi > Please see the below, thanks ! > > interface: eth1 (xx.xx.xx.0/255.255.255.0) > match: support1 > > U +6.698682 yy.yy.yy.146:18832 -> xx.xx.xx.51:5060 > REGISTER sip:register.domain.com SIP/2.0. > Via: SIP/2.0/UDP > > > > 192.168.0.191:18832;branch=z9hG4bK-d8754z-05164a466600837d-1---d8754z-;rport. > Max-Forwards: 70. > > > > Contact:sip:support1@192.168.0.191:18832;rinstance=f8e37e314657e0d7;transport=udp. > To: "Test Ast"sip:support1@register.domain.com. > From: "Test Ast"sip:support1@register.domain.com;tag=f710b930. > Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY.. > CSeq: 1 REGISTER. > Expires: 3600. > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, > SUBSCRIBE, INFO. > User-Agent: eyeBeam release 1102q stamp 51814. > Content-Length: 0. > . > > > U +0.005245 xx.xx.xx.51:5060 -> yy.yy.yy.146:18832 > SIP/2.0 401 Unauthorized. > Via: SIP/2.0/UDP > > > > 192.168.0.191:18832;branch=z9hG4bK-d8754z-05164a466600837d-1---d8754z-;rport=18832;received=yy.yy.yy.146. > To: "Test > > > Ast"sip:support1@register.domain.com;tag=e597ca73bdb255490f0cefa03b2fda82.3053. > From: "Test Ast"sip:support1@register.domain.com;tag=f710b930. > Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY.. > CSeq: 1 REGISTER. > WWW-Authenticate: Digest realm="domain.com", > nonce="TwMpUE8DKCSt/IP7jcNRMbCT4TnbqlHl". > Server: kamailio (3.2.1 (i386/linux)). > Content-Length: 0. > . > > > U +0.428042 yy.yy.yy.146:18832 -> xx.xx.xx.51:5060 > REGISTER sip:register.domain.com SIP/2.0. > Via: SIP/2.0/UDP > > > > 192.168.0.191:18832;branch=z9hG4bK-d8754z-fc633b21627dca6d-1---d8754z-;rport. > Max-Forwards: 70. > > > > Contact:sip:support1@192.168.0.191:18832;rinstance=f8e37e314657e0d7;transport=udp. > To: "Test Ast"sip:support1@register.domain.com. > From: "Test Ast"sip:support1@register.domain.com;tag=f710b930. > Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY.. > CSeq: 2 REGISTER. > Expires: 3600. > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, > SUBSCRIBE, INFO. > User-Agent: eyeBeam release 1102q stamp 51814. > Authorization: Digest > > > > username="support1",realm="domain.com",nonce="TwMpUE8DKCSt/IP7jcNRMbCT4TnbqlHl",uri="sip:register.domain.com",response="6122245b77e2df0b90179304464341e7",algorithm=MD5. > Content-Length: 0. > . > > > U +0.005146 xx.xx.xx.51:5060 -> yy.yy.yy.146:18832 > SIP/2.0 401 Unauthorized. > Via: SIP/2.0/UDP > > > > 192.168.0.191:18832;branch=z9hG4bK-d8754z-fc633b21627dca6d-1---d8754z-;rport=18832;received=yy.yy.yy.146. > To: "Test > > > Ast"sip:support1@register.domain.com;tag=e597ca73bdb255490f0cefa03b2fda82.fce3. > From: "Test Ast"sip:support1@register.domain.com;tag=f710b930. > Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY.. > CSeq: 2 REGISTER. > WWW-Authenticate: Digest realm="domain.com", > nonce="TwMpUE8DKCSt/IP7jcNRMbCT4TnbqlHl". > Server: kamailio (3.2.1 (i386/linux)). > Content-Length: 0. > . > > [root@kam-rtp-100-51 mysql]# mail alijawad1@gmail.com< > output.txt > [root@kam-rtp-100-51 mysql]# ngrep -W byline -T support1 -q -d eth1 > interface: eth1 (xx.xx.xx.0/255.255.255.0) > match: support1 > > > > > U +5.321505 yy.yy.yy.146:63610 -> xx.xx.xx.51:5060 > REGISTER sip:register.domain.com SIP/2.0. > Via: SIP/2.0/UDP > > > > 192.168.0.191:63610;branch=z9hG4bK-d8754z-fb28723daa3f772d-1---d8754z-;rport. > Max-Forwards: 70. > > > > Contact:sip:support1@192.168.0.191:63610;rinstance=782b19a2fccc665f;transport=udp. > To: "Test Ast"sip:support1@register.domain.com. > From: "Test Ast"sip:support1@register.domain.com;tag=ba705453. > Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI.. > CSeq: 1 REGISTER. > Expires: 3600. > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, > SUBSCRIBE, INFO. > User-Agent: eyeBeam release 1102q stamp 51814. > Content-Length: 0. > . > > > U +0.004782 xx.xx.xx.51:5060 -> yy.yy.yy.146:63610 > SIP/2.0 401 Unauthorized. > Via: SIP/2.0/UDP > > > > 192.168.0.191:63610;branch=z9hG4bK-d8754z-fb28723daa3f772d-1---d8754z-;rport=63610;received=yy.yy.yy.146. > To: "Test > > > Ast"sip:support1@register.domain.com;tag=e597ca73bdb255490f0cefa03b2fda82.6b98. > From: "Test Ast"sip:support1@register.domain.com;tag=ba705453. > Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI.. > CSeq: 1 REGISTER. > WWW-Authenticate: Digest realm="domain.com", > nonce="TwMpsU8DKIX4lvWDwPsV4iUhCl+iOAdk". > Server: kamailio (3.2.1 (i386/linux)). > Content-Length: 0. > . > > > U +0.400706 yy.yy.yy.146:63610 -> xx.xx.xx.51:5060 > REGISTER sip:register.domain.com SIP/2.0. > Via: SIP/2.0/UDP > > > > 192.168.0.191:63610;branch=z9hG4bK-d8754z-81517d296225234f-1---d8754z-;rport. > Max-Forwards: 70. > > > > Contact:sip:support1@192.168.0.191:63610;rinstance=782b19a2fccc665f;transport=udp. > To: "Test Ast"sip:support1@register.domain.com. > From: "Test Ast"sip:support1@register.domain.com;tag=ba705453. > Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI.. > CSeq: 2 REGISTER. > Expires: 3600. > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, > SUBSCRIBE, INFO. > User-Agent: eyeBeam release 1102q stamp 51814. > Authorization: Digest > > > > username="support1",realm="domain.com",nonce="TwMpsU8DKIX4lvWDwPsV4iUhCl+iOAdk",uri="sip:register.domain.com",response="4bfd80b0b836c20b748ee19a1c886284",algorithm=MD5. > Content-Length: 0. > . > > > U +0.005302 xx.xx.xx.51:5060 -> yy.yy.yy.146:63610 > SIP/2.0 401 Unauthorized. > Via: SIP/2.0/UDP > > > > 192.168.0.191:63610;branch=z9hG4bK-d8754z-81517d296225234f-1---d8754z-;rport=63610;received=yy.yy.yy.146. > To: "Test > > > Ast"sip:support1@register.domain.com;tag=e597ca73bdb255490f0cefa03b2fda82.2f76. > From: "Test Ast"sip:support1@register.domain.com;tag=ba705453. > Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI.. > CSeq: 2 REGISTER. > WWW-Authenticate: Digest realm="domain.com", > nonce="TwMpsU8DKIX4lvWDwPsV4iUhCl+iOAdk". > Server: kamailio (3.2.1 (i386/linux)). > Content-Length: 0. > . > > On Tue, Jan 3, 2012 at 6:08 PM, Daniel-Constantin Mierla > miconda@gmail.com wrote: >> >> Hello, >> >> I need the entire flow for registration, including the 401 reply and >> the >> following REGISTER request. >> >> Cheers, >> Daniel >> >> >> On 1/3/12 5:02 PM, Ali Jawad wrote: >>> >>> Hi >>> Please see the ngrep below, please note that if I use in the db >>> register.domain.com and generate a hash against it for HA1 it >>> works,but then the user cant logon to register2.domain.com >>> >>> >>> U +10.630576 xx.yy.yy.yy:20020 -> xx.xx.xx.xx:5060 >>> REGISTER sip:register.domain SIP/2.0. >>> Via: SIP/2.0/UDP >>> >>> >>> >>> >>> 192.168.0.191:20020;branch=z9hG4bK-d8754z-af65a442980c375f-1---d8754z-;rport. >>> Max-Forwards: 70. >>> >>> >>> >>> >>> Contact:sip:support1@192.168.0.191:20020;rinstance=4009190a4e109ac6;transport=udp. >>> To: "Test Ast"sip:support1@register.domain. >>> From: "Test Ast"sip:support1@register.domain;tag=976bb004. >>> Call-ID: MDFmZDU2ZTI2YjJjMGNlMGFmOTIzMWFmZGQ1ZTNjMDE.. >>> CSeq: 1 REGISTER. >>> Expires: 3600. >>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, >>> SUBSCRIBE, INFO. >>> User-Agent: eyeBeam release 1102q stamp 51814. >>> Content-Length: 0. >>> >>> On Tue, Jan 3, 2012 at 5:58 PM, Daniel-Constantin Mierla >>> miconda@gmail.com wrote: >>>> >>>> Hello, >>>> >>>> >>>> On 1/3/12 4:48 PM, Ali Jawad wrote: >>>>> >>>>> Hi Daniel >>>>> >>>>> Please see >>>>> >>>>> 5(18649) DEBUG:<core> [db_res.c:184]: allocate 8 bytes >>>>> for >>>>> rows >>>>> at >>>>> 0xb7b78d74 >>>>> 5(18649) DEBUG:<core> [db_row.c:119]: allocate 20 bytes >>>>> for >>>>> row >>>>> values at 0xb7b78dac >>>>> 5(18649) DEBUG:<core> [db_val.c:117]: converting STRING >>>>> [6f966cd9c628f14cdc20172f96a4d065] >>>>> 5(18649) DEBUG: auth [api.c:210]: check_response: Our result = >>>>> '6f95e6235edca0b7765042ef119fd83b' >>>>> 5(18649) DEBUG: auth [api.c:220]: check_response: Authorization >>>>> failed >>>>> 5(18649) DEBUG:<core> [db_res.c:81]: freeing 1 columns >>>>> 5(18649) DEBUG:<core> [db_res.c:85]: freeing >>>>> RES_NAMES[0] at >>>>> 0xb7b78d3c >>>>> 5(18649) DEBUG:<core> [db_res.c:94]: freeing result >>>>> names at >>>>> 0xb7b78bfc >>>>> 5(18649) DEBUG:<core> [db_res.c:99]: freeing result >>>>> types at >>>>> 0xb7b78c64 >>>>> 5(18649) DEBUG:<core> [db_res.c:54]: freeing 1 rows >>>>> 5(18649) DEBUG:<core> [db_row.c:97]: freeing row values >>>>> at >>>>> 0xb7b78dac >>>>> 5(18649) DEBUG:<core> [db_res.c:62]: freeing rows at >>>>> 0xb7b78d74 >>>>> 5(18649) DEBUG:<core> [db_res.c:136]: freeing result >>>>> set at >>>>> 0xb7b78bb0 >>>>> 5(18649) DEBUG: auth [challenge.c:102]: build_challenge_hf: >>>>> realm='nymgo.com' >>>>> 5(18649) DEBUG: auth [challenge.c:244]: auth: 'WWW-Authenticate: >>>>> Digest realm="domain.com", >>>>> nonce="TwMcuk8DG47SLxatlNdZfyfR8p3OiyAE" >>>>> ' >>>>> >>>>> I rebuilt the hashes against domain.com and then tried to connect >>>>> to >>>>> sip1.domain.com and sip2.domain.com and sip3.domain.com with all >>>>> of >>>>> the having >>>>> >>>>> >>>>> # ----- auth_db params ----- >>>>> #!ifdef WITH_AUTH >>>>> modparam("auth_db", "db_url", DBURL) >>>>> modparam("auth_db", "calculate_ha1", 0 ) >>>>> modparam("auth_db", "password_column", "ha1") >>>>> modparam("auth_db", "load_credentials", "") >>>>> modparam("auth_db", "use_domain", MULTIDOMAIN) >>>>> >>>>> And in the routing process : >>>>> >>>>> if (!www_authorize("domain.com", "subscriber")) >>>>> { >>>>> >>>>> www_challenge("domain.com", "0"); >>>>> exit; >>>>> } >>>>> >>>>> >>>>> +++++++++++++ >>>>> >>>>> My point is that the hashes are caculated from user:doman:pwd >>>>> which >>>>> are extracted from the SIP packet and in this case the domains >>>>> are >>>>> sip1,sip2,sip3 while the hashes stored in the database are >>>>> generated >>>>> against domain.com >>>>> >>>>> If " ha1 is actually hash over 'user:realm:pwd' " shouldn't I >>>>> have >>>>> to >>>>> set the domain/realm in the config file ? >>>> >>>> >>>> the first parameter in www_authorize and www_challenge functions >>>> is >>>> the >>>> realm and it is used to build the digest response. >>>> >>>> Is your phone putting user@domain in authorization header? Can you >>>> paste >>>> here the ngrep of registration? >>>> >>>> Cheers, >>>> Daniel >>>> >>>> >>>>> I might be wrong....thanks for the help so far. >>>>> >>>>> Regards >>>>> >>>>> On Tue, Jan 3, 2012 at 5:15 PM, Daniel-Constantin Mierla >>>>> miconda@gmail.com wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> >>>>>> On 1/3/12 4:12 PM, Ali Jawad wrote: >>>>>>> >>>>>>> Hi Daniel >>>>>>> This certainly makes sense, I will try it in a few mins, but >>>>>>> what >>>>>>> I >>>>>>> observed at Debug Level 3 is that Hash is calculated before >>>>>>> www_authenticate is executed and it shows HA comparison failed, >>>>>>> if >>>>>>> I >>>>>>> do use domain.com instead of $fd and use $domain.com in db >>>>>>> domain >>>>>>> field and build HA1 filed based on that, wont Kamailio still >>>>>>> try >>>>>>> to >>>>>>> build the HA1 hash which it will compare form user:domain:pwd >>>>>>> where >>>>>>> domain is fed in to the hash function from the header of the >>>>>>> SIP >>>>>>> packet ? >>>>>> >>>>>> >>>>>> the ha1 is actually hash over 'user:realm:pwd' -- it is just >>>>>> common >>>>>> practice >>>>>> to use the domain as realm, since realm should be a unique token >>>>>> to >>>>>> identify >>>>>> the service, but it can be any random string. realm is given as >>>>>> parameter >>>>>> to auth functions in kamailio.cfg >>>>>> >>>>>> Cheers, >>>>>> Daniel >>>>>> >>>>>> >>>>>>> Regards >>>>>>> >>>>>>> On Tue, Jan 3, 2012 at 5:07 PM, Daniel-Constantin Mierla >>>>>>> miconda@gmail.com wrote: >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> you can simply use 'domain.com' as realm parameter to >>>>>>>> authentication >>>>>>>> function instead of $fd. Also build ha1 and ha1b with >>>>>>>> domain.com >>>>>>>> and >>>>>>>> then >>>>>>>> you are safe no matter which sip server is used. >>>>>>>> >>>>>>>> Of course you can build the realm by striping first token >>>>>>>> before >>>>>>>> '.' >>>>>>>> in >>>>>>>> $fd >>>>>>>> and pass it to authentication functions, but not sure if makes >>>>>>>> sense >>>>>>>> since >>>>>>>> it should be always domain.com >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Daniel >>>>>>>> >>>>>>>> >>>>>>>> On 1/3/12 3:15 PM, Ali Jawad wrote: >>>>>>>>> >>>>>>>>> Hi >>>>>>>>> After some research it seems to me that the only way to >>>>>>>>> achieve >>>>>>>>> this >>>>>>>>> is to "try" and change how hashing is done in the source >>>>>>>>> code, a >>>>>>>>> little bit too ambitious for me, and it means I will have >>>>>>>>> loads >>>>>>>>> of >>>>>>>>> problems each time an upgrade is released. >>>>>>>>> >>>>>>>>> Or >>>>>>>>> >>>>>>>>> Use pseudovariables to fix the value of the $fd value to >>>>>>>>> something >>>>>>>>> constant, while this worked for values like $var(y) I was not >>>>>>>>> able >>>>>>>>> to >>>>>>>>> assign/strip $fd to remove the subdomain part. >>>>>>>>> >>>>>>>>> Any input please ? >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> >>>>>>>>> On Tue, Jan 3, 2012 at 2:06 PM, Ali >>>>>>>>> Jawadali.jawad@splendor.net >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Hi >>>>>>>>>> I do have 3 Kamailio servers, one for mobile phone >>>>>>>>>> registrations, >>>>>>>>>> one >>>>>>>>>> for softphone registrations and one for SIP device >>>>>>>>>> registrations. >>>>>>>>>> Each >>>>>>>>>> of those devices connects to it's perspective kamailio >>>>>>>>>> server >>>>>>>>>> >>>>>>>>>> sip1.domain.com >>>>>>>>>> sip2.domain.com >>>>>>>>>> sip3.domain.com >>>>>>>>>> >>>>>>>>>> All 3 Kamailio servers share the same database, and users >>>>>>>>>> can >>>>>>>>>> use >>>>>>>>>> their kamailio user/pwd on any of the devices, now I want to >>>>>>>>>> use >>>>>>>>>> encrypted passwords and remove clear text passwords from the >>>>>>>>>> database. >>>>>>>>>> I did test with one server and all is fine,however if a user >>>>>>>>>> want >>>>>>>>>> to >>>>>>>>>> register from the second kamailio server it does not work, >>>>>>>>>> basically >>>>>>>>>> because the db domain entry from which the hash is created >>>>>>>>>> is >>>>>>>>>> sip1.domain.com and stored in the db, while the user >>>>>>>>>> connects >>>>>>>>>> from >>>>>>>>>> to >>>>>>>>>> sip2.domain.com this eventually generates a different hash. >>>>>>>>>> >>>>>>>>>> Is there anyway to overcome this ? Can I exclude Domain from >>>>>>>>>> Hash >>>>>>>>>> generation ? Any other option that allows me to do the above >>>>>>>>>> ? >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> -- >>>>>>>> Daniel-Constantin Mierla -- http://www.asipto.com >>>>>>>> http://linkedin.com/in/miconda -- http://twitter.com/miconda >>>>>>>> >>>>>>> -- >>>>>>> Daniel-Constantin Mierla -- http://www.asipto.com >>>>>>> http://linkedin.com/in/miconda -- http://twitter.com/miconda >>>>> >>>>> >>>>> >>>> -- >>>> Daniel-Constantin Mierla -- http://www.asipto.com >>>> http://linkedin.com/in/miconda -- http://twitter.com/miconda >>>> >> -- >> Daniel-Constantin Mierla -- http://www.asipto.com >> http://linkedin.com/in/miconda -- http://twitter.com/miconda
>>
Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda
-- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda
-- Ali Jawad Information Systems Manager Splendor Telecom (www.splendor.net) Beirut, Lebanon Phone: +9611373725/ext 116 FAX: +9611375554
-- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda
Hi Daniel In this part of the debug log
7(19193) DEBUG: <core> [db_val.c:117]: converting STRING [fce64fbb39941fd185732f778188870f] 7(19193) DEBUG: auth [api.c:210]: check_response: Our result = 'd9f9e5c049e04d827a04e46b25d43ec5' 7(19193) DEBUG: auth [api.c:220]: check_response: Authorization failed
The first line is apparently fetched from the DB as this value matches the DB row, the second value is different each time I logon and out, shouldn't it be the same value each and everytime, even if it is different from the 1st line ?
See for the same user/pwd/client...just logging in and out :
3(19189) DEBUG: <core> [db_val.c:117]: converting STRING [fce64fbb39941fd185732f778188870f] 3(19189) DEBUG: auth [api.c:210]: check_response: Our result = 'd5fb7638088205bb82a03369c5c52292' 3(19189) DEBUG: auth [api.c:220]: check_response: Authorization failed
and
1(19187) DEBUG: <core> [db_val.c:117]: converting STRING [fce64fbb39941fd185732f778188870f] 1(19187) DEBUG: auth [api.c:210]: check_response: Our result = 'f22c158e695e453d713d8c67c6c1a3b8'
Regards
On Wed, Jan 4, 2012 at 10:54 AM, Ali Jawad ali.jawad@splendor.net wrote:
Hi Daniel Back-trace below, regards.
[root@kam-rtp-100-51 kamailio]# gdb /usr/local/kamailio/sbin/kamailio /core.18024GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-37.el5)Copyright (C) 2009 Free Software Foundation, Inc.License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.htmlThis is free software: you are free to change and redistribute it.There is NO WARRANTY, to the extent permitted by law. Type "show copying"and "show warranty" for details.This GDB was configured as "i386-redhat-linux-gnu".For bug reporting instructions, please see:http://www.gnu.org/software/gdb/bugs/...Reading symbols from /usr/local/kamailio/sbin/kamailio...done.[New Thread 18024]Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done.Loaded symbols for /lib/libdl.so.2Reading symbols from /lib/libresolv.so.2...(no debugging symbols found)...done.Loaded symbols for /lib/libresolv.so.2Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.Loaded symbols for /lib/libc.so.6Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.Loaded symbols for /lib/ld-linux.so.2Reading symbols from /usr/local/kamailio/lib/kamailio/modules/db_mysql.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules/db_mysql.soReading symbols from /usr/lib/mysql/libmysqlclient.so.15...(no debugging symbols found)...done.Loaded symbols for /usr/lib/mysql/libmysqlclient.so.15Reading symbols from /lib/libz.so.1...(no debugging symbols found)...done.Loaded symbols for /lib/libz.so.1Reading symbols from /lib/libcrypt.so.1...(no debugging symbols found)...done.Loaded symbols for /lib/libcrypt.so.1Reading symbols from /lib/libnsl.so.1...(no debugging symbols found)...done.Loaded symbols for /lib/libnsl.so.1Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done.Loaded symbols for /lib/libm.so.6Reading symbols from /lib/libssl.so.6...(no debugging symbols found)...done.Loaded symbols for /lib/libssl.so.6Reading symbols from /lib/libcrypto.so.6...(no debugging symbols found)...done.Loaded symbols for /lib/libcrypto.so.6Reading symbols from /usr/local/kamailio/lib/kamailio/libsrdb2.so.1...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/libsrdb2.so.1Reading symbols from /usr/local/kamailio/lib/kamailio/libsrdb1.so.1...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/libsrdb1.so.1Reading symbols from /usr/lib/libgssapi_krb5.so.2...(no debugging symbols found)...done.Loaded symbols for /usr/lib/libgssapi_krb5.so.2Reading symbols from /usr/lib/libkrb5.so.3...(no debugging symbols found)...done.Loaded symbols for /usr/lib/libkrb5.so.3Reading symbols from /lib/libcom_err.so.2...(no debugging symbols found)...done.Loaded symbols for /lib/libcom_err.so.2Reading symbols from /usr/lib/libk5crypto.so.3...(no debugging symbols found)...done.Loaded symbols for /usr/lib/libk5crypto.so.3Reading symbols from /usr/lib/libkrb5support.so.0...(no debugging symbols found)...done.Loaded symbols for /usr/lib/libkrb5support.so.0Reading symbols from /lib/libkeyutils.so.1...(no debugging symbols found)...done.Loaded symbols for /lib/libkeyutils.so.1Reading symbols from /lib/libselinux.so.1...(no debugging symbols found)...done.Loaded symbols for /lib/libselinux.so.1Reading symbols from /lib/libsepol.so.1...(no debugging symbols found)...done.Loaded symbols for /lib/libsepol.so.1Reading symbols from /usr/local/kamailio/lib/kamailio/modules_k/exec.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules_k/exec.soReading symbols from /usr/local/kamailio/lib/kamailio/modules_k/group.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules_k/group.soReading symbols from /usr/local/kamailio/lib/kamailio/libkcore.so.1...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/libkcore.so.1Reading symbols from /usr/local/kamailio/lib/kamailio/modules_k/speeddial.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules_k/speeddial.soReading symbols from /usr/local/kamailio/lib/kamailio/modules/carrierroute.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules/carrierroute.soReading symbols from /usr/lib/libconfuse.so.0...(no debugging symbols found)...done.Loaded symbols for /usr/lib/libconfuse.so.0Reading symbols from /usr/local/kamailio/lib/kamailio/libtrie.so.1...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/libtrie.so.1Reading symbols from /usr/local/kamailio/lib/kamailio/libkmi.so.1...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/libkmi.so.1Reading symbols from /usr/local/kamailio/lib/kamailio/modules_k/mi_fifo.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules_k/mi_fifo.soReading symbols from /usr/local/kamailio/lib/kamailio/modules_k/kex.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules_k/kex.soReading symbols from /usr/local/kamailio/lib/kamailio/modules/tm.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules/tm.soReading symbols from /usr/local/kamailio/lib/kamailio/modules_k/tmx.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules_k/tmx.soReading symbols from /usr/local/kamailio/lib/kamailio/modules/sl.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules/sl.soReading symbols from /usr/local/kamailio/lib/kamailio/modules_k/rr.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules_k/rr.soReading symbols from /usr/local/kamailio/lib/kamailio/modules_k/pv.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules_k/pv.soReading symbols from /usr/local/kamailio/lib/kamailio/modules_k/maxfwd.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules_k/maxfwd.soReading symbols from /usr/local/kamailio/lib/kamailio/modules_k/usrloc.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules_k/usrloc.soReading symbols from /usr/local/kamailio/lib/kamailio/modules_k/registrar.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules_k/registrar.soReading symbols from /usr/local/kamailio/lib/kamailio/modules_k/textops.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules_k/textops.soReading symbols from /usr/local/kamailio/lib/kamailio/modules_k/siputils.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules_k/siputils.soReading symbols from /usr/local/kamailio/lib/kamailio/modules_k/xlog.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules_k/xlog.soReading symbols from /usr/local/kamailio/lib/kamailio/modules/sanity.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules/sanity.soReading symbols from /usr/local/kamailio/lib/kamailio/modules/ctl.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules/ctl.soReading symbols from /usr/local/kamailio/lib/kamailio/modules/mi_rpc.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules/mi_rpc.soReading symbols from /usr/local/kamailio/lib/kamailio/modules_k/acc.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules_k/acc.soReading symbols from /usr/local/kamailio/lib/kamailio/modules/auth.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules/auth.soReading symbols from /usr/local/kamailio/lib/kamailio/modules_k/auth_db.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules_k/auth_db.soReading symbols from /usr/local/kamailio/lib/kamailio/modules_k/alias_db.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules_k/alias_db.soReading symbols from /usr/local/kamailio/lib/kamailio/modules_k/nathelper.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules_k/nathelper.soReading symbols from /usr/local/kamailio/lib/kamailio/modules/rtpproxy.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules/rtpproxy.soReading symbols from /usr/local/kamailio/lib/kamailio/modules/tls.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules/tls.soReading symbols from /lib/libnss_files.so.2...(no debugging symbols found)...done.Loaded symbols for /lib/libnss_files.so.2Core was generated by `./sbin/kamailio ./etc/kamailio/kamailio.cfg'.Program terminated with signal 11, Segmentation fault.#0 0x080b51a4 in U_MD5Update (context=0xbfd1a7b4, input=0x74756100 <Address 0x74756100 out of bounds>, inputLen=1650745192) at md5.c:160160 memcpy(gdb)
On Wed, Jan 4, 2012 at 10:48 AM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
can you get the backtrace? Locate the core file (perhaps in / directory if you don't use -w command line parameter) and do:
gdb /path/to/kamailio /path/to/corefile bt
Cheers, Daniel
On 1/4/12 9:17 AM, Ali Jawad wrote:
Hi When I did set modparam("auth_db", "calculate_ha1", 0 )
Kamailio is crashing see
Regards
On Tue, Jan 3, 2012 at 11:54 PM, Ali Jawadali.jawad@splendor.net wrote:
Hi It fetches one value from the database to compare it against a second value that has to be computed right, in the computation of the second hash where is the domain part fetched from ? Regards
On Wed, Jan 4, 2012 at 12:26 AM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
On 1/3/12 10:08 PM, Ali Jawad wrote:
Hi
In Xlite/eyebeam I put in the username and one of my 3 kamailio servers respectively as the sip registrar, I.e. register1.domain.com, register2.domain.com and register3.domain.com, that is why I was saying that hashing will create different hashes based on the register domain. With reference to my first related post, one kamailio server is for softphones, one for sip devices and one for mobile phones with SIP software. Each server has a slightly different NAT and Call routing structure.
but your service domain is 'domain.com', specific server addresses (domains) per UA type should be set as outbound proxy on the UA devices.
This is why I wanted to eliminate the domain factor from the hashing procedure, I am sure it chooses the right value from the DB value because it is the same value shown in the log of kamailio against which a comparison is being done and because it works if I put register.domain.com in the domain column rehash the HA! value of the db.
When auth_db module is configured to take the hashed value from database (calculate_ha1 parameter is 0), there is no more computation of it in kamailio -- it is just fetched from database and used -- so it does not matter anymore the domains in the sip message.
Check to see if the xlite does not have a realm field that has to be set properly.
>>>>> values at 0xb7b78dac >>>>>> >>>>>> 5(18649) DEBUG:<core> [db_val.c:117]: converting STRING >>>>>> [6f966cd9c628f14cdc20172f96a4d065]<====##### This is the value in >>>>>> the DB based on domain.com >>>>>> 5(18649) DEBUG: auth [api.c:210]: check_response: Our result = >>>>>> '6f95e6235edca0b7765042ef119fd83b'<====##### This value appears >>>>>> to >>>>>> be the value generated register.domain.com >>>>>> 5(18649) DEBUG: auth [api.c:220]: check_response: Authorization
How can I enable the SQL query log ?
I don't know by hart, googling should help you.
Cheers, Daniel
On Tue, Jan 3, 2012 at 8:12 PM, Daniel-Constantin Mierla miconda@gmail.com wrote: > > Hello, > > why are you using register.domain.com as domain for registration? > Isn't > domain.com the right one? > > Can you enable the sql query log for mysql server and double check if > the > right value (column) is selected from the database table? > > Cheers, > Daniel > > > On 1/3/12 5:13 PM, Ali Jawad wrote: >> >> Hi >> Please see the below, thanks ! >> >> interface: eth1 (xx.xx.xx.0/255.255.255.0) >> match: support1 >> >> U +6.698682 yy.yy.yy.146:18832 -> xx.xx.xx.51:5060 >> REGISTER sip:register.domain.com SIP/2.0. >> Via: SIP/2.0/UDP >> >> >> >> 192.168.0.191:18832;branch=z9hG4bK-d8754z-05164a466600837d-1---d8754z-;rport. >> Max-Forwards: 70. >> >> >> >> Contact:sip:support1@192.168.0.191:18832;rinstance=f8e37e314657e0d7;transport=udp. >> To: "Test Ast"sip:support1@register.domain.com. >> From: "Test Ast"sip:support1@register.domain.com;tag=f710b930. >> Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY.. >> CSeq: 1 REGISTER. >> Expires: 3600. >> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, >> SUBSCRIBE, INFO. >> User-Agent: eyeBeam release 1102q stamp 51814. >> Content-Length: 0. >> . >> >> >> U +0.005245 xx.xx.xx.51:5060 -> yy.yy.yy.146:18832 >> SIP/2.0 401 Unauthorized. >> Via: SIP/2.0/UDP >> >> >> >> 192.168.0.191:18832;branch=z9hG4bK-d8754z-05164a466600837d-1---d8754z-;rport=18832;received=yy.yy.yy.146. >> To: "Test >> >> >> Ast"sip:support1@register.domain.com;tag=e597ca73bdb255490f0cefa03b2fda82.3053. >> From: "Test Ast"sip:support1@register.domain.com;tag=f710b930. >> Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY.. >> CSeq: 1 REGISTER. >> WWW-Authenticate: Digest realm="domain.com", >> nonce="TwMpUE8DKCSt/IP7jcNRMbCT4TnbqlHl". >> Server: kamailio (3.2.1 (i386/linux)). >> Content-Length: 0. >> . >> >> >> U +0.428042 yy.yy.yy.146:18832 -> xx.xx.xx.51:5060 >> REGISTER sip:register.domain.com SIP/2.0. >> Via: SIP/2.0/UDP >> >> >> >> 192.168.0.191:18832;branch=z9hG4bK-d8754z-fc633b21627dca6d-1---d8754z-;rport. >> Max-Forwards: 70. >> >> >> >> Contact:sip:support1@192.168.0.191:18832;rinstance=f8e37e314657e0d7;transport=udp. >> To: "Test Ast"sip:support1@register.domain.com. >> From: "Test Ast"sip:support1@register.domain.com;tag=f710b930. >> Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY.. >> CSeq: 2 REGISTER. >> Expires: 3600. >> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, >> SUBSCRIBE, INFO. >> User-Agent: eyeBeam release 1102q stamp 51814. >> Authorization: Digest >> >> >> >> username="support1",realm="domain.com",nonce="TwMpUE8DKCSt/IP7jcNRMbCT4TnbqlHl",uri="sip:register.domain.com",response="6122245b77e2df0b90179304464341e7",algorithm=MD5. >> Content-Length: 0. >> . >> >> >> U +0.005146 xx.xx.xx.51:5060 -> yy.yy.yy.146:18832 >> SIP/2.0 401 Unauthorized. >> Via: SIP/2.0/UDP >> >> >> >> 192.168.0.191:18832;branch=z9hG4bK-d8754z-fc633b21627dca6d-1---d8754z-;rport=18832;received=yy.yy.yy.146. >> To: "Test >> >> >> Ast"sip:support1@register.domain.com;tag=e597ca73bdb255490f0cefa03b2fda82.fce3. >> From: "Test Ast"sip:support1@register.domain.com;tag=f710b930. >> Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY.. >> CSeq: 2 REGISTER. >> WWW-Authenticate: Digest realm="domain.com", >> nonce="TwMpUE8DKCSt/IP7jcNRMbCT4TnbqlHl". >> Server: kamailio (3.2.1 (i386/linux)). >> Content-Length: 0. >> . >> >> [root@kam-rtp-100-51 mysql]# mail alijawad1@gmail.com< >> output.txt >> [root@kam-rtp-100-51 mysql]# ngrep -W byline -T support1 -q -d eth1 >> interface: eth1 (xx.xx.xx.0/255.255.255.0) >> match: support1 >> >> >> >> >> U +5.321505 yy.yy.yy.146:63610 -> xx.xx.xx.51:5060 >> REGISTER sip:register.domain.com SIP/2.0. >> Via: SIP/2.0/UDP >> >> >> >> 192.168.0.191:63610;branch=z9hG4bK-d8754z-fb28723daa3f772d-1---d8754z-;rport. >> Max-Forwards: 70. >> >> >> >> Contact:sip:support1@192.168.0.191:63610;rinstance=782b19a2fccc665f;transport=udp. >> To: "Test Ast"sip:support1@register.domain.com. >> From: "Test Ast"sip:support1@register.domain.com;tag=ba705453. >> Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI.. >> CSeq: 1 REGISTER. >> Expires: 3600. >> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, >> SUBSCRIBE, INFO. >> User-Agent: eyeBeam release 1102q stamp 51814. >> Content-Length: 0. >> . >> >> >> U +0.004782 xx.xx.xx.51:5060 -> yy.yy.yy.146:63610 >> SIP/2.0 401 Unauthorized. >> Via: SIP/2.0/UDP >> >> >> >> 192.168.0.191:63610;branch=z9hG4bK-d8754z-fb28723daa3f772d-1---d8754z-;rport=63610;received=yy.yy.yy.146. >> To: "Test >> >> >> Ast"sip:support1@register.domain.com;tag=e597ca73bdb255490f0cefa03b2fda82.6b98. >> From: "Test Ast"sip:support1@register.domain.com;tag=ba705453. >> Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI.. >> CSeq: 1 REGISTER. >> WWW-Authenticate: Digest realm="domain.com", >> nonce="TwMpsU8DKIX4lvWDwPsV4iUhCl+iOAdk". >> Server: kamailio (3.2.1 (i386/linux)). >> Content-Length: 0. >> . >> >> >> U +0.400706 yy.yy.yy.146:63610 -> xx.xx.xx.51:5060 >> REGISTER sip:register.domain.com SIP/2.0. >> Via: SIP/2.0/UDP >> >> >> >> 192.168.0.191:63610;branch=z9hG4bK-d8754z-81517d296225234f-1---d8754z-;rport. >> Max-Forwards: 70. >> >> >> >> Contact:sip:support1@192.168.0.191:63610;rinstance=782b19a2fccc665f;transport=udp. >> To: "Test Ast"sip:support1@register.domain.com. >> From: "Test Ast"sip:support1@register.domain.com;tag=ba705453. >> Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI.. >> CSeq: 2 REGISTER. >> Expires: 3600. >> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, >> SUBSCRIBE, INFO. >> User-Agent: eyeBeam release 1102q stamp 51814. >> Authorization: Digest >> >> >> >> username="support1",realm="domain.com",nonce="TwMpsU8DKIX4lvWDwPsV4iUhCl+iOAdk",uri="sip:register.domain.com",response="4bfd80b0b836c20b748ee19a1c886284",algorithm=MD5. >> Content-Length: 0. >> . >> >> >> U +0.005302 xx.xx.xx.51:5060 -> yy.yy.yy.146:63610 >> SIP/2.0 401 Unauthorized. >> Via: SIP/2.0/UDP >> >> >> >> 192.168.0.191:63610;branch=z9hG4bK-d8754z-81517d296225234f-1---d8754z-;rport=63610;received=yy.yy.yy.146. >> To: "Test >> >> >> Ast"sip:support1@register.domain.com;tag=e597ca73bdb255490f0cefa03b2fda82.2f76. >> From: "Test Ast"sip:support1@register.domain.com;tag=ba705453. >> Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI.. >> CSeq: 2 REGISTER. >> WWW-Authenticate: Digest realm="domain.com", >> nonce="TwMpsU8DKIX4lvWDwPsV4iUhCl+iOAdk". >> Server: kamailio (3.2.1 (i386/linux)). >> Content-Length: 0. >> . >> >> On Tue, Jan 3, 2012 at 6:08 PM, Daniel-Constantin Mierla >> miconda@gmail.com wrote: >>> >>> Hello, >>> >>> I need the entire flow for registration, including the 401 reply and >>> the >>> following REGISTER request. >>> >>> Cheers, >>> Daniel >>> >>> >>> On 1/3/12 5:02 PM, Ali Jawad wrote: >>>> >>>> Hi >>>> Please see the ngrep below, please note that if I use in the db >>>> register.domain.com and generate a hash against it for HA1 it >>>> works,but then the user cant logon to register2.domain.com >>>> >>>> >>>> U +10.630576 xx.yy.yy.yy:20020 -> xx.xx.xx.xx:5060 >>>> REGISTER sip:register.domain SIP/2.0. >>>> Via: SIP/2.0/UDP >>>> >>>> >>>> >>>> >>>> 192.168.0.191:20020;branch=z9hG4bK-d8754z-af65a442980c375f-1---d8754z-;rport. >>>> Max-Forwards: 70. >>>> >>>> >>>> >>>> >>>> Contact:sip:support1@192.168.0.191:20020;rinstance=4009190a4e109ac6;transport=udp. >>>> To: "Test Ast"sip:support1@register.domain. >>>> From: "Test Ast"sip:support1@register.domain;tag=976bb004. >>>> Call-ID: MDFmZDU2ZTI2YjJjMGNlMGFmOTIzMWFmZGQ1ZTNjMDE.. >>>> CSeq: 1 REGISTER. >>>> Expires: 3600. >>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, >>>> SUBSCRIBE, INFO. >>>> User-Agent: eyeBeam release 1102q stamp 51814. >>>> Content-Length: 0. >>>> >>>> On Tue, Jan 3, 2012 at 5:58 PM, Daniel-Constantin Mierla >>>> miconda@gmail.com wrote: >>>>> >>>>> Hello, >>>>> >>>>> >>>>> On 1/3/12 4:48 PM, Ali Jawad wrote: >>>>>> >>>>>> Hi Daniel >>>>>> >>>>>> Please see >>>>>> >>>>>> 5(18649) DEBUG:<core> [db_res.c:184]: allocate 8 bytes >>>>>> for >>>>>> rows >>>>>> at >>>>>> 0xb7b78d74 >>>>>> 5(18649) DEBUG:<core> [db_row.c:119]: allocate 20 bytes >>>>>> for >>>>>> row >>>>>> values at 0xb7b78dac >>>>>> 5(18649) DEBUG:<core> [db_val.c:117]: converting STRING >>>>>> [6f966cd9c628f14cdc20172f96a4d065] >>>>>> 5(18649) DEBUG: auth [api.c:210]: check_response: Our result = >>>>>> '6f95e6235edca0b7765042ef119fd83b' >>>>>> 5(18649) DEBUG: auth [api.c:220]: check_response: Authorization >>>>>> failed >>>>>> 5(18649) DEBUG:<core> [db_res.c:81]: freeing 1 columns >>>>>> 5(18649) DEBUG:<core> [db_res.c:85]: freeing >>>>>> RES_NAMES[0] at >>>>>> 0xb7b78d3c >>>>>> 5(18649) DEBUG:<core> [db_res.c:94]: freeing result >>>>>> names at >>>>>> 0xb7b78bfc >>>>>> 5(18649) DEBUG:<core> [db_res.c:99]: freeing result >>>>>> types at >>>>>> 0xb7b78c64 >>>>>> 5(18649) DEBUG:<core> [db_res.c:54]: freeing 1 rows >>>>>> 5(18649) DEBUG:<core> [db_row.c:97]: freeing row values >>>>>> at >>>>>> 0xb7b78dac >>>>>> 5(18649) DEBUG:<core> [db_res.c:62]: freeing rows at >>>>>> 0xb7b78d74 >>>>>> 5(18649) DEBUG:<core> [db_res.c:136]: freeing result >>>>>> set at >>>>>> 0xb7b78bb0 >>>>>> 5(18649) DEBUG: auth [challenge.c:102]: build_challenge_hf: >>>>>> realm='nymgo.com' >>>>>> 5(18649) DEBUG: auth [challenge.c:244]: auth: 'WWW-Authenticate: >>>>>> Digest realm="domain.com", >>>>>> nonce="TwMcuk8DG47SLxatlNdZfyfR8p3OiyAE" >>>>>> ' >>>>>> >>>>>> I rebuilt the hashes against domain.com and then tried to connect >>>>>> to >>>>>> sip1.domain.com and sip2.domain.com and sip3.domain.com with all >>>>>> of >>>>>> the having >>>>>> >>>>>> >>>>>> # ----- auth_db params ----- >>>>>> #!ifdef WITH_AUTH >>>>>> modparam("auth_db", "db_url", DBURL) >>>>>> modparam("auth_db", "calculate_ha1", 0 ) >>>>>> modparam("auth_db", "password_column", "ha1") >>>>>> modparam("auth_db", "load_credentials", "") >>>>>> modparam("auth_db", "use_domain", MULTIDOMAIN) >>>>>> >>>>>> And in the routing process : >>>>>> >>>>>> if (!www_authorize("domain.com", "subscriber")) >>>>>> { >>>>>> >>>>>> www_challenge("domain.com", "0"); >>>>>> exit; >>>>>> } >>>>>> >>>>>> >>>>>> +++++++++++++ >>>>>> >>>>>> My point is that the hashes are caculated from user:doman:pwd >>>>>> which >>>>>> are extracted from the SIP packet and in this case the domains >>>>>> are >>>>>> sip1,sip2,sip3 while the hashes stored in the database are >>>>>> generated >>>>>> against domain.com >>>>>> >>>>>> If " ha1 is actually hash over 'user:realm:pwd' " shouldn't I >>>>>> have >>>>>> to >>>>>> set the domain/realm in the config file ? >>>>> >>>>> >>>>> the first parameter in www_authorize and www_challenge functions >>>>> is >>>>> the >>>>> realm and it is used to build the digest response. >>>>> >>>>> Is your phone putting user@domain in authorization header? Can you >>>>> paste >>>>> here the ngrep of registration? >>>>> >>>>> Cheers, >>>>> Daniel >>>>> >>>>> >>>>>> I might be wrong....thanks for the help so far. >>>>>> >>>>>> Regards >>>>>> >>>>>> On Tue, Jan 3, 2012 at 5:15 PM, Daniel-Constantin Mierla >>>>>> miconda@gmail.com wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> >>>>>>> On 1/3/12 4:12 PM, Ali Jawad wrote: >>>>>>>> >>>>>>>> Hi Daniel >>>>>>>> This certainly makes sense, I will try it in a few mins, but >>>>>>>> what >>>>>>>> I >>>>>>>> observed at Debug Level 3 is that Hash is calculated before >>>>>>>> www_authenticate is executed and it shows HA comparison failed, >>>>>>>> if >>>>>>>> I >>>>>>>> do use domain.com instead of $fd and use $domain.com in db >>>>>>>> domain >>>>>>>> field and build HA1 filed based on that, wont Kamailio still >>>>>>>> try >>>>>>>> to >>>>>>>> build the HA1 hash which it will compare form user:domain:pwd >>>>>>>> where >>>>>>>> domain is fed in to the hash function from the header of the >>>>>>>> SIP >>>>>>>> packet ? >>>>>>> >>>>>>> >>>>>>> the ha1 is actually hash over 'user:realm:pwd' -- it is just >>>>>>> common >>>>>>> practice >>>>>>> to use the domain as realm, since realm should be a unique token >>>>>>> to >>>>>>> identify >>>>>>> the service, but it can be any random string. realm is given as >>>>>>> parameter >>>>>>> to auth functions in kamailio.cfg >>>>>>> >>>>>>> Cheers, >>>>>>> Daniel >>>>>>> >>>>>>> >>>>>>>> Regards >>>>>>>> >>>>>>>> On Tue, Jan 3, 2012 at 5:07 PM, Daniel-Constantin Mierla >>>>>>>> miconda@gmail.com wrote: >>>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> you can simply use 'domain.com' as realm parameter to >>>>>>>>> authentication >>>>>>>>> function instead of $fd. Also build ha1 and ha1b with >>>>>>>>> domain.com >>>>>>>>> and >>>>>>>>> then >>>>>>>>> you are safe no matter which sip server is used. >>>>>>>>> >>>>>>>>> Of course you can build the realm by striping first token >>>>>>>>> before >>>>>>>>> '.' >>>>>>>>> in >>>>>>>>> $fd >>>>>>>>> and pass it to authentication functions, but not sure if makes >>>>>>>>> sense >>>>>>>>> since >>>>>>>>> it should be always domain.com >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Daniel >>>>>>>>> >>>>>>>>> >>>>>>>>> On 1/3/12 3:15 PM, Ali Jawad wrote: >>>>>>>>>> >>>>>>>>>> Hi >>>>>>>>>> After some research it seems to me that the only way to >>>>>>>>>> achieve >>>>>>>>>> this >>>>>>>>>> is to "try" and change how hashing is done in the source >>>>>>>>>> code, a >>>>>>>>>> little bit too ambitious for me, and it means I will have >>>>>>>>>> loads >>>>>>>>>> of >>>>>>>>>> problems each time an upgrade is released. >>>>>>>>>> >>>>>>>>>> Or >>>>>>>>>> >>>>>>>>>> Use pseudovariables to fix the value of the $fd value to >>>>>>>>>> something >>>>>>>>>> constant, while this worked for values like $var(y) I was not >>>>>>>>>> able >>>>>>>>>> to >>>>>>>>>> assign/strip $fd to remove the subdomain part. >>>>>>>>>> >>>>>>>>>> Any input please ? >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> >>>>>>>>>> On Tue, Jan 3, 2012 at 2:06 PM, Ali >>>>>>>>>> Jawadali.jawad@splendor.net >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Hi >>>>>>>>>>> I do have 3 Kamailio servers, one for mobile phone >>>>>>>>>>> registrations, >>>>>>>>>>> one >>>>>>>>>>> for softphone registrations and one for SIP device >>>>>>>>>>> registrations. >>>>>>>>>>> Each >>>>>>>>>>> of those devices connects to it's perspective kamailio >>>>>>>>>>> server >>>>>>>>>>> >>>>>>>>>>> sip1.domain.com >>>>>>>>>>> sip2.domain.com >>>>>>>>>>> sip3.domain.com >>>>>>>>>>> >>>>>>>>>>> All 3 Kamailio servers share the same database, and users >>>>>>>>>>> can >>>>>>>>>>> use >>>>>>>>>>> their kamailio user/pwd on any of the devices, now I want to >>>>>>>>>>> use >>>>>>>>>>> encrypted passwords and remove clear text passwords from the >>>>>>>>>>> database. >>>>>>>>>>> I did test with one server and all is fine,however if a user >>>>>>>>>>> want >>>>>>>>>>> to >>>>>>>>>>> register from the second kamailio server it does not work, >>>>>>>>>>> basically >>>>>>>>>>> because the db domain entry from which the hash is created >>>>>>>>>>> is >>>>>>>>>>> sip1.domain.com and stored in the db, while the user >>>>>>>>>>> connects >>>>>>>>>>> from >>>>>>>>>>> to >>>>>>>>>>> sip2.domain.com this eventually generates a different hash. >>>>>>>>>>> >>>>>>>>>>> Is there anyway to overcome this ? Can I exclude Domain from >>>>>>>>>>> Hash >>>>>>>>>>> generation ? Any other option that allows me to do the above >>>>>>>>>>> ? >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> -- >>>>>>>>> Daniel-Constantin Mierla -- http://www.asipto.com >>>>>>>>> http://linkedin.com/in/miconda -- http://twitter.com/miconda >>>>>>>>> >>>>>>>> -- >>>>>>>> Daniel-Constantin Mierla -- http://www.asipto.com >>>>>>>> http://linkedin.com/in/miconda -- http://twitter.com/miconda >>>>>> >>>>>> >>>>>> >>>>> -- >>>>> Daniel-Constantin Mierla -- http://www.asipto.com >>>>> http://linkedin.com/in/miconda -- http://twitter.com/miconda >>>>> >>> -- >>> Daniel-Constantin Mierla -- http://www.asipto.com >>> http://linkedin.com/in/miconda -- http://twitter.com/miconda >>> > -- > Daniel-Constantin Mierla -- http://www.asipto.com > http://linkedin.com/in/miconda -- http://twitter.com/miconda >
-- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda
-- Ali Jawad Information Systems Manager Splendor Telecom (www.splendor.net) Beirut, Lebanon Phone: +9611373725/ext 116 FAX: +9611375554
-- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda
-- Ali Jawad Information Systems Manager Splendor Telecom (www.splendor.net) Beirut, Lebanon Phone: +9611373725/ext 116 FAX: +9611375554
Hello,
you haven't run 'bt' command inside the gdb. Do that and send the output.
Cheers, Daniel
On 1/4/12 9:54 AM, Ali Jawad wrote:
Hi Daniel Back-trace below, regards.
[root@kam-rtp-100-51 kamailio]# gdb /usr/local/kamailio/sbin/kamailio /core.18024GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-37.el5)Copyright (C) 2009 Free Software Foundation, Inc.License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.htmlThis is free software: you are free to change and redistribute it.There is NO WARRANTY, to the extent permitted by law. Type "show copying"and "show warranty" for details.This GDB was configured as "i386-redhat-linux-gnu".For bug reporting instructions, please see:http://www.gnu.org/software/gdb/bugs/...Reading symbols from /usr/local/kamailio/sbin/kamailio...done.[New Thread 18024]Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done.Loaded symbols for /lib/libdl.so.2Reading symbols from /lib/libresolv.so.2...(no debugging symbols found)...done.Loaded symbols for /lib/libresolv.so.2Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.Loaded symbols for /lib/libc.so.6Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.Loaded symbols for /lib/ld-linux.so.2Reading symbols from /usr/local/kamailio/lib/kamailio/modules/db_mysql.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules/db_mysql.soReading symbols from /usr/lib/mysql/libmysqlclient.so.15...(no debugging symbols found)...done.Loaded symbols for /usr/lib/mysql/libmysqlclient.so.15Reading symbols from /lib/libz.so.1...(no debugging symbols found)...done.Loaded symbols for /lib/libz.so.1Reading symbols from /lib/libcrypt.so.1...(no debugging symbols found)...done.Loaded symbols for /lib/libcrypt.so.1Reading symbols from /lib/libnsl.so.1...(no debugging symbols found)...done.Loaded symbols for /lib/libnsl.so.1Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done.Loaded symbols for /lib/libm.so.6Reading symbols from /lib/libssl.so.6...(no debugging symbols found)...done.Loaded symbols for /lib/libssl.so.6Reading symbols from /lib/libcrypto.so.6...(no debugging symbols found)...done.Loaded symbols for /lib/libcrypto.so.6Reading symbols from /usr/local/kamailio/lib/kamailio/libsrdb2.so.1...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/libsrdb2.so.1Reading symbols from /usr/local/kamailio/lib/kamailio/libsrdb1.so.1...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/libsrdb1.so.1Reading symbols from /usr/lib/libgssapi_krb5.so.2...(no debugging symbols found)...done.Loaded symbols for /usr/lib/libgssapi_krb5.so.2Reading symbols from /usr/lib/libkrb5.so.3...(no debugging symbols found)...done.Loaded symbols for /usr/lib/libkrb5.so.3Reading symbols from /lib/libcom_err.so.2...(no debugging symbols found)...done.Loaded symbols for /lib/libcom_err.so.2Reading symbols from /usr/lib/libk5crypto.so.3...(no debugging symbols found)...done.Loaded symbols for /usr/lib/libk5crypto.so.3Reading symbols from /usr/lib/libkrb5support.so.0...(no debugging symbols found)...done.Loaded symbols for /usr/lib/libkrb5support.so.0Reading symbols from /lib/libkeyutils.so.1...(no debugging symbols found)...done.Loaded symbols for /lib/libkeyutils.so.1Reading symbols from /lib/libselinux.so.1...(no debugging symbols found)...done.Loaded symbols for /lib/libselinux.so.1Reading symbols from /lib/libsepol.so.1...(no debugging symbols found)...done.Loaded symbols for /lib/libsepol.so.1Reading symbols from /usr/local/kamailio/lib/kamailio/modules_k/exec.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules_k/exec.soReading symbols from /usr/local/kamailio/lib/kamailio/modules_k/group.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules_k/group.soReading symbols from /usr/local/kamailio/lib/kamailio/libkcore.so.1...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/libkcore.so.1Reading symbols from /usr/local/kamailio/lib/kamailio/modules_k/speeddial.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules_k/speeddial.soReading symbols from /usr/local/kamailio/lib/kamailio/modules/carrierroute.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules/carrierroute.soReading symbols from /usr/lib/libconfuse.so.0...(no debugging symbols found)...done.Loaded symbols for /usr/lib/libconfuse.so.0Reading symbols from /usr/local/kamailio/lib/kamailio/libtrie.so.1...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/libtrie.so.1Reading symbols from /usr/local/kamailio/lib/kamailio/libkmi.so.1...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/libkmi.so.1Reading symbols from /usr/local/kamailio/lib/kamailio/modules_k/mi_fifo.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules_k/mi_fifo.soReading symbols from /usr/local/kamailio/lib/kamailio/modules_k/kex.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules_k/kex.soReading symbols from /usr/local/kamailio/lib/kamailio/modules/tm.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules/tm.soReading symbols from /usr/local/kamailio/lib/kamailio/modules_k/tmx.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules_k/tmx.soReading symbols from /usr/local/kamailio/lib/kamailio/modules/sl.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules/sl.soReading symbols from /usr/local/kamailio/lib/kamailio/modules_k/rr.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules_k/rr.soReading symbols from /usr/local/kamailio/lib/kamailio/modules_k/pv.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules_k/pv.soReading symbols from /usr/local/kamailio/lib/kamailio/modules_k/maxfwd.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules_k/maxfwd.soReading symbols from /usr/local/kamailio/lib/kamailio/modules_k/usrloc.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules_k/usrloc.soReading symbols from /usr/local/kamailio/lib/kamailio/modules_k/registrar.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules_k/registrar.soReading symbols from /usr/local/kamailio/lib/kamailio/modules_k/textops.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules_k/textops.soReading symbols from /usr/local/kamailio/lib/kamailio/modules_k/siputils.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules_k/siputils.soReading symbols from /usr/local/kamailio/lib/kamailio/modules_k/xlog.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules_k/xlog.soReading symbols from /usr/local/kamailio/lib/kamailio/modules/sanity.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules/sanity.soReading symbols from /usr/local/kamailio/lib/kamailio/modules/ctl.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules/ctl.soReading symbols from /usr/local/kamailio/lib/kamailio/modules/mi_rpc.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules/mi_rpc.soReading symbols from /usr/local/kamailio/lib/kamailio/modules_k/acc.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules_k/acc.soReading symbols from /usr/local/kamailio/lib/kamailio/modules/auth.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules/auth.soReading symbols from /usr/local/kamailio/lib/kamailio/modules_k/auth_db.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules_k/auth_db.soReading symbols from /usr/local/kamailio/lib/kamailio/modules_k/alias_db.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules_k/alias_db.soReading symbols from /usr/local/kamailio/lib/kamailio/modules_k/nathelper.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules_k/nathelper.soReading symbols from /usr/local/kamailio/lib/kamailio/modules/rtpproxy.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules/rtpproxy.soReading symbols from /usr/local/kamailio/lib/kamailio/modules/tls.so...done.Loaded symbols for /usr/local/kamailio/lib/kamailio/modules/tls.soReading symbols from /lib/libnss_files.so.2...(no debugging symbols found)...done.Loaded symbols for /lib/libnss_files.so.2Core was generated by `./sbin/kamailio ./etc/kamailio/kamailio.cfg'.Program terminated with signal 11, Segmentation fault.#0 0x080b51a4 in U_MD5Update (context=0xbfd1a7b4, input=0x74756100<Address 0x74756100 out of bounds>, inputLen=1650745192) at md5.c:160160 memcpy(gdb)
On Wed, Jan 4, 2012 at 10:48 AM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
can you get the backtrace? Locate the core file (perhaps in / directory if you don't use -w command line parameter) and do:
gdb /path/to/kamailio /path/to/corefile bt
Cheers, Daniel
On 1/4/12 9:17 AM, Ali Jawad wrote:
Hi When I did set modparam("auth_db", "calculate_ha1", 0 )
Kamailio is crashing see
Regards
On Tue, Jan 3, 2012 at 11:54 PM, Ali Jawadali.jawad@splendor.net wrote:
Hi It fetches one value from the database to compare it against a second value that has to be computed right, in the computation of the second hash where is the domain part fetched from ? Regards
On Wed, Jan 4, 2012 at 12:26 AM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
On 1/3/12 10:08 PM, Ali Jawad wrote:
Hi
In Xlite/eyebeam I put in the username and one of my 3 kamailio servers respectively as the sip registrar, I.e. register1.domain.com, register2.domain.com and register3.domain.com, that is why I was saying that hashing will create different hashes based on the register domain. With reference to my first related post, one kamailio server is for softphones, one for sip devices and one for mobile phones with SIP software. Each server has a slightly different NAT and Call routing structure.
but your service domain is 'domain.com', specific server addresses (domains) per UA type should be set as outbound proxy on the UA devices.
This is why I wanted to eliminate the domain factor from the hashing procedure, I am sure it chooses the right value from the DB value because it is the same value shown in the log of kamailio against which a comparison is being done and because it works if I put register.domain.com in the domain column rehash the HA! value of the db.
When auth_db module is configured to take the hashed value from database (calculate_ha1 parameter is 0), there is no more computation of it in kamailio -- it is just fetched from database and used -- so it does not matter anymore the domains in the sip message.
Check to see if the xlite does not have a realm field that has to be set properly.
>>>>> values at 0xb7b78dac >>>>>> 5(18649) DEBUG:<core> [db_val.c:117]: converting STRING >>>>>> [6f966cd9c628f14cdc20172f96a4d065]<====##### This is the value in >>>>>> the DB based on domain.com >>>>>> 5(18649) DEBUG: auth [api.c:210]: check_response: Our result = >>>>>> '6f95e6235edca0b7765042ef119fd83b'<====##### This value appears >>>>>> to >>>>>> be the value generated register.domain.com >>>>>> 5(18649) DEBUG: auth [api.c:220]: check_response: Authorization How can I enable the SQL query log ?
I don't know by hart, googling should help you.
Cheers, Daniel
On Tue, Jan 3, 2012 at 8:12 PM, Daniel-Constantin Mierla miconda@gmail.com wrote: > Hello, > > why are you using register.domain.com as domain for registration? > Isn't > domain.com the right one? > > Can you enable the sql query log for mysql server and double check if > the > right value (column) is selected from the database table? > > Cheers, > Daniel > > > On 1/3/12 5:13 PM, Ali Jawad wrote: >> Hi >> Please see the below, thanks ! >> >> interface: eth1 (xx.xx.xx.0/255.255.255.0) >> match: support1 >> >> U +6.698682 yy.yy.yy.146:18832 -> xx.xx.xx.51:5060 >> REGISTER sip:register.domain.com SIP/2.0. >> Via: SIP/2.0/UDP >> >> >> >> 192.168.0.191:18832;branch=z9hG4bK-d8754z-05164a466600837d-1---d8754z-;rport. >> Max-Forwards: 70. >> >> >> >> Contact:sip:support1@192.168.0.191:18832;rinstance=f8e37e314657e0d7;transport=udp. >> To: "Test Ast"sip:support1@register.domain.com. >> From: "Test Ast"sip:support1@register.domain.com;tag=f710b930. >> Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY.. >> CSeq: 1 REGISTER. >> Expires: 3600. >> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, >> SUBSCRIBE, INFO. >> User-Agent: eyeBeam release 1102q stamp 51814. >> Content-Length: 0. >> . >> >> >> U +0.005245 xx.xx.xx.51:5060 -> yy.yy.yy.146:18832 >> SIP/2.0 401 Unauthorized. >> Via: SIP/2.0/UDP >> >> >> >> 192.168.0.191:18832;branch=z9hG4bK-d8754z-05164a466600837d-1---d8754z-;rport=18832;received=yy.yy.yy.146. >> To: "Test >> >> >> Ast"sip:support1@register.domain.com;tag=e597ca73bdb255490f0cefa03b2fda82.3053. >> From: "Test Ast"sip:support1@register.domain.com;tag=f710b930. >> Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY.. >> CSeq: 1 REGISTER. >> WWW-Authenticate: Digest realm="domain.com", >> nonce="TwMpUE8DKCSt/IP7jcNRMbCT4TnbqlHl". >> Server: kamailio (3.2.1 (i386/linux)). >> Content-Length: 0. >> . >> >> >> U +0.428042 yy.yy.yy.146:18832 -> xx.xx.xx.51:5060 >> REGISTER sip:register.domain.com SIP/2.0. >> Via: SIP/2.0/UDP >> >> >> >> 192.168.0.191:18832;branch=z9hG4bK-d8754z-fc633b21627dca6d-1---d8754z-;rport. >> Max-Forwards: 70. >> >> >> >> Contact:sip:support1@192.168.0.191:18832;rinstance=f8e37e314657e0d7;transport=udp. >> To: "Test Ast"sip:support1@register.domain.com. >> From: "Test Ast"sip:support1@register.domain.com;tag=f710b930. >> Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY.. >> CSeq: 2 REGISTER. >> Expires: 3600. >> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, >> SUBSCRIBE, INFO. >> User-Agent: eyeBeam release 1102q stamp 51814. >> Authorization: Digest >> >> >> >> username="support1",realm="domain.com",nonce="TwMpUE8DKCSt/IP7jcNRMbCT4TnbqlHl",uri="sip:register.domain.com",response="6122245b77e2df0b90179304464341e7",algorithm=MD5. >> Content-Length: 0. >> . >> >> >> U +0.005146 xx.xx.xx.51:5060 -> yy.yy.yy.146:18832 >> SIP/2.0 401 Unauthorized. >> Via: SIP/2.0/UDP >> >> >> >> 192.168.0.191:18832;branch=z9hG4bK-d8754z-fc633b21627dca6d-1---d8754z-;rport=18832;received=yy.yy.yy.146. >> To: "Test >> >> >> Ast"sip:support1@register.domain.com;tag=e597ca73bdb255490f0cefa03b2fda82.fce3. >> From: "Test Ast"sip:support1@register.domain.com;tag=f710b930. >> Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY.. >> CSeq: 2 REGISTER. >> WWW-Authenticate: Digest realm="domain.com", >> nonce="TwMpUE8DKCSt/IP7jcNRMbCT4TnbqlHl". >> Server: kamailio (3.2.1 (i386/linux)). >> Content-Length: 0. >> . >> >> [root@kam-rtp-100-51 mysql]# mail alijawad1@gmail.com< >> output.txt >> [root@kam-rtp-100-51 mysql]# ngrep -W byline -T support1 -q -d eth1 >> interface: eth1 (xx.xx.xx.0/255.255.255.0) >> match: support1 >> >> >> >> >> U +5.321505 yy.yy.yy.146:63610 -> xx.xx.xx.51:5060 >> REGISTER sip:register.domain.com SIP/2.0. >> Via: SIP/2.0/UDP >> >> >> >> 192.168.0.191:63610;branch=z9hG4bK-d8754z-fb28723daa3f772d-1---d8754z-;rport. >> Max-Forwards: 70. >> >> >> >> Contact:sip:support1@192.168.0.191:63610;rinstance=782b19a2fccc665f;transport=udp. >> To: "Test Ast"sip:support1@register.domain.com. >> From: "Test Ast"sip:support1@register.domain.com;tag=ba705453. >> Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI.. >> CSeq: 1 REGISTER. >> Expires: 3600. >> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, >> SUBSCRIBE, INFO. >> User-Agent: eyeBeam release 1102q stamp 51814. >> Content-Length: 0. >> . >> >> >> U +0.004782 xx.xx.xx.51:5060 -> yy.yy.yy.146:63610 >> SIP/2.0 401 Unauthorized. >> Via: SIP/2.0/UDP >> >> >> >> 192.168.0.191:63610;branch=z9hG4bK-d8754z-fb28723daa3f772d-1---d8754z-;rport=63610;received=yy.yy.yy.146. >> To: "Test >> >> >> Ast"sip:support1@register.domain.com;tag=e597ca73bdb255490f0cefa03b2fda82.6b98. >> From: "Test Ast"sip:support1@register.domain.com;tag=ba705453. >> Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI.. >> CSeq: 1 REGISTER. >> WWW-Authenticate: Digest realm="domain.com", >> nonce="TwMpsU8DKIX4lvWDwPsV4iUhCl+iOAdk". >> Server: kamailio (3.2.1 (i386/linux)). >> Content-Length: 0. >> . >> >> >> U +0.400706 yy.yy.yy.146:63610 -> xx.xx.xx.51:5060 >> REGISTER sip:register.domain.com SIP/2.0. >> Via: SIP/2.0/UDP >> >> >> >> 192.168.0.191:63610;branch=z9hG4bK-d8754z-81517d296225234f-1---d8754z-;rport. >> Max-Forwards: 70. >> >> >> >> Contact:sip:support1@192.168.0.191:63610;rinstance=782b19a2fccc665f;transport=udp. >> To: "Test Ast"sip:support1@register.domain.com. >> From: "Test Ast"sip:support1@register.domain.com;tag=ba705453. >> Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI.. >> CSeq: 2 REGISTER. >> Expires: 3600. >> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, >> SUBSCRIBE, INFO. >> User-Agent: eyeBeam release 1102q stamp 51814. >> Authorization: Digest >> >> >> >> username="support1",realm="domain.com",nonce="TwMpsU8DKIX4lvWDwPsV4iUhCl+iOAdk",uri="sip:register.domain.com",response="4bfd80b0b836c20b748ee19a1c886284",algorithm=MD5. >> Content-Length: 0. >> . >> >> >> U +0.005302 xx.xx.xx.51:5060 -> yy.yy.yy.146:63610 >> SIP/2.0 401 Unauthorized. >> Via: SIP/2.0/UDP >> >> >> >> 192.168.0.191:63610;branch=z9hG4bK-d8754z-81517d296225234f-1---d8754z-;rport=63610;received=yy.yy.yy.146. >> To: "Test >> >> >> Ast"sip:support1@register.domain.com;tag=e597ca73bdb255490f0cefa03b2fda82.2f76. >> From: "Test Ast"sip:support1@register.domain.com;tag=ba705453. >> Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI.. >> CSeq: 2 REGISTER. >> WWW-Authenticate: Digest realm="domain.com", >> nonce="TwMpsU8DKIX4lvWDwPsV4iUhCl+iOAdk". >> Server: kamailio (3.2.1 (i386/linux)). >> Content-Length: 0. >> . >> >> On Tue, Jan 3, 2012 at 6:08 PM, Daniel-Constantin Mierla >> miconda@gmail.com wrote: >>> Hello, >>> >>> I need the entire flow for registration, including the 401 reply and >>> the >>> following REGISTER request. >>> >>> Cheers, >>> Daniel >>> >>> >>> On 1/3/12 5:02 PM, Ali Jawad wrote: >>>> Hi >>>> Please see the ngrep below, please note that if I use in the db >>>> register.domain.com and generate a hash against it for HA1 it >>>> works,but then the user cant logon to register2.domain.com >>>> >>>> >>>> U +10.630576 xx.yy.yy.yy:20020 -> xx.xx.xx.xx:5060 >>>> REGISTER sip:register.domain SIP/2.0. >>>> Via: SIP/2.0/UDP >>>> >>>> >>>> >>>> >>>> 192.168.0.191:20020;branch=z9hG4bK-d8754z-af65a442980c375f-1---d8754z-;rport. >>>> Max-Forwards: 70. >>>> >>>> >>>> >>>> >>>> Contact:sip:support1@192.168.0.191:20020;rinstance=4009190a4e109ac6;transport=udp. >>>> To: "Test Ast"sip:support1@register.domain. >>>> From: "Test Ast"sip:support1@register.domain;tag=976bb004. >>>> Call-ID: MDFmZDU2ZTI2YjJjMGNlMGFmOTIzMWFmZGQ1ZTNjMDE.. >>>> CSeq: 1 REGISTER. >>>> Expires: 3600. >>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, >>>> SUBSCRIBE, INFO. >>>> User-Agent: eyeBeam release 1102q stamp 51814. >>>> Content-Length: 0. >>>> >>>> On Tue, Jan 3, 2012 at 5:58 PM, Daniel-Constantin Mierla >>>> miconda@gmail.com wrote: >>>>> Hello, >>>>> >>>>> >>>>> On 1/3/12 4:48 PM, Ali Jawad wrote: >>>>>> Hi Daniel >>>>>> >>>>>> Please see >>>>>> >>>>>> 5(18649) DEBUG:<core> [db_res.c:184]: allocate 8 bytes >>>>>> for >>>>>> rows >>>>>> at >>>>>> 0xb7b78d74 >>>>>> 5(18649) DEBUG:<core> [db_row.c:119]: allocate 20 bytes >>>>>> for >>>>>> row >>>>>> values at 0xb7b78dac >>>>>> 5(18649) DEBUG:<core> [db_val.c:117]: converting STRING >>>>>> [6f966cd9c628f14cdc20172f96a4d065] >>>>>> 5(18649) DEBUG: auth [api.c:210]: check_response: Our result = >>>>>> '6f95e6235edca0b7765042ef119fd83b' >>>>>> 5(18649) DEBUG: auth [api.c:220]: check_response: Authorization >>>>>> failed >>>>>> 5(18649) DEBUG:<core> [db_res.c:81]: freeing 1 columns >>>>>> 5(18649) DEBUG:<core> [db_res.c:85]: freeing >>>>>> RES_NAMES[0] at >>>>>> 0xb7b78d3c >>>>>> 5(18649) DEBUG:<core> [db_res.c:94]: freeing result >>>>>> names at >>>>>> 0xb7b78bfc >>>>>> 5(18649) DEBUG:<core> [db_res.c:99]: freeing result >>>>>> types at >>>>>> 0xb7b78c64 >>>>>> 5(18649) DEBUG:<core> [db_res.c:54]: freeing 1 rows >>>>>> 5(18649) DEBUG:<core> [db_row.c:97]: freeing row values >>>>>> at >>>>>> 0xb7b78dac >>>>>> 5(18649) DEBUG:<core> [db_res.c:62]: freeing rows at >>>>>> 0xb7b78d74 >>>>>> 5(18649) DEBUG:<core> [db_res.c:136]: freeing result >>>>>> set at >>>>>> 0xb7b78bb0 >>>>>> 5(18649) DEBUG: auth [challenge.c:102]: build_challenge_hf: >>>>>> realm='nymgo.com' >>>>>> 5(18649) DEBUG: auth [challenge.c:244]: auth: 'WWW-Authenticate: >>>>>> Digest realm="domain.com", >>>>>> nonce="TwMcuk8DG47SLxatlNdZfyfR8p3OiyAE" >>>>>> ' >>>>>> >>>>>> I rebuilt the hashes against domain.com and then tried to connect >>>>>> to >>>>>> sip1.domain.com and sip2.domain.com and sip3.domain.com with all >>>>>> of >>>>>> the having >>>>>> >>>>>> >>>>>> # ----- auth_db params ----- >>>>>> #!ifdef WITH_AUTH >>>>>> modparam("auth_db", "db_url", DBURL) >>>>>> modparam("auth_db", "calculate_ha1", 0 ) >>>>>> modparam("auth_db", "password_column", "ha1") >>>>>> modparam("auth_db", "load_credentials", "") >>>>>> modparam("auth_db", "use_domain", MULTIDOMAIN) >>>>>> >>>>>> And in the routing process : >>>>>> >>>>>> if (!www_authorize("domain.com", "subscriber")) >>>>>> { >>>>>> >>>>>> www_challenge("domain.com", "0"); >>>>>> exit; >>>>>> } >>>>>> >>>>>> >>>>>> +++++++++++++ >>>>>> >>>>>> My point is that the hashes are caculated from user:doman:pwd >>>>>> which >>>>>> are extracted from the SIP packet and in this case the domains >>>>>> are >>>>>> sip1,sip2,sip3 while the hashes stored in the database are >>>>>> generated >>>>>> against domain.com >>>>>> >>>>>> If " ha1 is actually hash over 'user:realm:pwd' " shouldn't I >>>>>> have >>>>>> to >>>>>> set the domain/realm in the config file ? >>>>> >>>>> the first parameter in www_authorize and www_challenge functions >>>>> is >>>>> the >>>>> realm and it is used to build the digest response. >>>>> >>>>> Is your phone putting user@domain in authorization header? Can you >>>>> paste >>>>> here the ngrep of registration? >>>>> >>>>> Cheers, >>>>> Daniel >>>>> >>>>> >>>>>> I might be wrong....thanks for the help so far. >>>>>> >>>>>> Regards >>>>>> >>>>>> On Tue, Jan 3, 2012 at 5:15 PM, Daniel-Constantin Mierla >>>>>> miconda@gmail.com wrote: >>>>>>> Hello, >>>>>>> >>>>>>> >>>>>>> On 1/3/12 4:12 PM, Ali Jawad wrote: >>>>>>>> Hi Daniel >>>>>>>> This certainly makes sense, I will try it in a few mins, but >>>>>>>> what >>>>>>>> I >>>>>>>> observed at Debug Level 3 is that Hash is calculated before >>>>>>>> www_authenticate is executed and it shows HA comparison failed, >>>>>>>> if >>>>>>>> I >>>>>>>> do use domain.com instead of $fd and use $domain.com in db >>>>>>>> domain >>>>>>>> field and build HA1 filed based on that, wont Kamailio still >>>>>>>> try >>>>>>>> to >>>>>>>> build the HA1 hash which it will compare form user:domain:pwd >>>>>>>> where >>>>>>>> domain is fed in to the hash function from the header of the >>>>>>>> SIP >>>>>>>> packet ? >>>>>>> >>>>>>> the ha1 is actually hash over 'user:realm:pwd' -- it is just >>>>>>> common >>>>>>> practice >>>>>>> to use the domain as realm, since realm should be a unique token >>>>>>> to >>>>>>> identify >>>>>>> the service, but it can be any random string. realm is given as >>>>>>> parameter >>>>>>> to auth functions in kamailio.cfg >>>>>>> >>>>>>> Cheers, >>>>>>> Daniel >>>>>>> >>>>>>> >>>>>>>> Regards >>>>>>>> >>>>>>>> On Tue, Jan 3, 2012 at 5:07 PM, Daniel-Constantin Mierla >>>>>>>> miconda@gmail.com wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> you can simply use 'domain.com' as realm parameter to >>>>>>>>> authentication >>>>>>>>> function instead of $fd. Also build ha1 and ha1b with >>>>>>>>> domain.com >>>>>>>>> and >>>>>>>>> then >>>>>>>>> you are safe no matter which sip server is used. >>>>>>>>> >>>>>>>>> Of course you can build the realm by striping first token >>>>>>>>> before >>>>>>>>> '.' >>>>>>>>> in >>>>>>>>> $fd >>>>>>>>> and pass it to authentication functions, but not sure if makes >>>>>>>>> sense >>>>>>>>> since >>>>>>>>> it should be always domain.com >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Daniel >>>>>>>>> >>>>>>>>> >>>>>>>>> On 1/3/12 3:15 PM, Ali Jawad wrote: >>>>>>>>>> Hi >>>>>>>>>> After some research it seems to me that the only way to >>>>>>>>>> achieve >>>>>>>>>> this >>>>>>>>>> is to "try" and change how hashing is done in the source >>>>>>>>>> code, a >>>>>>>>>> little bit too ambitious for me, and it means I will have >>>>>>>>>> loads >>>>>>>>>> of >>>>>>>>>> problems each time an upgrade is released. >>>>>>>>>> >>>>>>>>>> Or >>>>>>>>>> >>>>>>>>>> Use pseudovariables to fix the value of the $fd value to >>>>>>>>>> something >>>>>>>>>> constant, while this worked for values like $var(y) I was not >>>>>>>>>> able >>>>>>>>>> to >>>>>>>>>> assign/strip $fd to remove the subdomain part. >>>>>>>>>> >>>>>>>>>> Any input please ? >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> >>>>>>>>>> On Tue, Jan 3, 2012 at 2:06 PM, Ali >>>>>>>>>> Jawadali.jawad@splendor.net >>>>>>>>>> wrote: >>>>>>>>>>> Hi >>>>>>>>>>> I do have 3 Kamailio servers, one for mobile phone >>>>>>>>>>> registrations, >>>>>>>>>>> one >>>>>>>>>>> for softphone registrations and one for SIP device >>>>>>>>>>> registrations. >>>>>>>>>>> Each >>>>>>>>>>> of those devices connects to it's perspective kamailio >>>>>>>>>>> server >>>>>>>>>>> >>>>>>>>>>> sip1.domain.com >>>>>>>>>>> sip2.domain.com >>>>>>>>>>> sip3.domain.com >>>>>>>>>>> >>>>>>>>>>> All 3 Kamailio servers share the same database, and users >>>>>>>>>>> can >>>>>>>>>>> use >>>>>>>>>>> their kamailio user/pwd on any of the devices, now I want to >>>>>>>>>>> use >>>>>>>>>>> encrypted passwords and remove clear text passwords from the >>>>>>>>>>> database. >>>>>>>>>>> I did test with one server and all is fine,however if a user >>>>>>>>>>> want >>>>>>>>>>> to >>>>>>>>>>> register from the second kamailio server it does not work, >>>>>>>>>>> basically >>>>>>>>>>> because the db domain entry from which the hash is created >>>>>>>>>>> is >>>>>>>>>>> sip1.domain.com and stored in the db, while the user >>>>>>>>>>> connects >>>>>>>>>>> from >>>>>>>>>>> to >>>>>>>>>>> sip2.domain.com this eventually generates a different hash. >>>>>>>>>>> >>>>>>>>>>> Is there anyway to overcome this ? Can I exclude Domain from >>>>>>>>>>> Hash >>>>>>>>>>> generation ? Any other option that allows me to do the above >>>>>>>>>>> ? >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>> >>>>>>>>>> >>>>>>>>> -- >>>>>>>>> Daniel-Constantin Mierla -- http://www.asipto.com >>>>>>>>> http://linkedin.com/in/miconda -- http://twitter.com/miconda >>>>>>>>> >>>>>>>> -- >>>>>>>> Daniel-Constantin Mierla -- http://www.asipto.com >>>>>>>> http://linkedin.com/in/miconda -- http://twitter.com/miconda >>>>>> >>>>>> >>>>> -- >>>>> Daniel-Constantin Mierla -- http://www.asipto.com >>>>> http://linkedin.com/in/miconda -- http://twitter.com/miconda >>>>> >>> -- >>> Daniel-Constantin Mierla -- http://www.asipto.com >>> http://linkedin.com/in/miconda -- http://twitter.com/miconda >>> > -- > Daniel-Constantin Mierla -- http://www.asipto.com > http://linkedin.com/in/miconda -- http://twitter.com/miconda >
-- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda
-- Ali Jawad Information Systems Manager Splendor Telecom (www.splendor.net) Beirut, Lebanon Phone: +9611373725/ext 116 FAX: +9611375554
-- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda
-- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda
-
Ali Jawad -
Daniel-Constantin Mierla