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@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. _______________________________________________ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
