Alan DeKok wrote:
rihad wrote:
Trying for the third time:
Do you have any intention of reading the messages here?
there are many, many requests of the
"Discarding conflicting packet" kind, which for one reason or another
are dupped by our Cisco NASes in under one second (see the code). And
there are many, many lines of the "Received conflicting packet" fame
(see the code).
If (as you say) the NAS is sending a conflicting packet within 1
second of the first one, then the NAS is broken. It SHOULD wait 5
seconds for the old request to time out, before sending a new one that
re-uses the same IP/port/Id.
Take your NAS, and throw it in the garbage. Buy a real NAS that
implements RADIUS.
Oh yeah? Isn't Cisco 7260 good enough for you?
Now, it can be logically deduced that a big part of the
latter are indeed of the former type (because none of the NASes have
timeouts as low as 2-5 seconds). What I'd really love is for freeradius
to stop killing the current request after receiving a dup 2-5 seconds
apart.
That won't solve anything. This has been explained to you.
Did you understand the explanation, or are you simply ignoring it?
Explained what? What good is an explanation without testing it? True, I
still haven't tested increasing the 1 second wait either.
It's no problem for me to patch and rebuild freeradius myself, I
just thought it wouldn't be fair not to share that idea with others.
Thanks. And we shared our opinions... and you told us we were wrong.
Stop hacking the server and start looking at your perl code. Do you
really
need to use it for authentication? Can you get all the data in authorize
script and let freeradius default modules do the authentication (that can
speed things up quite a bit)? Can you get (some of) the data using
freeradius sql/ldap/whatever modules instead?
The rlm_perl authorization/accounting is dealing with traffic shaping,
so I'd rather fix this freeradius' shortcoming.
That response completely ignores the question. Did you understand it?
Didn't I say the Perl code might not be fast enough to handle hundreds
of requests per second? Probably up to several thousand. What good will
some sql/ldap/whatever tests do if I'm not going to be using them?
That said, I've increased cleanup_delay from 5 to 120, and max_requests
from 10000 to 100000. Let's wait...
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
