[SR-Users] Registration Authentication Error
Nathaniel L Keeling III
forums at akan.net
Sun Sep 30 21:30:44 CEST 2012
The sequence is not changing and the authorization header is not being
sent in the subsequent registrar request. This is why I can not
authenticate. My question would be why would this occurring?
Thanks
Nathaniel
On 9/28/12 1:57 AM, Moritz Graf wrote:
> Hi,
>
> I have not been that much in Kamailio yet, but I can see the following
> messages:
>
> UAC UAS
> REGISTER -----> (CSeq=1)
> 401 Unauth. <--
> REGISTER -----> (CSeq=1)
> 401 Unauth. <--
>
> I am missing the answer from the UAC where it solves the challange and
> sends another Register with CSeq=2.
> But maybe I just missunderstand the logfiles, so correct me if I'm wrong.
>
> greeetz moritz
>
>
> Am 27.09.2012 23:36, schrieb Nathaniel L Keeling III:
>> Sorry, I thought I had saved it in plain text format. I have included
>> the right file.
>>
>> Thanks
>>
>> Nathaniel
>>
>> On 9/27/12 10:12 AM, Daniel-Constantin Mierla wrote:
>>> Can you sent the attachment in text format so it can be read from any
>>> device? It should be just text content anyhow.
>>>
>>> Cheers,
>>> Daniel
>>>
>>> On 9/27/12 4:26 AM, Nathaniel L Keeling III wrote:
>>>> I am using the Jitsi sip client and tried the X-Lite sip client. I am
>>>> not able to authenticate with either. I am including a text with the
>>>> sip messages and some of kamailio logs.
>>>>
>>>> Thanks
>>>>
>>>> Nathaniel
>>>>
>>>> On 9/24/12 3:21 AM, Daniel-Constantin Mierla wrote:
>>>>> Hello,
>>>>>
>>>>> all seems ok from the logs, have you checked the realm in the
>>>>> authorization header, is it the right one? Maybe you can just paste
>>>>> the trace for a registration that fails.
>>>>>
>>>>> I can think of anything else that could go wrong, this part of the
>>>>> code is used a lot. I assume it is a well known user agent/phone
>>>>> that can't have a broken implementation.
>>>>>
>>>>> Cheers,
>>>>> Daniel
>>>>>
>>>>>
>>>>> On 9/21/12 10:43 PM, Nathaniel L Keeling III wrote:
>>>>>> here is the output from the log file of the test user:
>>>>>>
>>>>>> 2(2744) DEBUG: db_postgres [km_dbase.c:224]: sending query ok:
>>>>>> 10046f6d0 (7) - [select password from subscriber where
>>>>>> username='test' AND domain='akanvoice.com']
>>>>>> 2(2744) DEBUG: <core> [db_res.c:118]: allocate 48 bytes for result
>>>>>> set at 10049a018
>>>>>> 2(2744) DEBUG: db_postgres [km_dbase.c:521]: 10046f6d0
>>>>>> PQresultStatus(PGRES_TUPLES_OK) PQgetResult(1008b7e50)
>>>>>> 2(2744) DEBUG: db_postgres [km_res.c:108]: 1 columns returned from
>>>>>> the query
>>>>>> 2(2744) DEBUG: <core> [db_res.c:155]: allocate 8 bytes for result
>>>>>> names at 100499f28
>>>>>> 2(2744) DEBUG: <core> [db_res.c:165]: allocate 4 bytes for result
>>>>>> types at 100499f40
>>>>>> 2(2744) DEBUG: db_postgres [km_res.c:126]: allocate 16 bytes for
>>>>>> RES_NAMES[0] at 100499f58
>>>>>> 2(2744) DEBUG: db_postgres [km_res.c:133]:
>>>>>> RES_NAMES(100499f58)[0]=[password]
>>>>>> 2(2744) DEBUG: db_postgres [km_res.c:166]: use DB1_STRING result type
>>>>>> 2(2744) DEBUG: db_postgres [km_res.c:222]: allocate for 1 columns
>>>>>> 8 bytes in row buffer at 100499f78
>>>>>> 2(2744) DEBUG: <core> [db_res.c:184]: allocate 16 bytes for rows
>>>>>> at 100499f90
>>>>>> 2(2744) DEBUG: db_postgres [km_res.c:243]:
>>>>>> PQgetvalue(10046f6d0,0,0)=[test1234]
>>>>>> 2(2744) DEBUG: db_postgres [km_res.c:252]: [0][0]
>>>>>> Column[password]=[test1234]
>>>>>> 2(2744) DEBUG: <core> [db_row.c:119]: allocate 32 bytes for row
>>>>>> values at 100499fb0
>>>>>> 2(2744) DEBUG: <core> [db_val.c:117]: converting STRING [test1234]
>>>>>> 2(2744) DEBUG: <core> [db_val.c:127]: allocate 9 bytes memory for
>>>>>> STRING at 100499fe0 2(2744) DEBUG: db_postgres [km_res.c:267]:
>>>>>> freeing row buffer at 100499f78
>>>>>> 2(2744) DEBUG: db_postgres [km_dbase.c:393]: PQclear(1008b7e50)
>>>>>> result set
>>>>>> 2(2744) DEBUG: auth [api.c:211]: check_response: Our result =
>>>>>> '1793af7ca4c2a2feb31410fb6c113695'
>>>>>> 2(2744) DEBUG: auth [api.c:221]: check_response: Authorization failed
>>>>>> 2(2744) DEBUG: <core> [db_res.c:81]: freeing 1 columns
>>>>>> 2(2744) DEBUG: <core> [db_res.c:85]: freeing RES_NAMES[0] at
>>>>>> 100499f58
>>>>>> 2(2744) DEBUG: <core> [db_res.c:94]: freeing result names at
>>>>>> 100499f28
>>>>>> 2(2744) DEBUG: <core> [db_res.c:99]: freeing result types at
>>>>>> 100499f40
>>>>>> 2(2744) DEBUG: <core> [db_res.c:54]: freeing 1 rows
>>>>>> 2(2744) DEBUG: <core> [db_row.c:68]: free VAL_STRING[0] 'test1234'
>>>>>> at 100499fe0
>>>>>> 2(2744) DEBUG: <core> [db_row.c:97]: freeing row values at 100499fb0
>>>>>> 2(2744) DEBUG: <core> [db_res.c:62]: freeing rows at 100499f90
>>>>>> 2(2744) DEBUG: <core> [db_res.c:136]: freeing result set at 10049a018
>>>>>> 2(2744) ERROR: *** cfgtrace:
>>>>>> c=[/opt/kamailio-3.3/etc/kamailio/kamailio.cfg] l=730 a=27
>>>>>> n=auth_challenge
>>>>>> 2(2744) DEBUG: auth [challenge.c:128]: build_challenge_hf:
>>>>>> realm='akanvoice.com'
>>>>>> 2(2744) DEBUG: auth [challenge.c:270]: auth: 'WWW-Authenticate:
>>>>>> Digest realm="akanvoice.com", nonce="UFzRV1Bc0CunOjSLvAkebJwYzCBSBRYH"
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Nathaniel
>>>>>> On 9/21/12 8:15 AM, Daniel-Constantin Mierla wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> On 9/21/12 2:43 PM, Nathaniel L Keeling III wrote:
>>>>>>>> Yes, the password column of the subscriber's table contains the
>>>>>>>> plain text password. Should the calculated HA1 string match the
>>>>>>>> HA1 value in the database?
>>>>>>> no, if clear text password is used, the ha1 column is not
>>>>>>> important at all.
>>>>>>>
>>>>>>> If you work with default config, it's really strange, I tested and
>>>>>>> all goes fine. Can you add a temporary account with a simple
>>>>>>> username/password to be sure no typo can happen and test again?
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Daniel
>>>>>>> [...]
>
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120930/f47002aa/attachment.htm>
More information about the sr-users
mailing list