(RADIATOR) Strange MySQL error.

[Greg Wildman]

Hi all,

I am struggling with a MySQL error in the AuthSQL section. Let me shed
some more light on my situation.

I am in the process up upgrading our Radius server from version 2.16.1
to 3.3.1. The new server is running Red Hat 7.3 with the following
package versions.

Radiator-3.3.1-1
mysql-3.23.49-3
perl-DBI-1.21-1
perl-DBD-MySQL-1.2219-6

The actual MySQL server located on the same switched network is also
running version 3.23.49. It is currently configured for 300 max
concurrent sessions.

During my testing using radpwtest I get the following errors in my
radiator logfile and then usually followed by LDAP failure errors.

DBD::mysql::st fetchrow failed: fetch() without execute() at
/usr/lib/perl5/site_perl/5.6.1/Radius/SqlDb.pm line 253. 
DBD::mysql::st fetchrow failed: fetch() without execute() at
/usr/lib/perl5/site_perl/5.6.1/Radius/SqlDb.pm line 253.


I have looked in the SqlDb.pm and can see that the function getOneRow is
called and seems to be failing because the connection has failed. I
suspected that the "persistent" connection had closed for whatever
reason at the time of the fetch().

I hashed out the <SessionDatabase SQL> section of my config, restarted
radiator and the problem persisted, so I unhashed my changes and then
hashed out the <Auth SQL> section. My problem disappeared after a
restart. The catch is that this section if necessary for auditing
purposes.

I run mytop on the MySQL server during my tests but the server never has
more than 40 open connection (of a possible 300) and only 2 are active
at any one time. Another thing I noticed was that the connection from
radiator lasts only 10 seconds before it closes and another one opens.
The errors I get in the logfile "seem" to only happed on the first
radpwtest after I stop testing for a few minutes.

My config is as follows:

<Handler Realm=XYZ>
   #Continue trying to authenticate while rejected.
   #SQL will force reject.
   AuthByPolicy    ContinueWhileReject

   # This will always reject, we use it to update the SQL server.
   # Use the SQL database to only store accounting information.
   <AuthBy SQL>
      Identifier   vISP_accounting
      DBSource    dbi:mysql:radius_db:db.some.server.net
      DBUsername   radius
      DBAuth       secret

      Timeout      15
      FailureBackoffTime 2

      #Delete any possible broken sessions from the session DB
      AuthSelect DELETE FROM RADONLINE WHERE USERNAME='%n' AND
TIME_STAMP+1800 < %t

      AccountingTable ACCOUNTING
      AcctColumnDef   USERNAME,User-Name
      AcctColumnDef   TIME_STAMP,Timestamp,integer
      AcctColumnDef   ACCTSTATUSTYPE,Acct-Status-Type
      AcctColumnDef   ACCTDELAYTIME,Acct-Delay-Time,integer
      AcctColumnDef   ACCTINPUTOCTETS,Acct-Input-Octets,integer
      AcctColumnDef   ACCTOUTPUTOCTETS,Acct-Output-Octets,integer
      AcctColumnDef   ACCTSESSIONID,Acct-Session-Id
      AcctColumnDef   ACCTSESSIONTIME,Acct-Session-Time,integer
      AcctColumnDef   ACCTTERMINATECAUSE,Acct-Terminate-Cause
      AcctColumnDef   NASIDENTIFIER,NAS-IP-Address
      AcctColumnDef   NASPORT,NAS-Port,integer
      AcctColumnDef   FRAMEDIPADDRESS,Framed-IP-Address
  </AuthBy>

  # Now for the real authentication. If it fails here then the user is
out of luck.
  <AuthBy LDAP2>
      DefaultSimultaneousUse  1

      Host            localhost
      Port            389
      BaseDN          ou=radius,o=example,c=com
      Version         2
      HoldServerConnection

      #LDAP Asstributes
      UsernameAttr            uid
      EncryptedPasswordAttr   userpassword
      CheckAttr               check

      AddToReply Service-Type=Framed-User,\
           Framed-Protocol=PPP,\
           Framed-IP-Address=255.255.255.254
  </AuthBy>
</Handler>


Anybody had similar problems? Is there any way of tracing the MySQL
calls or getting more debug than level 5?

--
Greg


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