Aleksandar Stojilkovic wrote:

Ok, I'm new one to this...

And Owwww.... Yellow dots are matter of personal taste... And owwwww, do everyone a favor - keep your opinion for yourself... I am trying to get some help here....

Follow the rules and you are more likely to get help: http://www.freeradius.org/list/users.html -- Dennis Skinner Systems Administrator BlueFrog Internet http://www.bluefrog.com

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 = "3_test001_+48580001@server1.test.pl" 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 = "3_test001_+48580001@server1.test.pl" 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: '3_test001_+48580001@server1.test.pl' rlm_sql (sql): sql_set_user escaped user --> '3_test001_+48580001@server1.test.pl' radius_xlat: 'SELECT * FROM test.authorize_check('SIP-Callee-AVPs','3_test001_+48580001@server1.test.pl' )' rlm_sql (sql): Reserving sql socket id: 2 rlm_sql_postgresql: query: SELECT * FROM test.authorize_check('SIP-Callee-AVPs','3_test001_+48580001@server1.test.pl' ) 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','3_test001_+48580001@server1.test.pl' , '', '' )' rlm_sql_postgresql: query: SELECT * FROM test.authorize_reply('SIP-Callee-AVPs','3_test001_+48580001@server1.test.pl' , '', '' ) 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: [3_test001_+48580001@server1.test.pl/<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

Sorry I wrote wrong. I do not set Auth-Type, simply in config I have set auth. Digest but beside digest message radius receives non digest message that I have to handle. I do not know why radius claims that it is digest message??? Maybe you know ? As I wrote before request was: rad_recv: Access-Request packet from host 153.19.130.250:45740, id=181, length=80 User-Name = "3_test001_+48580001@server1.test.pl" Service-Type = SIP-Callee-AVPs NAS-Port = 0 NAS-IP-Address = 153.19.130.250 And after: rad_check_password: Found Auth-Type Digest auth: type "digest" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 4 ERROR: You set 'Auth-Type = Digest' for a request that did not contain any digest attributes! modcall[authenticate]: module "digest" returns invalid for request 4 modcall: leaving group authenticate (returns invalid) for request 4 auth: Failed to validate the user. Login incorrect: [3_test001_+48580001@server1.test.pl/<no User-Password attribute>] (from client erver1 port 0) Sending Access-Reject of id 181 to 153.19.130.250 port 45740 -----Original Message----- From: freeradius-users-bounces+biuro=globeinphotos.com@lists.freeradius.org [mailto:freeradius-users-bounces+biuro=globeinphotos.com@lists.freeradius.or g] On Behalf Of Phil Mayers Sent: Thursday, July 27, 2006 10:18 PM To: FreeRadius users mailing list Subject: Re: How to handle non digest messeg if Auth-Type is set to Digest? Don't set Auth-Type = digest. In fact, don't set Auth-Type at all, except in the rare cases of Reject or Accept. The "digest" and other modules will (should) set the Auth-Type for themselves in the authorize section, and only do it if it *is* a digest (or other) request. - 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

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

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

I have also this in 'user' file DEFAULT Auth-Type := Digest Michal -----Original Message----- From: freeradius-users-bounces+biuro=globeinphotos.com@lists.freeradius.org [mailto:freeradius-users-bounces+biuro=globeinphotos.com@lists.freeradius.or 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" <biuro@globeinphotos.com> 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

GlobeInPhotos wrote:

I've commented line in users file

#DEFAULT Auth-Type := Digest

Finally. That line? That *was* you setting Auth-Type to 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 = "3_test001_+48580001@server1.test.pl" 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

Ok, so for these non-digest requests, you'll have to configure the server to authenticate them without a password being present. This is one of those rare cases where you *do* set auth-type. So, something like in radiusd.conf: authorize { preprocess # digest will set Auth-Type=Digest IF AND ONLY IF this # request is a real digest one digest files # maybe other modules } ...and in "users": # Since the Auth-Type = Accept is a conditional set, this # entry will NOT MATCH if the "digest" module has already # set Auth-Type=Digest # # Therefore, it should only match your "special" requests DEFAULT Service-Type==SIP-Callee-AVPs, Auth-Type = Accept VoIP-Attribute-1 = value1, Other-Attribute = otherval That is: If a request comes in with Service-Type == SIP-Callee-AVPs, then set Auth-Type to accept IF AND ONLY IF it isn't already set (= is conditional set; := which you were using earlier is unconditional set - see "man users"). Then set some attributes on the reply. You didn't show one of your other (the "real" digest) requests so I can't be sure what they look like, but something like the above should work.

Aleksandar Stojilkovic wrote:

...

Aleksandar Stojilkovic wrote:

...

Hello,

My log is full of this kind of errors:

Wed Jul 26 02:55:54 2006 : Error: Discarding duplicate request from client APMajur:2048 - ID: 27 due to unfinished request 11$ Don't post to the list in HTML. Awful HTML at that...

This is normally caused by a slowly-responding database (e.g. SQL, LDAP) or upstream proxy server. Make "the thing" respond quicker. Without more details as to your configuration, we can only guess, but maybe indices on key SQL tables and/or optimising the queries? -

Thanks. I suspected so I increased the timeout between requests on my NASes from 200ms to 600ms. Everything worked fine for 3 days and then again the same...

That won't solve the problem, and I'm not surprised it came back. You need to speed the backend up, not have the radius server wait longer.

Which computer configuration is recommended for my needs: Freeradius with Mysql for about 1000 users that connects to network using wireless connections?

Any reasonably modern computer e.g. ~1.6GHz >512Mb ram, reasonably fast disks to support the database, should be able to handle that load. It's likely a slowdown on the MySQL side. Some possibilities: 1. Are all your queries on tables which are indexed properly? 2. Are you periodically emptying or archiving old data from the accounting table? Because if not, the time to insert accounting entries will just go up and up as the table grows.