Eric Reischer <[EMAIL PROTECTED]> wrote: > I see in a lot of the dictionary files that there is a terminate-cause > value called "radius-request", yet I have not found a way to get Radius to > auto-kick people off after their daily time limit has been exceeded.
There is no standard way to do this. In any case, why the heck do you want to keep that amount of state on the RADIUS server? The NAS is already keeping track of the users PPP/IP options, so it's the one which should be dropping the connection after a time out. See 'Session-Timeout' > I also enabled the daily-session-limit counter, but this function > does not appear to terminate any active sessions for the user after > their daily limit has been met. It could be a bug in the server. Run it in debugging mode to be sure that authentication replies have a proper Session-Timeout attribute. If not, it could mean that the server is never getting accounting packets, which are REQUIRED to maintain the daily time outs. Or, it could mean that the NAS is ignoring the Session-Timeout attribute in the reply. > Does anybody know how to go about doing this? I was thinking about > performing some type of arithmetic function in the session-timeout > reply value in the users file, but I'm not sure if that file will > accept an arithmetic function as a reply value. No, it won't. And you would have to keep track of their timeouts for multiple logins in one day. That's what the 'counter' module is supposed to do. > Also -- Separate question: The Lucent/Ascend MAX uses a separate attribute > called Ascend-Terminate-Cause in place of the disconnect-reason attribute, > and I added its declaration and attribute values to the dictionary file, You shouldn't have to do that. It's already in the 'dictionary.ascend' > yet it is still not saving the entries in my SQL accounting database. I > changed the postgresql.conf queries so they use Ascend-Terminate-Cause, but > it still doesn't save it. I turned on detail logging and I see the > attribute being returned by the terminal server, but it's getting lost > somewhere after that. Has anybody else had this problem? I haven't heard of it before. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
