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

Reply via email to