Hi > Think about it for a second. It's taking SIXTY SECONDS to > authenticate a user? What the heck is going on in your system?
I think the problem is not the authentication process. It occurs after a accounting stop request. The mentioned problem (resident radiusd process with 99% cpu load) seems to be caused by dialin users, that use bundled ISDN connections (128k). The process uses up to 99% after the user has disconnected (after AcctStop). I recorded the debug log from radiusd and extracted the following sequence that caused such a 99%-process: req. action --------------------- 56 Access channel#1 -> response 56 57 AccStart channel#1 -> response 57 58 AccAlive channel#1 -> response 58 59 Access channel#2 -> response 59 60 AccStart channel#2 61 AccAlive channel#2 -> response 61 -> response 60 62 AccStop channel #2 63 AccStop channel #1 -> response 62 64 AccStop channel #1 -> response 64 ==> WARNING: Unresponsive child (id 2051) for request 61 ---------------------- The only problem is the 99%-process that is left over after that sequence. Everything else is ok: Both connections were recorded completely by the accunting DB, the user could use the service etc. The sequence above leads to the following questions: 1. Why is there no response to the request 63? 2. Why causes the AccAlive request 61 the warning, that was processed successfully? Any ideas? Is there a known problem with bundled ISDN connections? PS: The debug log is available on request. Thank you Marco Steinacher -- WebSource Internet Services - www.websource.ch Kontakt/PGP-Keys: www.websource.ch/kontakt - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html