January 2009 - Freeradius-Devel - lists.freeradius.org

GIT Log for 2009-01-20 00:33 GMT
by aland＠deployingradius.com 19 Jan '09

19 Jan '09

commit 41f7fe149bce496f5584df11dd6e9fe1a28bc3a1 Author: Alan T. DeKok <aland(a)freeradius.org> Date: Mon Jan 19 16:15:08 2009 +0100 Notes on MySQL Files changed: raddb/sqlippool.conf | 9 +-------- 1 files changed, 1 insertions(+), 8 deletions(-) ====================================================================== commit 2378dddd64ec401c905fd919be64e74a65c68aee Author: Alan T. DeKok <aland(a)freeradius.org> Date: Tue Jan 13 14:01:14 2009 +0100 Note restrictions on detail file usage Files changed: raddb/modules/detail | 7 ------- raddb/sites-available/robust-proxy-accounting | 7 ------- 2 files changed, 0 insertions(+), 14 deletions(-) ====================================================================== commit 27e1fa07d2397eef1429b0f9686abc5acce6403f Author: Alan T. DeKok <aland(a)freeradius.org> Date: Sun Jan 18 16:13:13 2009 +0100 CoA is in request->proxy, not request->packet Files changed: src/main/event.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) ====================================================================== commit 74e3af45d731ad88b040256769c5848e8c4949cc Author: Alan T. DeKok <aland(a)freeradius.org> Date: Mon Jan 19 14:51:19 2009 +0100 Try to work around transactional issues... Files changed: raddb/sql/mysql/ippool.conf | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) ====================================================================== commit 59eb241b7e0a3ae3af834deb1a516226f1a9aa81 Author: Alan T. DeKok <aland(a)freeradius.org> Date: Mon Jan 19 13:41:34 2009 +0100 Clean up CoA origination to not depend on CoA This makes the patch a little cleaner Files changed: src/main/event.c | 13 +++++-------- 1 files changed, 5 insertions(+), 8 deletions(-) ======================================================================

1 0

GIT Log for 2009-01-19 00:33 GMT
by aland＠deployingradius.com 18 Jan '09

18 Jan '09

commit 43c7d9ced19f33f1f8b9370f53f223067dffd747 Author: Alan T. DeKok <aland(a)freeradius.org> Date: Sun Jan 18 17:16:10 2009 +0100 Removed extraneous line src/main/checkrad.pl.in | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-)

1 0

detail logging not logging?
by Brad Clemmons Jr 17 Jan '09

17 Jan '09

