Hello Jeff -
The first thing you should do is read the radius rfc's and the Radiator reference manual (both contained in the "doc" directory of the distribution). Then you should read the Radiator source code to find out how it works. And we also offer training courses if that is of interest.
You should also note that there are two seperate things happening with the radius protocol. The first is the access request/access accept, and it is in the access accept that the Session-Timeout must be returned to the NAS. The second thing that happens after the session has come up is an accounting start is sent, and after the session has completed an accounting stop is sent.
With a standard AuthBy SQL clause it is very easy to do what you describe with an AuthColumnDef.
BTW - the latest version is Radiator 3.5.
regards
Hugh
On Tuesday, Jan 21, 2003, at 04:26 Australia/Melbourne, Jeff Cave wrote:
Two questions:
1. I have had Radiator thrown at me. I have no knowledge of the system and feel like I am in way over my head. Can anyone recommend good reading, courses or other ways to get educated?
2. The problem I have had thrown at me...
I have been asked to set a session timeout based on the amount of time left in a users account. I can hard code a timeout in the realm but I need to set it on a user-to-user basis. The system's code has been heavily modified and a lot of what is in the Radiator manual no longer seems to apply.
The Realm handler is a modified AuthSQL file.
In the file AuthCOMPNAME, I have added a couple of lines that add a session timeout to the response packet, but it seems that it does not calculate how much time the user has (SQL Procedure: isp_requestauth) until after the ACCESS-ACCEPT packet is sent to the NAS. When I check the log, it appears that isp_requestauth is being run before the ACCESS-ACCEPT packet is sent, this makes sense since isp_requestauth is also where the user's password and filename are verified and Radiator is catching invalid logins (infact it knows it was an invalid login because they had 0 minutes returned).
SEQUENCE OF EVENTS:
1. ACCESS-ACCEPT Sent with SESSION-TIMEOUT=0
2. AuthCOMPNAME calculates session-timeout to be ?????
3. Accounting-Response Sent with SESSION-TIMEOUT = ?????
The problem with this is that with the initial timeout of 0, it seems that the timeout is not taking when it is sent in the accounting-response.
WANTED SEQUENCE OF EVENTS:
1. AuthCOMPNAME calculates session-timeout to be ?????
2. ACCESS-ACCEPT Sent with SESSION-TIMEOUT = ?????
Does anyone have any suggestions on where/how I should be setting the session-timeout to ensure that the user has their appropriate timeout?
THE CONFIG FILE:
<Realm DEFAULT>
AcctLogFileName %L/account.log
<AuthBy COMPNAME>
NoDefault
DBSource dbi:ODBC:ilink
DBUsername xxxxxxx
DBAuth xxxxxxx
FailureBackoffTime 30
Timeout 10
# Authentication
AuthBlock \
isp_requestauth '%U','%P','%{NAS-IP-Address}/%{NAS-Port}','%{Calling_Station_ID}'
# Accounting
AccountingStopsOnly
AcctSQLStatement \
isp_accounting '%U', \
'%g-%i-%f %j:%k:%p', \
%{Acct-Session-Time}, \
'%{Acct-Session-Id}', \
'%{Acct-Terminate-Cause}', \
'%N', \
'%{NAS-Port}', \
'%{Framed-IP-Address}', \
%{Acct-Input-Octets}, \
%{Acct-Output-Octets}
</Authby>
</Realm>
Signifigant Bits from AuthCOMPNAME:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
#This is the only place that I can find that the response packet is built
#I have only added the one line and set it to a global variable $SessTime
#I know gobal is probably not the best for this but I'm panicking.
sub handle_request
{
my ($self, $p, $rp, $extra_checks) = @_;
my $type = ref($self);
$self->log($main::LOG_DEBUG, "Handling with $type (special)");
if ($p->decodedPassword() =~ /'/)
{
$self->log($main::LOG_DEBUG, "$type rejected because invalid char in password");
return ($main::REJECT, 'Invalid Char in password');
} else {
$self->log($main::LOG_DEBUG, "$type accepted char in password");
}
#
# This is where the timeout gets stuffed into the response packet
#
$rp->addAttrByNum($Radius::Radius::SESSION_TIMEOUT,$SessTime);
#
#
#
return $self->SUPER::handle_request($p, $rp, $extra_checks);
}
#####################################################################
# Find a the named user by looking in the database, and constructing
# User object if we found the named user
# $name is the user name we want
# $p is the current request we are handling
sub findUser
{
my ($self, $name, $p) = @_;
.
.
.
my $q = &Radius::Util::format_special($self->{AuthBlock}, $p);
#
# I set the global $SessTime in here
#
my $sth = $self->prepareAndExecute($q);
#
#
#
.
.
.
return ($User)
}
#####################################################################
# Convenience function to prepare and execute a query.
# If it fails to execute, complain, and try to reconnect and reexecute.
# If it still fails to execute, return undef, else a statement handle
sub prepareAndExecute
{
my ($self, $q) = @_;
my ($attempts, $sth, $rc);
$sth = $Radius::SqlDb::handles{$self->{dbname}}->prepare($q);
$rc = $sth->execute if $sth;
my $row = $sth->fetchrow_arrayref;
&main::log($main::LOG_DEBUG, "2 rc = @$row[0], balance = @$row[1]\n");
#
# Here is where I set SessTime
#
$SessTime = @$row[1] * 60;
#
#
#
return $sth;
}
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
-- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence.
=== Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
