(RADIATOR) Session-Timeout getting set too late

Mon Jan 20 22:34:38 CST 2003

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 radiator-announce at open.com.au
> To unsubscribe, email 'majordomo at open.com.au' 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 radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.