rihad wrote:
Don't you think 5 second delay is pretty unusual for a LAN.
You misunderstand. The packets are reaching the server just fine. You've configured the server to do *something* strange. So it's taking more than 20 seconds to respond. This does not happen in the default configuration.
Yes, UDP acct packets sometimes get dropped and never reach the server, but the delay... It's much safer to sometimes drop 2 auth requests in a row for the reason you stated than allow the server to reach a point where it's unable to make further progress doing _current_ work.
*You* are the one who allowed the server to reach a point where it can't make progress. The server *is* dropping the authentication requests. See the log output you posted. I suggest understanding how RADIUS works before offering advice.
That's hundreds if not thousands (if you count acct packets too) of requests all reaching the server nearly at the same time.
The server can handle 1000's and even 10's of 1000's of packets per second. If you are seeing performance less than that, it's because you've configured something to be slow. i.e. you're putting the accounting packets into a slow DB, or a DB without indexes. When you make FreeRADIUS depend on something else like a slow DB, then the server performance is limited by that DB. Blaming FreeRADIUS isn not appropriate. Alan DeKok.
Tomorrow early in the morning I'll try the fix and see how it goes.
Thanks for all the info you gave.
Any suggestions?
Fix whatever backend is getting overloaded and making FreeRADIUS wait for> 5 seconds to send a response...
-Arran
Arran Cudbard-Bell a.cudbardb@freeradius.org
RADIUS - Waging war on ignorance and apathy one Access-Challenge at a time.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html