Re: Max TNT not respecting my Default profile
On Jul 2, 2004, at 10:40 AM, Drew Weaver wrote: Alan, I assume Idle-Timeout = 900 Means that after 900 seconds (15min) of the connection being idle it will drop? I have it set that way right now and this connection I made has been active for 44 minutes (idle) You might have a setting on the NAS that is overriding the Idle-Timeout RADIUS attribute. Do this: 1. read answer-defaults 2. list session-info Take a look at what is set for "idle-timer" What I can tell you for sure is that this is not a problem with RADIUS. HTH, Chris Brotsos Any ideas? -Drew -Original Message- From: Alan DeKok [mailto:[EMAIL PROTECTED] Sent: Friday, July 02, 2004 10:18 AM To: [EMAIL PROTECTED] Subject: Re: Max TNT not respecting my Default profile Drew Weaver <[EMAIL PROTECTED]> wrote: Sorry to bother you guys with this.. I just noticed that this command Ascend-Idle-Limit = 900 appears to have no effect on the length of time our Ascend Max TNT will allow a user to be idle. So use the standard attribute "Idle-Timeout" Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Leading \000 in accounting-records
On Apr 30, 2004, at 2:04 PM, Alan DeKok wrote: Chris Brotsos <[EMAIL PROTECTED]> wrote: Just out of curiosity, was this bug just recently introduced into the system? I ask because we are running a CVS head after 0.9.3 and don't have this problem. No, it's most likely due to a client doing weird things. If the tag is zero, then the client SHOULD not put it in the attribute. FreeRADIUS doesn't. Apparently some clients do. Excellent, thanks Alan. Chris - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Leading \000 in accounting-records
On Apr 30, 2004, at 1:37 PM, Alan DeKok wrote: "Michael Markstaller" <[EMAIL PROTECTED]> wrote: I'm getting some strange leading "\000" in some L2tp-attributes within accounting records like (IPs are changed): Tunnel-Server-Endpoint:0 =3D "\00010.11.1.1"" It's a bug. Just out of curiosity, was this bug just recently introduced into the system? I ask because we are running a CVS head after 0.9.3 and don't have this problem. Thanks, Chris - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Filtering Accounting-Data
If you have the accounting compatible version of attr_filter, you should be able to do this. Instantiate attr_filter before detail in the accounting config, and whatever pairs you decide to strip should not make it into the detail file. HTH, Chris On Mar 23, 2004, at 9:58 AM, Oliver Zimmermann wrote: Hi, I hope, you can help me with an idea, how to filter/strip the "Framed-IP-Address" of customers from the accounting data. At the moment, I delete the these lines in the detail logs, but I'd like to know, if there is a more elegant way to achieve this. Has freeradius-0.9.3 a feature, to filter these incoming data or not to write it to the accounting logs? Regards, Oliver - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problem in Radius Proxy during FailOver --
List,
I have a patch to suggest at the bottom of this email.
Thanks,
Chris
On Feb 20, 2004, at 1:51 PM, Alan DeKok wrote:
Chris Brotsos <[EMAIL PROTECTED]> wrote:
Isn't this actually correct? According to the DOCS, if Synchronous is
set to Yes, then all of the other parameters should be set to 0. How
will the server 'know' what the retry_delay, retry_count, and
dead_time
are?
The server should have some configuration to use, to decide that a
home server hasn't responded in N seconds, and marks it dead. That
time can probably be "retry_delay * retry_count".
Some code probably needs to be added to the server to support this.
Alan DeKok.
-
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
Index: request_list.c
===
RCS file: /source/radiusd/src/main/request_list.c,v
retrieving revision 1.26
diff -u -r1.26 request_list.c
--- request_list.c 19 Feb 2004 21:40:58 - 1.26
+++ request_list.c 23 Feb 2004 17:03:19 -
@@ -916,6 +916,14 @@
* in the given retry window.
*/
if (mainconfig.proxy_synchronous) {
+ if (info->now > (request->timestamp +
(mainconfig.proxy_retry_delay * mainconfig.proxy_retry_count))) {
+ rad_assert(request->child_pid ==
NO_SUCH_CHILD_PID);
+ request_reject(request);
+
realm_disable(request->proxy->dst_ipaddr,
+ request->proxy->dst_port);
+ request->finished = TRUE;
+ goto setup_timeout;
+ }
request->proxy_next_try = info->now +
mainconfig.proxy_retry_delay;
}
difference = request->proxy_next_try - info->now;
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problem in Radius Proxy during FailOver --
On Feb 20, 2004, at 6:41 AM, Alan DeKok wrote: "Sudhagar Chinnaswamy" <[EMAIL PROTECTED]> wrote: The failover doesn't work if the "synchronous" parameter is set to "yes". Can someone explain this behaviour ? It's probably a bug in the server. I don't think that configuration has been well tested. Isn't this actually correct? According to the DOCS, if Synchronous is set to Yes, then all of the other parameters should be set to 0. How will the server 'know' what the retry_delay, retry_count, and dead_time are? Chris - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
