[RADIATOR] radiator Timeout handling

[Hugh Irvine]

Hello Michael -

We'll need to see a copy of the configuration file (no secrets), together with a more complete trace 4 debug showing what is happening.

We will also need to know what hardware/software platform you are running on, what version of Perl, what version of DBI/DBD, what SQL database, and anything else that might be useful.

regards

Hugh


On 16 Sep 2010, at 13:33, Michael wrote:

> Hi, 
> 
> I'm having a couple issues with <AuthBy SQL>. Maybe it would be considered a bug i'm not sure. 
> 
> 
> 1. the Timeout handling. 
> ------------------------ 
> >From my testing, it appears that radiator times out at this value, but seems to retry the sql query a second time, creating in another timeout count. 
> 
> eg debug: 
> Tue Sep 14 12:48:21 2010: DEBUG: Handling accounting with Radius::AuthSQL 
> Tue Sep 14 12:48:21 2010: DEBUG: do query is: 'insert into `acct` <snip> 
> Tue Sep 14 12:48:25 2010: ERR: do failed for 'insert into `acct` <snip> SQL Timeout 
> Tue Sep 14 12:48:29 2010: ERR: do failed for 'insert into `acct` <snip> SQL Timeout 
> Tue Sep 14 12:48:29 2010: DEBUG: AuthBy SQL result: IGNORE, Database failure 
> 
> Timeout is set for 4 seconds... 
> so, query executed at 12:48:21, ERR timed out 4 seconds later, appeared to re-try but didn't say anything, and another ERR timeout 4 seconds after that.  That's 8 seconds of course.  It doubles the Timeout value. 
> 
> This is no good, for me.  If I set my SQL timeout value for 4 seconds, and my NAS timeout for 5 seconds, I expect my radiator to timeout before my NAS re-transmits.  my NAS will retry after 5 seconds because radiator hasn't responded.  And, radiator hasn't obeyed the timeout so it's still waiting for 8 seconds.  This causes the same accounting packet to enter radiator again, and causing another 8 seconds delay, and of course duplicate entries in the accounting logging since I'm also using AcctFailedLogFileName so the packet will eventually end up in the SQL table. 
> 
> 
> 2. SQL Timeout issue #2. 
> ------------------------ 
> using the same debug example above, when the SQL query times out, it doesn't seem to use the FailureBackoffTime value. It only seems to use FailureBackoffTime when there is a connection failure, not a timeout.  So, every query is still presented to the SQL server.  If the timeout is due to lets say a write lock, when the lock releases, all the queued insert statements are executed creating in sometimes up to 10 duplicate accounting entries. 
> 
> 
> 3. AuthBy result after failure 
> ------------------------------ 
> an IGNORE occurs when the SQL query fails, but if AcctFailedLogFileName is used, and successfully wrote the accounting packet to the file, should radiator not then reply with an ACCEPT?  Dumping the accounting packet to a file, but replying with IGNORE will cause the NAS to go to the next radius server possibly accepting the entry, therefore the packet in the acct failed logfile, is a double.  Even if there's only 1 radiator server in play, there will be an accounting packet entry in the failed log for each time the NAS retries. 
> 
> 
> Thanks in advanced for any advice, 
> Michael 
> 
> _______________________________________________
> radiator mailing list
> radiator at open.com.au
> http://www.open.com.au/mailman/listinfo/radiator



NB: 

Have you read the reference manual ("doc/ref.html")?
Have you searched the mailing list archive (www.open.com.au/archives/radiator)?
Have you had a quick look on Google (www.google.com)?
Have you included a copy of your configuration file (no secrets), 
together with a trace 4 debug showing what is happening?

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
Includes support for reliable RADIUS transport (RadSec),
and DIAMETER translation agent.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.