Never mind.  I just saw the fix in the patch list.

 

Thanks!

 

-----Original Message-----
From: Eric Lackey
Sent
:
Saturday, May 11, 2002 11:37 AM
To: '[EMAIL PROTECTED]'
Subject: FW: problem with RADONLINE and RADPOOL in radiator

 

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: [EMAIL PROTECTED]
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

[EMAIL PROTECTED]

 

 

 

 

 

Reply via email to