Hi all. I seem to be missing something somewhere. I'm new to freeradius but I managed to get a system up and running. Here's a copy of my stripped down radiusd.conf. I'm only doing accounting right now so no auth stuff. I know radius itself is working because I can change the secret in the client.conf and I get the errors in the radius.log when the client sends. The issue I'm having now though is that I can't seem to get the detail logging to work so the only time I get any logs is if I purposefully foul something up to cause it to error. Right now I have the detail statement at the bottom of the file. I've tried moving it into the modules section but that didn't make any different. I also tried manually specifying the fully qualified path for the log file as well to no avail. I verified user and group permissions in the necessary directories, but I must still be missing something. Anyone able to point out what's wrong but right under my nose? Also it's worth noting this is running on Solaris10x86 under a zone. ############################################################ ## radiusd.conf -- FreeRADIUS server configuration file. ## ## http://www.freeradius.org/ ## $Id$ ## prefix = /opt/freeradius exec_prefix = ${prefix} instance_prefix = /opt/voip/freeradius sysconfdir = ${instance_prefix}/etc localstatedir = ${instance_prefix}/var sbindir = ${exec_prefix}/sbin logdir = ${instance_prefix}/logs raddbdir = ${instance_prefix}/etc radacctdir = ${instance_prefix}/var/radacct # # name of the running server. See also the "-n" command-line option. name = radiusd # Location of config and logfiles. confdir = ${raddbdir} run_dir = ${localstatedir}/run # Should likely be ${localstatedir}/lib/radiusd db_dir = ${raddbdir} # # libdir: Where to find the rlm_* modules. # # libdir = ${exec_prefix}/lib # pidfile: Where to place the PID of the RADIUS server. # pidfile = ${run_dir}/${name}.pid # user/group: The name (or #number) of the user/group to run radiusd as. # user = ****** group = ****** # max_request_time: The maximum time (in seconds) to handle a request. # max_request_time = 30 # cleanup_delay: The time to wait (in seconds) before cleaning up cleanup_delay = 5 # max_requests: The maximum number of requests which the server keeps max_requests = 1024 # listen: Make the server listen on a particular IP address, and send listen { type = acct ipaddr = * port = 1813 } # hostname_lookups: Log the names of clients or just their IP addresses hostname_lookups = no # Core dumps are a bad thing. This should only be set to 'yes' allow_core_dumps = no # Regular expressions regular_expressions = yes extended_expressions = yes # # Logging section. The various "log_*" configuration items log { destination = files file = ${logdir}/radius.log syslog_facility = daemon # Log the full User-Name attribute, as it was found in the request. stripped_names = no # Log authentication requests to the log file. auth = no # Log passwords with the authentication requests. auth_badpass = no auth_goodpass = no } # The program to execute to do concurrency checks. checkrad = ${sbindir}/checkrad # SECURITY CONFIGURATION security { max_attributes = 200 reject_delay = 1 status_server = yes } # PROXY CONFIGURATION # # proxy_requests: Turns proxying of RADIUS requests on or off. proxy_requests = no #$INCLUDE proxy.conf # CLIENTS CONFIGURATION $INCLUDE clients.conf # THREAD POOL CONFIGURATION thread pool { # Number of servers to start initially --- should be a reasonable # ballpark figure. start_servers = 5 max_servers = 32 min_spare_servers = 3 max_spare_servers = 10 max_requests_per_server = 0 } # MODULE CONFIGURATION modules { # $INCLUDE ${confdir}/modules/ $INCLUDE eap.conf $INCLUDE sql.conf $INCLUDE sql/mysql/counter.conf #$INCLUDE sql/postgresql/counter.conf } # Instantiation instantiate { exec expr expiration logintime } ###################################################################### # # Policies that can be applied in multiple places are listed # globally. That way, they can be defined once, and referred # to multiple times. # ###################################################################### $INCLUDE policy.conf #$INCLUDE sites-enabled/ detail { detailfile = ${radacctdir}/%{Client-IP-Address}/detail-%Y%m%d #detailfile = ${radacctdir}/%{NAS-IP-Address}/detail-%Y%m%d #detailfile = ${radacctdir}/detail.log detailperm = 0600 } ########################################################################

2 3

FreeRadius as a RADIUS server cum GPRS subscriber database
by Sourav Chakraborty 15 Jan '09

15 Jan '09

Hi All, We are evaluating whether we can use FreeRadius as a RADIUS server cum GPRS subscriber database(using MYSQL).There are these queries which we have and hence I am seeking your help --- 1>What is the rate of RADIUS msgs that FreeRadius can handle? 2>What needs to be done if we want to write handlers for START/STOP/Interim Update acct msgs?The handlers would basically extract info of the corresponding subscriber(framed-IP) from the mySQL database and send out radius response. 3>On receiving STOP msg from NAS,can FreeRadius send out notification to a particular IP?Any event handling capability existing? Thanks in Advance Sourav

2 1

freeradius FreeTDS/sybase
by Gabriel Blanchard 14 Jan '09

14 Jan '09

Reading through the freeradius archive I realize that FreeTDS support has been "abandoned". But I'm at the point where I need this support for MSSQL connectivity and ready to spend the time coding the necessary modules to support it. Would it be safe to simply use the Sybase library and go from there? What is currently missing from FreeTDS for it to be stable with Freeradius? -Gabriel

3 3

GIT Log for 2009-01-13 00:33 GMT
by aland＠deployingradius.com 12 Jan '09

12 Jan '09

