(RADIATOR) Problem with session database and wireless reauthe ntication

[Frank Danielson]

Another option is to have a handler for authentication with a
<SessionDatabase NULL> and a seperate handler for the accounting with your
<SessionDatabase SQL>. The downside to this is that if you miss an
accounting Start for some reason, radwho won't show the session.

You may also want to try and use a DeleteQuery value in your
<SessionDatabase SQL> that only works during accounting requests by using
the special variables in section 6.2 of the manual. Something like delete
from RADONLINE where NASIDENTIFIER='%1' and NASPORT=0%2 AND
%{Acct-Status-Type} = 'Stop'. This will only delete from the table during
Stop accounting requests and not access requests. The downside here and the
reason why there is a delete during access requests is that you will get a
hung session in the table if you miss an accounting Stop.

If you don't have a problem with occasional missed accounting requests
either way should work but I like the second option because it feels more
perlish and what you are trying to accomplish would probably be more obivous
to someone reading the config file.

Frank Danielson
Infrastructure Architect

ClearSky Mobile Media
56 E. Pine St.
Orlando, FL 32801
USA

-----Original Message-----
From: Roy Badami [mailto:roy.badami at globalgraphics.com]
Sent: Monday, January 10, 2005 11:23 AM
To: radiator at open.com.au
Subject: (RADIATOR) Problem with session database and wireless
reauthentication



I have a problem with the session database losing entries for wireless
connections, which I've tracked down to the following code in
handle_request (in Handler.pm)

    if ($p->code eq 'Access-Request')
    {
        # If we lost a Stop for this port, clean up the session database
        $sessdb->delete($original_username, $nas_id, $nas_port, $p,
                        $session_id, $framed_ip_address);
 
        # Issue a denial and bomb out
        return $self->handlerResult($p, $main::REJECT, 'MaxSessions
exceeded')
            if (defined $self->{MaxSessions}
                && $sessdb->exceeded($self->{MaxSessions},
$original_username, \
$p));
    }


If a wireless client reauthenticates (either because Odyssey Client is
configured to periodically reauthenticate, or because the user hits
the reauthenticate button) then the above code will delete the session
from the session database in response to the Access-Request.

However reauthentication doesn't send any new accounting requests (at
least with Cisco access points) so the user is not added back to the
session database after successful reauthentication.

At the moment I don't really care about session limits, but I do care
about radwho.pl working.  So as a workaround I think I can safely
comment out the above code.

A proper fix is harder...

  -roy

--
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.

--
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.