Re: radclient: problem with exit code 0 and 1
Hello, Alan DeKok wrote: I've committed a fix that will be in the next release of the server. If you need this functionality, upgrade. I tried your git repository as described on freeradius.org. I do not understand the versioning scheme, but I downloaded the fixed stable tree (upcoming 2.1.5?) and built it without 'make install' on my AMD64-Machine. The problem in radclient is fixed, thank you Alan! I just had to append the new dictionary path in my scripts, because the dictionaries of my old inst do not work with the new radclient: ./radclient -d /usr/local/src/radiusd/share -f /home/me/radpacket -x 192.168.X.X:1812 auth secret123 Thanks for your fast help! oz - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: radclient: problem with exit code 0 and 1
Hello, Alan DeKok wrote: oz wrote: for monitoring our radius-servers, I use radclient for a long time in a script. After migration to another platform, radclient seems to work else, than before. If a monitored radiusd is down or the Auth of my monitoring-user fails, radclient gets an expected answer, but exits with status 0 in these cases. Hmm... good point. I'll take a look at that. the normal behavior of radclient seems to get lost somewhere in the versions later than freeradius-0.7, where it worked: ... radclient: no response from server host1:/usr/local/src/freeradius-0.7/src/main# echo $? 1 ... with ./radclient -v radclient: $Id: radclient.c,v 1.46 2002/06/21 19:57:26 cparker Exp $ built on Nov 5 2002 at 09:31:53 And it fails with later versions like # radclient -v radclient: $Id: radclient.c,v 1.72.2.1.2.7 2007/04/07 22:22:51 aland Exp $ built on No v 16 2007 at 14:04:12 ... from freeradius-1.1.7 and ... radclient -v radclient: $Id: radclient.c,v 1.120 2008/04/03 13:43:12 aland Exp $ built on Jul 7 20 08 at 16:01:22 ... from freeradius-2.0.5: radclient -v radclient: $Id: radclient.c,v 1.120 2008/04/03 13:43:12 aland Exp $ built on Jul 7 20 08 at 16:01:22 Kind regards, oz I am running radclient from freeradius 1.1.3-3, Debian/etch amd64: # radclient -v radclient: $Id: radclient.c,v 1.72.2.1.2.5 2006/05/16 18:26:08 aland Exp $ built on Dec 17 2006 at 01:07:36 Err... that won't be fixed. The fix will be in a recent version of the server. Not one that is three years old. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: radclient: problem with exit code 0 and 1
Alan DeKok wrote: oz wrote: the normal behavior of radclient seems to get lost somewhere in the versions later than freeradius-0.7, where it worked: That's nice... but 1.1.x will NOT be fixed. I've committed a fix that will be in the next release of the server. If you need this functionality, upgrade. Thanks, but for some reasons I cannot do updates to the upcoming release on that server. So I compiled 0.7 this morning, just to get the radclient tool from that release. It was succesfully built, yeay, but has another bug with masking the password when it is used in the radtest-script :-/ Sending Access-Request of id 110 to 192.168.X.X:1812 User-Name = testuser User-Password = \360\213[p\224\212I\314\217\343\361\214\370\326\351$ Do you have an idea, which freeradius version after 0.7 has a working exit code 1, but is free from that other problem with the password-masking? Then I'd like to try that. Else I would have to test-compile the 19 releases between 0.7 and 1.1.7 for a possible workaround. oz - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: radclient: problem with exit code 0 and 1
Alan DeKok wrote: Uh... you *can* run just radclient from the new version of the server. You don't have to upgrade the server to run radclient. Yes, thanks, I built the latest 2.1.4 but it still has the bug: /usr/local/src/freeradius-server-2.1.4/src/main# ./radclient -d /usr/local/src/freeradius-server-2.1.4/share -f /home/me/radpacket -x 192.168.X.X:1812 auth secret123 Sending Access-Request of id 41 to 192.168.X.X port 1812 User-Name = testuser Password = testpassword NAS-IP-Address = 192.168.x.x NAS-Port = 10 ... radclient: no response from server for ID 41 socket 3 yoda:/usr/local/src/freeradius-server-2.1.4/src/main# echo $? 0 I just hope to find a workaround for my alarm-monitoring in using an old version, until a fixed version of freeradius is released. - Ok, now that I know, you will fix it, I can wait. Thanks for your help, oz - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: radclient: problem with exit code 0 and 1
t...@kalik.net wrote: from that release. It was succesfully built, yeay, but has another bug with masking the password when it is used in the radtest-script :-/ Sending Access-Request of id 110 to 192.168.X.X:1812 User-Name = testuser User-Password = \360\213[p\224\212I\314\217\343\361\214\370\326\351$ Not a bug. Shared secret is wrong. It looks like a wrong shared secret, ... usr/local/src/freeradius-0.9.2/src/main# ./radclient -d /usr/local/src/freeradius-0.9.2/share -f /home/me/radpacket -x 192.168.111.18:1812 auth test123 Sending Access-Request of id 20 to 192.168.111.18:1812 User-Name = testuser Password = testpassword NAS-IP-Address = pluto NAS-Port = 10 rad_recv: Access-Reject packet from host 192.168.111.18:1812, id=20, length=20 rad_decode: Received Access-Reject packet from 192.168.111.18 with invalid signature (err=2)! (Shared secret is incorrect.) ... but it is not wrong, I used the same secret as on 2.1.4, where it works. I compiled both versions on an AMD64 arch and found some hints on the internet, that this might be the problem. Version 0.9.2 is from October 2003, so it is probably too old. As Alan said, I have to wait for a new release of freeradius. Thanks for your help, oz - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
radclient: problem with exit code 0 and 1
Hello, for monitoring our radius-servers, I use radclient for a long time in a script. After migration to another platform, radclient seems to work else, than before. If a monitored radiusd is down or the Auth of my monitoring-user fails, radclient gets an expected answer, but exits with status 0 in these cases. As far as I remember, in the past it was exit 1 (-- echo $?=1). I used to process exit 1 to indicate a problem with my radius-servers. Has this behaviour changed somewhere in the past? Or is it the wanted behaviour, that every valid answer to radclient exits with status 0 now? Take this for example: # /usr/bin/radclient -f /home/me/radpacket -x 192.168.x.x:1812 auth secret123 Sending Access-Request of id 248 to 192.168.x.x port 1812 User-Name = test-user Password = XXX NAS-IP-Address = 255.255.255.255 NAS-Port = 10 radclient: no response from server for ID 248 # echo $? 0 ... I expected $? to be 1, because the server was down and did not respond, what indicates an error. I am running radclient from freeradius 1.1.3-3, Debian/etch amd64: # radclient -v radclient: $Id: radclient.c,v 1.72.2.1.2.5 2006/05/16 18:26:08 aland Exp $ built on Dec 17 2006 at 01:07:36 Any ideas? thnx - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
checkrad not called after upgrade to 2.x
P.S. Sorry, I posted to the developers-list, but I meant the users-list, so
here it should be discussed:
M. S. wrote:
Can I put this in bugzilla? Seems like simultaneous use is completely
broken in 2.x which is a fairly significant feature.
To me checkrad seems to be broken too. I'm using 2.0.5 without virtual servers.
Checkrad says, my NAS is Unknown when it is invoked, although I have it in
my clients.conf:
client testerx {
ipaddr = 212.x.x.x
secret = xxx
nastype = erx
}
radiusd -X
[...]
auth: user supplied User-Password matches local User-Password
+- entering group session
expand: /usr/local/var/log/radius/radutmp -
/usr/local/var/log/radius/radutmp
expand: %{User-Name} - smith
checkrad: Unknown NAS 212.x.x.x, not checking
++[radutmp] returns ok
Multiple logins (max 1) [MPP attempt]: [smith] (from client testerx port
1610612780 cli #erx705#E60#44)
Found Post-Auth-Type Reject
WARNING: Unknown value specified for Post-Auth-Type. Cannot perform
requested action.
Sending Access-Reject of id 88 to 212.x.x.x port 5
Reply-Message := \r\nYou are already logged in - access denied\r\n\n
Finished request 2.
[...]
For our customers I have Simultaneous-Use := 1 in my users-file and checkrad
is invoked, when a stale session in radutmp is found:
# radwho -ir
smith,04279558,PPP,S1610612780,Wed 12:2,212.x.x.x,x.x.x.x
It is possible, that in 2.0.3 checkrad was ok, because I noticed no problems
with Simultaneous-Use there ... but maybe accidentally.
Is it really a bug in freeradius-2.0.5?
oz
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: checkrad not called after upgrade to 2.x
Alan DeKok wrote:
oz wrote:
M. S. wrote:
Can I put this in bugzilla? Seems like simultaneous use is completely
broken in 2.x which is a fairly significant feature.
I would agree. I'm not sure why it's broken...
To me checkrad seems to be broken too. I'm using 2.0.5 without virtual
servers.
...
checkrad: Unknown NAS 212.x.x.x, not checking
Arg.
I don't know why that doesn't work.
It is possible, that in 2.0.3 checkrad was ok, because I noticed no
problems with Simultaneous-Use there ... but maybe accidentally.
If it works in 2.0.3 that would be good to know. It would help track
down where the problem is.
Is it really a bug in freeradius-2.0.5?
Yes.
Alan DeKok.
Hello,
I guess, I tracked it down. I started radiusd -X of version 2.0.3 in my
2.0.5 environment, and compared the console messages between the two versions.
I noticed, that 2.0.5 didn't read in all my NAS clients. It stopped, where
one client definition had no secret set, with this message:
[...]
client as5200 {
ipaddr = 192.168.101.2
require_message_authenticator = no
shortname = as5200
}
/usr/local/etc/raddb/clients.conf[310]: secret must be at least 1 character long
Version 2.0.5 then rejects all users from *all the other* clients, when
checkrad is invoked and when radiusd wasn't able to read in the clients.conf
before completely:
auth: user supplied User-Password matches local User-Password
+- entering group session
expand: /usr/local/var/log/radius/radutmp -
/usr/local/var/log/radius/radutmp
expand: %{User-Name} - smith
checkrad: Unknown NAS 212.x.x.x, not checking
++[radutmp] returns ok
Multiple logins (max 1) [MPP attempt]: [smith] (from client testerx port
1610612780 cli #erx705#E60#44)
Found Post-Auth-Type Reject
WARNING: Unknown value specified for Post-Auth-Type. Cannot perform
requested action.
Sending Access-Reject of id 9 to 212.x.x.x port 5
Reply-Message := \r\nYou are already logged in - access denied\r\n\n
Finished request 2.
Going to the next request
When the clients.conf contains only valid clients, checkrad is invoked as it
should:
auth: user supplied User-Password matches local User-Password
+- entering group session
expand: /usr/local/var/log/radius/radutmp -
/usr/local/var/log/radius/radutmp
expand: %{User-Name} - smith
checkrad: unknown NAS type erx
rlm_radutmp: Failed to check the terminal server for user 'smith'.
++[radutmp] returns fail
Login OK: [smith] (from client testerx port 1610612780 cli #erx705#E60#44)
(... *this* checkrad message is ok, because the original checkrad-script
isn't aware of my custom NAS type erx).
So it is not a severe bug of checkrad in 2.0.5, it just behaves strange,
when some clients in clients.conf are no correctly defined.
Kind regards,
oz
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: checkrad not called after upgrade to 2.x
On Wed, 02 Jul 2008 18:02:18 +0200 Alan DeKok [EMAIL PROTECTED] wrote: i.e. when the server starts properly, checkrad works. When the server doesn't start properly, it doesn't. So it is not a severe bug of checkrad in 2.0.5, it just behaves strange, when some clients in clients.conf are no correctly defined. I've fixed it. The server now refuses to start if the client definitions are wrong. Alan DeKok. Thank you, Alan! oz - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Forcing lowercase User-Name with rlm_perl
Hi Chris,
your perl-module for lower_user works perfectly!
It was important, to use it in the right order, which
means in my case before files ...
authorize {
preprocess
perl
files
}
preacct {
preprocess
perl
files
}
Doing this, User-Name is lower-cased in the auth AND acct packets.
A small problem I just had when I recompiled my freeradius-2.0.3 with
libperl-dev to make rlm_perl available. At the end of make install
I've got:
[...]
if [ ! -f /usr/local/etc/raddb/sites-enabled/inner-tunnel ]; then \
cd /usr/local/etc/raddb/sites-enabled/; \
ln -s ../sites-available/inner-tunnel; \
fi
ln: creating symbolic link `./inner-tunnel' to
`../sites-available/inner-tunnel': File exists make[2]: *** [install]
Error 1 make[2]: Leaving directory
`/usr/local/src/freeradius-server-2.0.3/raddb' make[1]: *** [common]
Error 2 make[1]: Leaving directory
`/usr/local/src/freeradius-server-2.0.3' make: *** [install] Error 2
I decided to ignore it, because the symbolic link inner-tunnel
alread existed from my first compilation an that seems to cause the
error (is this fixed in 2.0.5 eventually?).
Thanks,
oz
Wow Chris, looks great and is very helpful!
I will test it tomorrow and give a short feedback whether it works.
Thanks a lot,
oz
On Wed, 11 Jun 2008 14:28:13 -0700
Chris [EMAIL PROTECTED] wrote:
I'm doing this:
perl_tolower.pm:
use strict;
use vars qw(%RAD_REQUEST %RAD_REPLY %RAD_CHECK);
#
# This the remapping of return values
#
use constantRLM_MODULE_REJECT=0;# /* immediately
reject the request */
use constantRLM_MODULE_FAIL= 1;# /* module failed,
don't reply */
use constantRLM_MODULE_OK=2;# /* the module is
OK, continue */
use constantRLM_MODULE_HANDLED= 3;# /* the module
handled the request, so stop. */
use constantRLM_MODULE_INVALID= 4;# /* the module
considers therequest invalid. */
use constantRLM_MODULE_USERLOCK= 5;# /* reject the
request (useris locked out) */
use constantRLM_MODULE_NOTFOUND= 6;# /* user not found
*/
use constantRLM_MODULE_NOOP= 7;# /* module succeeded
withoutdoing anything */
use constantRLM_MODULE_UPDATED= 8;# /* OK (pairs
modified) */
use constantRLM_MODULE_NUMCODES= 9;# /* How many
return codes there are */
sub authorize {
$RAD_REQUEST{'User-Name'} = lc($RAD_REQUEST{'User-Name'});
return RLM_MODULE_OK;
}
sub preacct {
$RAD_REQUEST{'User-Name'} = lc($RAD_REQUEST{'User-Name'});
return RLM_MODULE_OK;
}
radiusd.conf:
modules {
...
perl {
module = /usr/local/etc/perl_tolower.pm
}
...
}
In sites-enabled/default:
authorize {
preprocess
perl
...
}
preacct {
preprocess
perl
...
}
Works great as long as you don't have occasion for upper-case in User-
Name.
I am pretty sure when you define the module, you can have multiple
instances. It might be better to name this module perl-lc-username
and use perl-lc-username in the authorize{} and preacct{} sections of
sites-enabled/default.
Like this:
radiusd.conf:
modules {
...
perl-lc-username {
module = /usr/local/etc/perl_tolower.pm
}
...
}
In sites-enabled/default:
authorize {
preprocess
perl-lc-username
...
}
preacct {
preprocess
perl-lc-username
...
}
That'd be a lot clearer when you're looking at it months or years
later. I haven't tried this but it works with other modules.
On Jun 11, 2008, at 1:04 PM, oz wrote:
On Sat, 17 May 2008 18:09:09 -0700
Chris [EMAIL PROTECTED] wrote:
Thanks. I'll look at lc.
I was actually more concerned about the interfacing with
freeradius than the perl itself.
Hello, another user here, who needs lower_user = before to be able
to
switch to freeradius-2.0.x. Our database is an historically grown
users-file.
Were you or somebody else able to follow the advice of using
rlm_perl and lc()?
I must admit, I'm not able to program freeradius-perl-plugins :-/, but
would test it if necessary. At the moment I don't even have the
rlm_perl in /usr/local/lib/, but that I could solve by myself I guess
(libperl-dev wasn't already installed during compile-time on my
minimal
Debian/lenny etc.).
I know, there is nothing like a wishlist, but the lowercase-feature is
essential if we want to use 2.x it in the future.
kind regards
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Forcing lowercase User-Name with rlm_perl
On Sat, 17 May 2008 18:09:09 -0700 Chris [EMAIL PROTECTED] wrote: Thanks. I'll look at lc. I was actually more concerned about the interfacing with freeradius than the perl itself. Hello, another user here, who needs lower_user = before to be able to switch to freeradius-2.0.x. Our database is an historically grown users-file. Were you or somebody else able to follow the advice of using rlm_perl and lc()? I must admit, I'm not able to program freeradius-perl-plugins :-/, but would test it if necessary. At the moment I don't even have the rlm_perl in /usr/local/lib/, but that I could solve by myself I guess (libperl-dev wasn't already installed during compile-time on my minimal Debian/lenny etc.). I know, there is nothing like a wishlist, but the lowercase-feature is essential if we want to use 2.x it in the future. kind regards - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Forcing lowercase User-Name with rlm_perl
Wow Chris, looks great and is very helpful!
I will test it tomorrow and give a short feedback whether it works.
Thanks a lot,
oz
On Wed, 11 Jun 2008 14:28:13 -0700
Chris [EMAIL PROTECTED] wrote:
I'm doing this:
perl_tolower.pm:
use strict;
use vars qw(%RAD_REQUEST %RAD_REPLY %RAD_CHECK);
#
# This the remapping of return values
#
use constantRLM_MODULE_REJECT=0;# /* immediately
reject the request */
use constantRLM_MODULE_FAIL= 1;# /* module failed,
don't reply */
use constantRLM_MODULE_OK=2;# /* the module is
OK, continue */
use constantRLM_MODULE_HANDLED= 3;# /* the module
handled the request, so stop. */
use constantRLM_MODULE_INVALID= 4;# /* the module
considers therequest invalid. */
use constantRLM_MODULE_USERLOCK= 5;# /* reject the
request (useris locked out) */
use constantRLM_MODULE_NOTFOUND= 6;# /* user not found
*/
use constantRLM_MODULE_NOOP= 7;# /* module succeeded
withoutdoing anything */
use constantRLM_MODULE_UPDATED= 8;# /* OK (pairs
modified) */
use constantRLM_MODULE_NUMCODES= 9;# /* How many
return codes there are */
sub authorize {
$RAD_REQUEST{'User-Name'} = lc($RAD_REQUEST{'User-Name'});
return RLM_MODULE_OK;
}
sub preacct {
$RAD_REQUEST{'User-Name'} = lc($RAD_REQUEST{'User-Name'});
return RLM_MODULE_OK;
}
radiusd.conf:
modules {
...
perl {
module = /usr/local/etc/perl_tolower.pm
}
...
}
In sites-enabled/default:
authorize {
preprocess
perl
...
}
preacct {
preprocess
perl
...
}
Works great as long as you don't have occasion for upper-case in User-
Name.
I am pretty sure when you define the module, you can have multiple
instances. It might be better to name this module perl-lc-username
and use perl-lc-username in the authorize{} and preacct{} sections of
sites-enabled/default.
Like this:
radiusd.conf:
modules {
...
perl-lc-username {
module = /usr/local/etc/perl_tolower.pm
}
...
}
In sites-enabled/default:
authorize {
preprocess
perl-lc-username
...
}
preacct {
preprocess
perl-lc-username
...
}
That'd be a lot clearer when you're looking at it months or years
later. I haven't tried this but it works with other modules.
On Jun 11, 2008, at 1:04 PM, oz wrote:
On Sat, 17 May 2008 18:09:09 -0700
Chris [EMAIL PROTECTED] wrote:
Thanks. I'll look at lc.
I was actually more concerned about the interfacing with
freeradius than the perl itself.
Hello, another user here, who needs lower_user = before to be able
to
switch to freeradius-2.0.x. Our database is an historically grown
users-file.
Were you or somebody else able to follow the advice of using
rlm_perl and lc()?
I must admit, I'm not able to program freeradius-perl-plugins :-/, but
would test it if necessary. At the moment I don't even have the
rlm_perl in /usr/local/lib/, but that I could solve by myself I guess
(libperl-dev wasn't already installed during compile-time on my
minimal
Debian/lenny etc.).
I know, there is nothing like a wishlist, but the lowercase-feature is
essential if we want to use 2.x it in the future.
kind regards
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
text files authentcation fails (2.0.3)
Hello group,
I try to migrate a freeradius-Server from 1.1.7 to 2.0.3 using the new 2.0
syntax. Authentication uses the plain textfile /etc/raddb/users.
Although my test-user matches an entry, I get an error-message auth: No
authenticate method (Auth-Type)...
I have no idea how to change this Auth-Type.
The exact error you can see in an excerpt of radiusd -X:
#radiusd -X
FreeRADIUS Version 2.0.3, for host i686-pc-linux-gnu, built on Apr 3 2008
at 13:33:47
Copyright (C) 1999-2008 The FreeRADIUS server project and contributors.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
You may redistribute copies of FreeRADIUS under the terms of the
GNU General Public License.
Starting - reading configuration files ...
[...]
files {
usersfile = /usr/local/etc/raddb/users
acctusersfile = /usr/local/etc/raddb/acct_users
preproxy_usersfile = /usr/local/etc/raddb/preproxy_users
compat = cistron
}
[/usr/local/etc/raddb/users]:1 Cistron compatibility checks for entry odsl ...
Changing 'Password =' to 'Password =='
Changing 'Huntgroup-Name =' to 'Huntgroup-Name =='
Changing 'Simultaneous-Use =' to 'Simultaneous-Use +='
[...]
Ready to process requests.
[...]
Going to the next request
Ready to process requests.
User-Password = XYZ8AB
User-Name = odsl
Acct-Session-Id = erx GigabitEthernet 6/0.44:44:0004269184
Service-Type = Framed-User
Framed-Protocol = PPP
ERX-Pppoe-Description = pppoe 00:a0:c5:53:c9:40
Calling-Station-Id = #erx705#E60#44
NAS-Port-Type = Ethernet
NAS-Port = 1610612780
NAS-Port-Id = GigabitEthernet 6/0.44:44
NAS-IP-Address = XX.XX.XX.XX
NAS-Identifier = erx705
+- entering group authorize
++[preprocess] returns ok
WARNING: Found User-Password ==
WARNING: Are you sure you don't mean Cleartext-Password?
WARNING: See man rlm_pap for more information.
users: Matched entry odsl at line 1
++[files] returns ok
auth: No authenticate method (Auth-Type) configuration found for the
request: Rejecting the user
auth: Failed to validate the user.
Login incorrect: [odsl/XYZ8AB] (from client testerx port 1610612780 cli
#erx705#E60#44)
Delaying reject of request 0 for 1 seconds
Going to the next request
I have nothing special in my authorize and authenticate sections, because
there was no need for it in 1.1.7 (no pap-settings for example). In short
these entries:
/etc/raddb/radiusd.conf:
[...]
files {
usersfile = ${confdir}/users
acctusersfile = ${confdir}/acct_users
preproxy_usersfile = ${confdir}/preproxy_users
compat = cistron
}
[...]
$INCLUDE sites-enabled/
/etc/raddb/sites-available/default:
authorize {
preprocess
}
authenticate {
}
[...]
Do I need rlm_pap now in 2.0.3 for using files-authentication?
Any ideas, how I can make users/files authentication work again?
Greetings,
oz
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: text files authentcation fails (2.0.3)
First, thanks for supporting anyway! Alan DeKok wrote: oz wrote: I have no idea how to change this Auth-Type. You don't. You fix the configuration files to use the new recommended practice, which started being recommended in version 1.1.4. If you mean the cistron-compatibilty, I know it is not the recommended syntax. But we need this compatibility, because we can't change our users-processing at the moment. I'm sorry that I wasn't aware that Password has to be replaced with Cleartext-Password in 2.x. I read the docu before, but didn't find it mentioned explicitly. [/usr/local/etc/raddb/users]:1 Cistron compatibility checks for entry odsl ... Changing 'Password =' to 'Password ==' Changing 'Huntgroup-Name =' to 'Huntgroup-Name ==' Changing 'Simultaneous-Use =' to 'Simultaneous-Use +=' Fix those entries All I needed to do was replacing odslPassword = XYZ8AB with odslCleartext-Password = XYZ8AB in my users-file, and it instantly worked! Also, change ALL Password = ... or Password == .. to Cleartext-Password := ... See the FAQ for an example. That was the key and works under compat = cistron also. ++[preprocess] returns ok WARNING: Found User-Password == WARNING: Are you sure you don't mean Cleartext-Password? WARNING: See man rlm_pap for more information. Could you please try reading the debug output, and following it's recommendations? Yes, that can't be stressed enough! But I did, I just had the misunderstanding, that Cleartext-Password means the *value* of User-Password - and not is an attribute name by itself. And in man rlm_pap Cleartext-Password is not mentioned. Do I need rlm_pap now in 2.0.3 for using files-authentication? Any ideas, how I can make users/files authentication work again? READ the debug output? Yes, and I had tried using the pap-module, but with no success. It was the wrong direction, as I know now. Honestly. We don't just say run in debugging mode because we want the logs to be posted to the list. YOU need to read the output. It's not hard. Things like WARNING and read the man page should indicate to most people that maybe reading the man page would be a good idea. True as always. But sometimes debug-logs can be wrong interpreted and need additional information. Now, that I know that Cleartext-Password is mandatory in 2.x, I have another problem. I can't take the same users-file I use with my other 1.1.7-Servers without conversion. Freeradius-2.x is in my situation not downward-compatible, right?. Is it a dumb idea, to convert Password -- Cleartext-Password in a later release, when compat = cistron ist used? Or to accept both terms, Password and Cleartext-Password? Greetings, oz - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
1.1.7 on Debian sarge ?
Hello list, doesn't freeradius-1.1.7 no longer compile on Debian sarge (oldstable)? I get these errors on after ./configure and make: [...] Making all in rlm_perl... make[6]: Entering directory `/usr/local/src/freeradius-1.1.7/src/modules/rlm_perl' /usr/local/src/freeradius-1.1.7/libtool --mode=compile gcc -g -O2 -I/usr/local/src/f reeradius-1.1.7/src/include -D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBIAN -f no-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I /usr/lib/perl/5.8/CORE -D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBIAN -fno-st rict-aliasing -I/usr/local/include -c rlm_perl.c mkdir .libs gcc -g -O2 -I/usr/local/src/freeradius-1.1.7/src/include -D_REENTRANT -D_GNU_SOURCE - DTHREADS_HAVE_PIDS -DDEBIAN -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOU RCE -D_FILE_OFFSET_BITS=64 -I/usr/lib/perl/5.8/CORE -D_REENTRANT -D_GNU_SOURCE -DTHREA DS_HAVE_PIDS -DDEBIAN -fno-strict-aliasing -I/usr/local/include -c rlm_perl.c -fPIC - DPIC -o .libs/rlm_perl.o rlm_perl.c: In function `perl_xlat': rlm_perl.c:658: parse error before `*' rlm_perl.c:660: `handle' undeclared (first use in this function) rlm_perl.c:660: (Each undeclared identifier is reported only once rlm_perl.c:660: for each function it appears in.) make[6]: *** [rlm_perl.lo] Error 1 make[6]: Leaving directory `/usr/local/src/freeradius-1.1.7/src/modules/rlm_perl' make[5]: *** [common] Error 2 make[5]: Leaving directory `/usr/local/src/freeradius-1.1.7/src/modules' make[4]: *** [all] Error 2 make[4]: Leaving directory `/usr/local/src/freeradius-1.1.7/src/modules' make[3]: *** [common] Error 2 make[3]: Leaving directory `/usr/local/src/freeradius-1.1.7/src' make[2]: *** [all] Error 2 make[2]: Leaving directory `/usr/local/src/freeradius-1.1.7/src' make[1]: *** [common] Error 2 make[1]: Leaving directory `/usr/local/src/freeradius-1.1.7' make: *** [all] Error 2 /usr/local/src/freeradius-1.1.7# But I can compile 1.1.7 on Debian etch (stable) and Debian lenny (testing). Am I just missing a Debian developement package or something? I'd like to update our productive sarge installations before I try distro updates. Any ideas or known issues with Debian sarge? Thanks. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: 1.1.7 on Debian sarge ?
Thanks for your reply! I did an apt-get dist-upgrade of the oldstable/sarge system to have the latest versions of the sarge-packages. The compilation succeeded now! Now I will see if I can do the transition from freeradius 1.0.0 to 1.1.7 ... Oliver Alan DeKok wrote: oz wrote: doesn't freeradius-1.1.7 no longer compile on Debian sarge (oldstable)? I get these errors on after ./configure and make: ... rlm_perl.c: In function `perl_xlat': rlm_perl.c:658: parse error before `*' The weird thing is that the typedef it's complaining about is defined in rlm_perl... But I can compile 1.1.7 on Debian etch (stable) and Debian lenny (testing). Am I just missing a Debian developement package or something? I'd like to update our productive sarge installations before I try distro updates. Any ideas or known issues with Debian sarge? I don't run it myself, so I don't know more. If you don't use rlm_perl, just delete the entire directory. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Slow Accounting-Database - workaround?
Hello, our Accounting-SQL-Database became slower, so often radius-packets are dropped and and the NAS falls back to the secondary radius-server. Though the postgres database is indexed, there are often response-times between 1 - 3 secs and we cannot change it for the moment. To speed up things a little, I tried to change from single- to multi-threaded radius mode, but the problems even get worse. Only a few minutes after radiusd start, the maximum number of threads (= 256) is reached, caused by Unresponsive childs, which might be slow database answers: radius.log: ... Tue May 10 10:59:48 2005 : Error: WARNING: Unresponsive child (id 1015871) for request 71 Tue May 10 10:59:48 2005 : Info: The maximum number of threads (256) are active, cannot spawn new thread to handle request ... Is there any chance to use freeradius-1.0.2 with a *slow* SQL-Database? I read something about radsqlrelay in the 1.1.0 snapshot - can that be used to form some kind of buffer queue between the radiusd and the slow accounting database? Or will radsqlrelay step into the same timing-problem as the single- or multi-threaded radiusd? Thanks, Oliver - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Slow Accounting-Database - workaround?
Kostas Kalevras wrote: Is there any chance to use freeradius-1.0.2 with a *slow* SQL-Database? I read something about radsqlrelay in the 1.1.0 snapshot - can that be used to form some kind of buffer queue between the radiusd and the slow accounting database? Or will radsqlrelay step into the same timing-problem as the single- or multi-threaded radiusd? Yes use radsqlrelay. It's in cvs. radsqlrelay will be used in combination with a detail file for buffering and can handle sql database slow downs/failures. Bear in mind though that if your sql database cannot handle the accounting rate no buffering will do you any good in the long run. Thank you, I will see if we can use it. Compiling the 20050510-Snapshot of freeradius 1.1.0 under Debian(Sarge) I had a problem with make install. But I think it is known, and I solved it by removing the source-code of the module rlm_eap. make install: ... *** Warning: Linking the shared library rlm_eap_peap.la against the loadable module^M *** rlm_eap_tls.so is not portable!^M ^M *** Warning: Linking the shared library rlm_eap_peap.la against the loadable module^M *** libeap.so is not portable!^M ... Nice, that the new radzap ist working! Bye, Oliver - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