commit 11143e95d2ed10ba31f9ca12174d0ddbd101343f Author: Alan T. DeKok <aland(a)freeradius.org> Date: Mon Jan 12 14:35:30 2009 +0100 run_dir depends on ${name}, too Files changed: raddb/radiusd.conf.in | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) ====================================================================== commit 72d69c97d779ac6fdeb0cc64d60846ef533da1f2 Author: Alan T. DeKok <aland(a)freeradius.org> Date: Mon Jan 12 14:32:10 2009 +0100 Commented out SQL modules by default. Unlike the EAP module, they need *additional* things to be configured before they will work. So you can't just build the server with SQL support, and then start it. You need to edit sql.conf, etc. In the interest of making the server start quickly in debugging mode, the SQL module configurations are now commented out. Files changed: raddb/radiusd.conf.in | 9 +++++---- 1 files changed, 5 insertions(+), 4 deletions(-) ====================================================================== commit 3a7c42724175b11c08c29a128b6f11c7b8c0311a Author: Alan T. DeKok <aland(a)freeradius.org> Date: Mon Jan 12 10:14:12 2009 +0100 Change default hash function to SHA1. MD5 is broken. Files changed: raddb/certs/ca.cnf | 2 +- raddb/certs/client.cnf | 2 +- raddb/certs/server.cnf | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) ====================================================================== commit 82188f7ec3ad2793467e358fecd90d214008dffe Author: Alan T. DeKok <aland(a)freeradius.org> Date: Wed Jan 7 10:51:34 2009 +0100 Added notes on using "screen" Files changed: doc/bugs | 23 ----------------------- 1 files changed, 0 insertions(+), 23 deletions(-) ======================================================================

1 0

FreeRADIUS and OpenSSL Linkage
by Alan DeKok 10 Jan '09

10 Jan '09

It would be useful to be able to link FreeRADIUS with OpenSSL, for systems like Debian that have restrictive license policies. Upon auditing the source code (and some offline discussion), it looks like it may be possible. The code using OpenSSL is: src/main/threads.c src/modules/rlm_eap/ src/modules/rlm_otp/ src/modules/rlm_wimax/ The ownership of the relevant code is largely myself, a bankrupt company (rlm_eap), and Tri-D systems (rlm_otp). We've tried contacting Tri-D systems (now owned by RedHat), but have had little response. My suggestion is to do the following: 1) add a license exception to the main LICENSE file: In addition, as a special exception, the copyright holders give permission to link the code of portions of this program with the OpenSSL library, and distribute linked combinations including the two. This exception does not apply to the "rlm_otp" module. You must obey the GNU General Public License in all respects for all of the code used other than OpenSSL. If you modify file(s) with this exception, you may extend this exception to your version of the file(s), but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version. 2) remove rlm_otp from the "stable" module list. It's not being maintained, and I'm not sure anyone is using it. This will make life easier for package maintainers, as they can just configure --without-rlm_otp. The result will be a version of the server that can be linked with OpenSSL on Debian-based systems. Thoughts? Alan DeKok.

6 7

Does freeradius-client-1.1.6 library supports challenge-response mode of authentication?
by Gautam Tripathi 08 Jan '09

08 Jan '09

Hi all radius developers, We are using freeradius-client library version 1.1.6 for authenticating users against a Radius server. Our radius server uses the challenge-response mechanism of radius protocol. (It a steel belted radius server which acts as a front end for RSA ace manager). However, we are unable to use this client library for our needs. The reason is that the library does not seem to support challenge-response mode of authentication. From what I have understood by looking at the library source is that it can only give a yes/no answer to an authentication request. Specifically, the library provides a single method for radius authentication called rc_auth. However, this function seems to return only binary result (OK_RC or BADRESP_RC). There is no return code for an access-challenge message from the server. The client understand only access-accept or access-reject codes. So I am coming to the conclusion that the freeradius-client-1.1.6 is not a fully conforming radius client library. The library in its current form and at the current version doesn not support challenge-response type of authentications. Please corrent me if I am wrong. May be I am missing something here. But we need a definite answer to be able to decide if this library is sufficient for our needs or not. Best, Great Khan

2 1

Debian and RTLD_GLOBAL (again)
by Chris Moules 08 Jan '09

08 Jan '09

Hi, I have been following the development of the 2.x branch of FreeRADIUS for awhile. We have been looking at moving our Debian systems running FreeRADIUS 1.1.x to the 2.x release. Most things are fine, more than that, the FR 2.x release is great. There is a sticking point however, on systems that use the sqlippool module there is still the crash due to a symbol lookup error, the known Debian RTLD_GLOBAL (or lack thereof) issue (I have tried resolving some of this myself, but it is beyond my ken). I have seen that there has been work towards resolving this, The last I (productively) saw written on this was: <http://lists.freeradius.org/pipermail/freeradius-users/2008-November/msg001…> Alan, what would your "one more fix" be? I can try to work on this if you can point me in the right direction. I would really like to get this working so that I can decommission the last remaining 1.1.x servers. Thanks for any input. Regards Chris

2 3

bobby has recommended you
by bobby 08 Jan '09

08 Jan '09

1 0