(RADIATOR) FW: problem with RADONLINE and RADPOOL in radiator

Eric Lackey eric at isdn.net
Sat May 11 11:37:10 CDT 2002


I never got a response on this message.  I just wanted to verify that you
got the problem, so we don't write over it in our next upgrade of Radiator
and recreate the problem.
 
Thanks,
 
Eric Lackey
ISDN-Net Operations
615-221-4204
 
-----Original Message-----
From: Eric Lackey 
Sent: Tuesday, May 07, 2002 3:57 PM
To: radiator at open.com.au
Subject: problem with RADONLINE and RADPOOL in radiator
 
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/20020511/aec76c0a/attachment.html>


More information about the radiator mailing list