(RADIATOR) problem with RADONLINE and RADPOOL in radiator

[Eric Lackey]

This is a very weird problem and would only happen in certain situations.
We use <SessionDatabase SQL> and <AddressAllocator SQL> in our radius
configuration.  We had a problem recently where our users could not get
authenticated and we were getting errors like these in our logfile.
 
ERR: do failed for 'update RADPOOL set STATE=1,TIME_STAMP=1020502923,
EXPIRY=1043278923, USERNAME= where YIADDR='XXX.XXX.XXX.XXX' and TIME_STAMP
=1020488587': You have an error in your SQL syntax near 'where
YIADDR='XXX.XXX.XXX.XXX' and TIM
E_STAMP =1020488587' at line 1 
 
As you can see the query is blowing up because there is no username in the
query.  We know that our RADONLINE table was corrupted.  This was causing
the database handle to die in the SqlDB.pm do subroutine when it tried to
insert a login into the RADONLINE table.  
 
The problem results from this code here in the
AddressAllocatorSQL.pm::allocate code.
 
$username = $self->quote($username);  
 
This calls the routine below in SqlDB.pm.  It looks like this code tries to
call a quote routine in the DBI module.  By this time, the handle has been
killed because the RADONLINE table was corrupted and gave back an error.  So
there is no handle available to call the quote routine.  Therefore this
routine returns undefined which sets the username to undefined making the
username variable unavailable for the update RADPOOL query.
 
sub quote
{
    my ($self, $s) = @_;
 
       return $Radius::SqlDb::handles{$self->{dbname}}
       ? $Radius::SqlDb::handles{$self->{dbname}}->quote($s)
           : undef;   
 
}
 
We have fixed this problem by changing the routine to the following which
reconnects to the database if no handle exists.  If there is a better
solution to this problem, please let me know.
 
sub quote
{
    my ($self, $s) = @_;
 
    if ($self->reconnect())
    {
       return $Radius::SqlDb::handles{$self->{dbname}}
       ? $Radius::SqlDb::handles{$self->{dbname}}->quote($s)
           : undef;   
    }
    # we should never get here
    return undef;
}
 
Thanks,
 
Eric Lackey
ISDN-Net Operations
eric at isdn.net
 
 
 
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.open.com.au/pipermail/radiator/attachments/20020507/4d02d435/attachment.html>