RE: How to handle non digest messeg if Auth-Type is set to Digest?

2006-07-28 Thread GlobeInPhotos
  No.  It is IMPOSSIBLE for Auth-Type to be in a RADIUS packet.


I've commented line in users file

#DEFAULT Auth-Type := Digest

But now I've got following message if non-digest message arrive:

rad_recv: Access-Request packet from host 153.19.130.250:46963, id=190,
length=80
User-Name = [EMAIL PROTECTED]
Service-Type = SIP-Callee-AVPs
NAS-Port = 0
NAS-IP-Address = 153.19.130.250

[cut]

auth: type Local
auth: No User-Password or CHAP-Password attribute in the request
auth: Failed to validate the user.
Login incorrect: [EMAIL PROTECTED]/no User-Password
attribute] (from client server1
port 0)
Sending Access-Reject of id 190 to 153.19.130.250 port 46963

and probably there is no user-password in request but we cannot add this
field to request in openser :(

Michal


-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.10.4/401 - Release Date: 2006-07-26
 

- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


How to handle non digest messeg if Auth-Type is set to Digest?

2006-07-27 Thread GlobeInPhotos
Hi
My Freeradius has to receive and process digest and non-digest message but
when freeradius  receives and process  nondigest message (I have only one
such message) I've got message:


ERROR: You set 'Auth-Type = Digest' for a request that did not contain any
digest attributes!
  modcall[authenticate]: module digest returns invalid for request 1
modcall: leaving group authenticate (returns invalid) for request 1


and I cannot return attributes in reply message.

What should I do to process this message without ERROR ?

Full log bellow:

User-Name = [EMAIL PROTECTED]
Service-Type = SIP-Callee-AVPs
NAS-Port = 0
NAS-IP-Address = 153.19.130.250
  Processing the authorize section of radiusd.conf
modcall: entering group authorize for request 1
  modcall[authorize]: module preprocess returns ok for request 1
  modcall[authorize]: module chap returns noop for request 1
  modcall[authorize]: module digest returns noop for request 1
rlm_realm: Looking up realm server1.test.pl for User-Name =
[EMAIL PROTECTED]
rlm_realm: No such realm server1.test.pl
  modcall[authorize]: module suffix returns noop for request 1
  rlm_eap: No EAP-Message, not doing EAP
  modcall[authorize]: module eap returns noop for request 1
users: Matched entry DEFAULT at line 45
  modcall[authorize]: module files returns ok for request 1
radius_xlat:  '[EMAIL PROTECTED]'
rlm_sql (sql): sql_set_user escaped user --
'[EMAIL PROTECTED]'
radius_xlat:  'SELECT * FROM
test.authorize_check('SIP-Callee-AVPs','[EMAIL PROTECTED]'
)'
rlm_sql (sql): Reserving sql socket id: 2
rlm_sql_postgresql: query: SELECT * FROM
test.authorize_check('SIP-Callee-AVPs','[EMAIL PROTECTED]'
)
rlm_sql_postgresql: Status: PGRES_TUPLES_OK
rlm_sql_postgresql: affected rows =
radius_xlat:  '--authorize_group_check_query'
rlm_sql_postgresql: query: --authorize_group_check_query
rlm_sql_postgresql: Status: PGRES_EMPTY_QUERY
rlm_sql_postgresql: affected rows =
radius_xlat:  'SELECT * FROM
test.authorize_reply('SIP-Callee-AVPs','[EMAIL PROTECTED]'
, '', '' )'
rlm_sql_postgresql: query: SELECT * FROM
test.authorize_reply('SIP-Callee-AVPs','[EMAIL PROTECTED]'
, '', '' )
SQL statement SELECT  * FROM test.find_sip_account_info(  $1 ,  $2 ,  $3 )
rlm_sql_postgresql: Status: PGRES_TUPLES_OK
rlm_sql_postgresql: affected rows =
radius_xlat:  '--authorize_group_reply_query'
rlm_sql_postgresql: query: --authorize_group_reply_query
rlm_sql_postgresql: Status: PGRES_EMPTY_QUERY
rlm_sql_postgresql: affected rows =
rlm_sql (sql): Released sql socket id: 2
  modcall[authorize]: module sql returns ok for request 1
modcall: leaving group authorize (returns ok) for request 1
  rad_check_password:  Found Auth-Type Digest
auth: type digest
  Processing the authenticate section of radiusd.conf
modcall: entering group authenticate for request 1
ERROR: You set 'Auth-Type = Digest' for a request that did not contain any
digest attributes!
  modcall[authenticate]: module digest returns invalid for request 1
modcall: leaving group authenticate (returns invalid) for request 1
auth: Failed to validate the user.
Login incorrect: [EMAIL PROTECTED]/no User-Password
attribute] (from client server1 port 0)
Sending Access-Reject of id 162 to 153.19.130.250 port 45429

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.10.4/401 - Release Date: 2006-07-26
 

- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


RE: How to handle non digest messeg if Auth-Type is set to Digest?

2006-07-27 Thread GlobeInPhotos

  So the conclusion is that you set Auth-Type = Digest somewhere.

Probably OpenSer which is a sender set Auth-Type=Digest in request.

By the way is it possible to make workaround for such situation to be honest
I do not need authorize message but only I have to send some values to
OpenSer - this non-digest (which seems to be a digest) message is our
internal message. Or maybe it is a possibilities to accept this special
message which is digest but has no digest attributes?

Michal Szymanski

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.10.4/401 - Release Date: 2006-07-26
 

- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


RE: How to handle non digest messeg if Auth-Type is set to Digest?

2006-07-27 Thread GlobeInPhotos

 Go back and read the debug log.  Check your configuration.  YOU set
Auth-Type in YOUR configuration.

Are you talking about radius config?
In my config I have something like this.
authorize {
cut
Digest
cut
}

I can send 

  Stop arguing, and go check it.

For sure I'm not arguing but I'm trying to find solution to my problem :)

 I do not need authorize message but only I have to send some values to
 OpenSer - this non-digest (which seems to be a digest) message is our
 internal message. Or maybe it is a possibilities to accept this special
 message which is digest but has no digest attributes?

 That makes no sense to me.


Well, it makes sense :) After real digest message (INVITE request from
OpenSer), our script in OpenSer sends special request for extra processing.
This extra request is sent only in special situation. OpenSer can decide is
this special situation happen when it receives data after INVITE request. We
can sent all necessary data in reply for INVITE message but retrieving extra
data is processor expensive and that is why we retrieve data only when it is
really needed - using next nondigest request. I hope it is clear now.
What we implement it is not typical Voip solution that is why we need
special handling.

Michal Szymanski

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.10.4/401 - Release Date: 2006-07-26
 

- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


RE: How to handle non digest messeg if Auth-Type is set to Digest?

2006-07-27 Thread GlobeInPhotos
I have also this in 'user' file

DEFAULT Auth-Type := Digest

Michal

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
g] On Behalf Of Alan DeKok
Sent: Friday, July 28, 2006 12:39 AM
To: FreeRadius users mailing list
Subject: Re: How to handle non digest messeg if Auth-Type is set to Digest? 

GlobeInPhotos [EMAIL PROTECTED] wrote:
   So the conclusion is that you set Auth-Type = Digest somewhere.
 
 Probably OpenSer which is a sender set Auth-Type=Digest in request.

  No.  It is IMPOSSIBLE for Auth-Type to be in a RADIUS packet.

 Go back and read the debug log.  Check your configuration.  YOU set
Auth-Type in YOUR configuration.

  Stop arguing, and go check it.

 I do not need authorize message but only I have to send some values to
 OpenSer - this non-digest (which seems to be a digest) message is our
 internal message. Or maybe it is a possibilities to accept this special
 message which is digest but has no digest attributes?

  That makes no sense to me.

  Alan DeKok.
--
  http://deployingradius.com   - The web site of the book
  http://deployingradius.com/blog/ - The blog
- 
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html


-- 
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.10.4/401 - Release Date: 2006-07-26
 

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.10.4/401 - Release Date: 2006-07-26
 

- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html